Career path
Platform Engineer
Give development teams a self-service internal platform, secure by default, where the right way to build, deploy and run is also the easiest one.
Aim for this jobWhat this job does
- 6 responsibilities
- 18 missions
- 68 skills
- 250 hours of work an estimate, starting from zero
The job
What a Platform Engineer does
Six responsibilities. Each one is carried out through concrete missions, which require skills.
Isolate and secure teams on the platform
Missions that make it up
-
Centralize user identity on an identity provider
Deliverablea persistent identity provider with its realm, users, groups, roles and event logs, and an application connected with OpenID Connect whose tokens are validated
-
Provide secrets and identities to applications
Deliverableeach application with a minimal identity and vault access limited to its paths, its secrets issued with a bounded lifetime or mounted from a Kubernetes Secret, never written into its image or manifests
- Store a secret in a vault and read it without ever writing it in clear
- Scope access to a vault to the strict minimum and explain a denial
- Issue a secret with a bounded lifetime, renew it and revoke it in an emergency
- Configure an application with ConfigMaps and Secrets
- Give a workload a minimal identity (ServiceAccount)
-
Cap the resources of a platform's teams
Deliverablequotas and resource ranges per team, an overrun refused by the cluster
-
Open an isolated space for a team on a shared cluster
Deliverablea space where the cluster refuses what is forbidden, where the team's identity can do almost nothing, and that nothing outside can reach
Provide golden paths to teams
Missions that make it up
-
Provide observability to teams
Deliverablea standard telemetry collection, pipeline and instrumentation conventions, that teams plug into without rebuilding it
-
Ship an internal tool to other teams
Deliverablean internal tool that is tested, reviewed, versioned and installable by other teams without help
-
Standardise a team's CI
Deliverablepipeline templates reused by several repositories, with their contribution rules
-
Publish a reference Helm chart for teams
Deliverablea maintained chart, with a documented and validated values contract, signed and published to an OCI registry
Operate the platform's runtime foundation
Missions that make it up
-
Observe the platform
Deliverablea platform whose health, saturation and errors are collected, queryable, visualised and alerted on in a usable way
-
Bring a failing cluster back
Deliverablea node, a control plane or name resolution restored, the cause found without a procedure
-
Bring an application back on a cluster
Deliverablean application answering again, its faults found with no ticket and no procedure
-
Operate a Kubernetes cluster over time
Deliverablea cluster installed, hardened to the CIS benchmark, observed, backed up and restored from its backup
- Configure kubectl access to your clusters: kubeconfig, contexts and default namespace
- Observe a cluster's health and resource usage
- Install a Kubernetes cluster
- Back up and restore a cluster's state
- Run a cluster's operating routine
- Maintain and manage nodes without service interruption
- Harden a cluster's components with the CIS Benchmark
-
Upgrade a cluster without service interruption
Deliverablea cluster moved to the next minor version, deprecated APIs migrated, nodes drained without outage
Enable self-service deployment
Missions that make it up
-
Deliver an application on Kubernetes from a specification
Deliverablean application configured, probed, given a minimal identity, exposed and isolated, with no walkthrough
- Expose an application with a Service, Ingress or Gateway
- Configure an application with ConfigMaps and Secrets
- Make a workload reliable: health probes and resources
- Give a workload a minimal identity (ServiceAccount)
- Isolate traffic between Pods with NetworkPolicies
- Audit an application factor by factor (12-factor) on Kubernetes and fix its gaps
-
Deliver the same artefact to several environments
Deliverablean artefact built once, promoted from staging to production reproducibly, under control and traceably, with configuration specific to each environment
- Build an artifact once and promote it across environments
- Update an application and roll back
- Configure an application with ConfigMaps and Secrets
- Make a workload reliable: health probes and resources
- Design dynamic pipelines (variables, conditions, reuse)
- Deliver to environments, artifacts included
- Adapt manifests per environment with Kustomize
- Change Kubernetes resources declaratively without drifting from Git
-
Deploy with GitOps
Deliverablenotes-api deployed and promoted between two environments from Git
Describe the platform's infrastructure as code
Missions that make it up
-
Describe infrastructure as shareable, replayable code
Deliverablean infrastructure split into versioned modules, its state shared and locked, replayed identically
- Predict what an IaC tool will create, change or destroy: declarative model, idempotence, state and plan
- Keep an IaC repository healthy: layered structure, plan review, testing pyramid and secrets out of the code
- Structure infrastructure as code at scale: stacks, versioned modules, environments and debt
- Share a remote, locked and recoverable Terraform state
- Consume and version Terraform modules reproducibly
- Design, structure and test a reusable Terraform module
Guarantee trusted images and artefacts
Missions that make it up
-
Deliver a traceable artefact
Deliverablea hardened image, its SBOM and a provenance attestation
- Read an OCI image and check its integrity: index, manifest, config, layers and digests
- Secure the installation and the containers
- Harden the build, the images and the IaC
- Produce an artifact's SBOM and qualify its vulnerabilities with a VEX
- Publish an image to a registry: access token, tag, digest and publishing from CI
- Sign an artifact, attest its provenance and verify it before deployment
Also required, outside missions
The means
With which tools?
Choose your tools: the choice changes the lessons to read, never the responsibilities.
Continuous integration platform
GitOps tool
Automation language
Hypervisor
Going further
Specialisations
Optional, measured apart from the job.
Run the platform's secrets vault
Write the platform's tooling
- Read and transform data (JSON, YAML, APIs)
- Write a tested command-line tool
- Organize code into modules and publish a package on PyPI
- Manage Python versions, dependencies and installed tools (pyenv, pipx, Poetry)
- Test in isolation and across Python versions (unittest, mock, tox)
- Audit the quality and security of a project's code and dependencies
- Expose a REST API in Python and protect it with JWT
- Develop an Ansible module or plugin in Python
Set the platform's guardrails as Rego policies
Run a self-service private cloud on Incus
- Describe and deploy instances in Terraform with the hypervisor's provider
- Secure an Incus server and its remote administration
- Administer Incus OS nodes through the API: seed installation, A/B updates, Tailscale, backup, monitoring and fleet
- Build and run an Incus cluster: joining, quorum and roles, workers, shared CephFS storage
- Isolate tenants on Incus: OVN VPCs, load balancer, ACLs, quotas, scoped credentials and a 3-tier deployment in Terraform
Build maintainable Python tools
- Manipulate lists, tuples, sets and slices in Python
- Design Python classes: encapsulation, inheritance, abc and mixins
- Run concurrent work and choose the right model
- Harden a Python test suite: Hypothesis, pytest fixtures, coverage and mutation
- Model and type data in Python with dataclasses, Enum and annotations
- Write idiomatic Python: decorators, generators, context managers and itertools
- Profile and optimize a Python program, up to a native extension
Work with an AI coding agent, under control
- Scope a task given to Claude Code and check its result with a plan, a diff and tests
- Confine Claude Code's execution: permissions, secrets and sandbox
- Automate and extend Claude Code with hooks, skills and plugins
- Connect an MCP server to Claude Code and delegate to isolated subagents
- Take back control of a drifting Claude Code session and troubleshoot its configuration
- Deliver a complete project driven by Claude Code, one vertical slice at a time
- Run Claude Code without an interactive session, in CI, with the right model and cost
Provide teams with a sovereign AI platform
- Explain how an LLM works, its inference and its quantization
- Write reliable prompts: roles, few-shot, Chain-of-Thought and ReAct
- Run and serve an open source LLM, from the workstation to the GPU
- Operate an LLM gateway: routing, fallback, cache, keys and budgets
- Trace LLM calls with OpenTelemetry GenAI up to Grafana Tempo
- Secure, test, authenticate and deploy MCP servers
- Have an agent run code in a hardened sandbox
- Assemble a sovereign AI stack and expose it behind a secured web interface
- Analyze an LLM application's risks with the OWASP Top 10 for LLM 2025 and choose defense-in-depth controls
Run and govern the platform's identity provider, and connect Kubernetes and Vault to it
- Protect an API with OAuth 2 tokens: audience, scopes, machine access and choosing the flow of a client without a browser
- Require a second factor per group in Keycloak, with forced enrolment and recovery, and set a password policy compliant with NIST SP 800-63B-4
- Manage the account lifecycle in Keycloak with SCIM and Workflows, handle a departure and run an access review
- Run Keycloak in production: TLS proxy, restored backup, version upgrade, emergency access and a realm described in Terraform
- Connect the Kubernetes API server and Vault to an OIDC identity provider, turn token groups into limited rights and diagnose a denial
Administer a self-hosted Git forge (Forgejo)
- Set up Forgejo on PostgreSQL behind a TLS proxy, reachable over HTTPS and SSH, then configure mail, LFS and sign-ups
- Govern access to Forgejo: organisations, teams and permissions, sign-in through an OIDC provider with an enforced second factor, and account support from the command line
- Monitor Forgejo through its logs and Prometheus metrics, fire an alert and diagnose a database outage
- Secure a Forgejo instance: webhooks kept off the internal network, brute force banned with fail2ban, a break-glass administrator account, scoped tokens and signed commits
- Back up Forgejo, copy the encrypted backup off the machine, restore it on a blank stack and write the recovery runbook
- Maintain Forgejo and upgrade it: scheduled tasks, doctor and quotas, an upgrade rehearsed on a copy with validation criteria and rollback from the backup
What the site does not cover yet
Developer portal (service catalogue, project templates) and reproducible development environments: being prepared (drafts platform.portal.catalog and dev.environment.provide). Disposable virtual machines are recommended; Nix, taught in the Linux course, stays outside the role (niche tool).
Golden paths (level 4): declared, not demonstrated while the Helm, standardised CI and team observability proofs are missing.
Delivering a secret from a vault to a Kubernetes workload (External Secrets Operator, CSI): taught since 2026-10-18 by the optional secrets-kubernetes lesson of the Kubernetes course (External Secrets Operator on a test provider, choice between CSI, Sealed Secrets, SOPS and Vault Agent Injector), assessed by its quiz, with no proof of autonomy for lack of a lab; attached as practice to k8s.workload.configure and k8s.access.authorize, no skill carries its contract. The vault, its access and its time-bounded secrets are in the core since 2026-10-14 (sec.secrets.store, access, lifecycle), unproven while the secrets labs are missing.