Skip to content

DevOps / Platform Engineer

Builds infrastructure, pipelines and platforms so teams ship fast, safely and reliably

A path from Linux, networking and Git through containers, CI/CD, cloud, IaC, Kubernetes, observability, supply chain security and platform engineering, plus running AI workloads. For developers who want to understand the infrastructure behind their code, or anyone moving into a DevOps, SRE or Platform Engineer role.

Start at stage 01
stages
10stages
topics
56topics
weeks, part-time
~42weeks, part-time
  • Foundation
  • Core
  • Advanced
  • LinuxLinux
  • DockerDocker
  • GitHubGitHub Actions
  • KubernetesKubernetes
  • TerraformOpenTofu/Terraform
  • AWS
  • OpenTelemetry
  • Argo CD

My take

I am a Frontend Developer, not a DevOps specialist. What I know about this area comes from setting up CI, writing Dockerfiles and configuring Vercel deploys for the Bun + Turborepo monorepo behind this blog, plus time spent with the DevOps engineers on my team while debugging pipelines and environment issues. Every time I sat next to them I realized I had only touched the outer layer. This map is the path I would take if I started as a DevOps / Platform Engineer today, built from official docs, what I observed, and the major shifts in the field as of late 2026.

What I wish I had known earlier

  • When I started writing pipelines I would copy some YAML until it ran and call it done. What I wish I had known earlier is that you need Linux, processes, networking and DNS to debug a pipeline or container that dies for no obvious reason.
  • Anything done by hand in a cloud console gets forgotten or drifts between environments sooner or later. Putting everything in code and reviewing it like application code made me much less afraid of making changes.
  • Observability is not about pretty dashboards. The real question is what users are experiencing, and SLOs let the whole team answer that with numbers instead of gut feeling.
  • Building a platform means building a product for other developers. From the developer side, I only adopt something if it is easier than doing it myself, so a golden path has to be genuinely easy, not just a rule.
0 of 10 stages passed

Foundation01–03

  1. 01Stage 01, 5 weeksLinux, shell and networking basicsWork confidently on Linux servers, write safe shell scripts and explain how a request travels through DNS, TLS and a load balancer.
    I used to find this part dry and wanted to jump straight to Kubernetes. But most of the nastiest container and CI failures come down to permissions, processes, DNS or certificates, so this foundation is worth the time.

    What to learn

    Processes, file system and permissions
    Understand processes, signals (SIGTERM, SIGKILL), file descriptors, users and groups, chmod/chown and capabilities. Inspect resources with ps, top, ss, lsof, df, du and read system logs with journalctl. Containers reuse exactly these primitives through namespaces and cgroups.
    systemd and service management
    Write unit files, understand restart policies, unit dependencies and how systemd limits resources through cgroups. Read state with systemctl status and debug a service that will not start using journalctl -u.
    Safe shell scripting
    Use set -euo pipefail, quote variables properly, use trap for cleanup and lint scripts with ShellCheck. Know when to stop writing Bash and switch to Python or Go once the logic gets complex.
    DNS and HTTP
    Understand A, AAAA, CNAME, TXT and MX records, TTLs and the resolution process, and debug with dig. Know how HTTP/1.1, HTTP/2 and HTTP/3 differ, along with the headers that matter for caching, proxies and CORS.
    TLS and certificates
    Understand the TLS handshake, certificate chains, SNI, mTLS and the certificate lifecycle with ACME (Let's Encrypt). Use openssl s_client to check for expired certificates or broken chains, a very common deploy failure.
    Load balancing and reverse proxies
    Distinguish layer 4 from layer 7 load balancers, round robin and least connections, health checks and connection draining. Practice with Nginx, HAProxy or Caddy to see how timeouts, keep-alive and X-Forwarded-* headers behave.

    Do

    • Use SSH keys instead of passwords and disable direct root login on every server.
    • Run ShellCheck on every script before it goes into a repo or pipeline.
    • Debug networking layer by layer: DNS, TCP connection, TLS, then HTTP.
    • Keep your most-used debugging commands in a short personal runbook.

    Watch out for

    • Running everything as root or using chmod 777 to move fast and never reverting it.
    • Changing DNS without considering TTL, then being surprised that some users still hit the old server.
    • Writing hundreds of lines of Bash with no error handling that fails halfway without anyone noticing.

    Checkpoint project: Run your own web server on a VPS

    Rent a small VPS, set up a non-root user, SSH keys and a firewall, and serve an app through Caddy or Nginx with HTTPS from Let's Encrypt. Done when the domain resolves correctly, certificates renew automatically, and the app runs under systemd and restarts after a crash.

    • LinuxLinux
    • Bash
    • DNS
    • TLS

    Quick check

    0/4 answered · 0 correct

    Get at least 3 of 4 right to mark this stage as passed.

    1. Question 1 of 4StarterDuring a deploy, the orchestrator sends SIGTERM and then SIGKILL 30 seconds later. Why should the app handle SIGTERM?
    2. Question 2 of 4StarterA script runs curl -sf "$URL" | jq .version > version.txt and keeps going even when curl fails. What makes that failure stop the script?
    3. Question 3 of 4StarterYou pointed an A record at a new server, yet some users keep hitting the old one for hours. Why?
    4. Question 4 of 4StarterRight after a deploy, users report the site cannot be reached. What is the most effective debugging order?
  2. 02Stage 02, 2 weeksGit workflows and trunk-based developmentUse Git at an advanced level and understand why trunk-based development is the foundation of CI/CD.
    Early on I was used to feature branches that lived for a week, and merging meant conflicts everywhere. Once I split PRs small and merged early, releasing became much calmer.

    What to learn

    Git's data model
    Understand commits, trees, blobs, refs and HEAD so rebase, reset and reflog stop being scary. Know when to merge versus rebase and how to recover lost commits with reflog.
    Trunk-based development
    Everyone merges into main frequently through short-lived branches, and main is always deployable. Compare it with GitFlow and understand why teams with high deploy frequency usually choose trunk-based.
    Feature flags
    Separate deploy from release with feature flags so unfinished code can be merged without affecting users. Look at OpenFeature as a vendor-neutral API and always plan for removing old flags.
    Branch protection and code review
    Configure rulesets or branch protection, required status checks, CODEOWNERS and signed commits. Use a merge queue when many people merge at once so main never breaks.
    Conventional Commits and versioning
    Write commit messages following Conventional Commits to generate changelogs and bump SemVer versions automatically with tools like release-please or Changesets in a monorepo.

    Do

    • Keep PRs small and focused, and merge them within a day or two.
    • Require green CI before anything merges into main.
    • Use feature flags for unfinished features instead of long-lived branches.
    • Never commit secrets, even on a temporary branch, because Git history is very hard to scrub.

    Watch out for

    • Force pushing to a shared branch and wiping out a teammate's commits.
    • Leaving feature flags around forever until the code turns into an if/else maze.

    Checkpoint project: Set up a trunk-based workflow for a repo

    Configure a repo with a ruleset protecting main, CODEOWNERS, required status checks and automatic changelogs from Conventional Commits. Done when nobody can push directly to main and every merge produces correct release notes.

    Resources

    • Git
    • Trunk-based
    • Feature flags

    Quick check

    0/4 answered · 0 correct

    Get at least 3 of 4 right to mark this stage as passed.

    1. Question 1 of 4StarterAfter git reset --hard HEAD~3 you realize you needed those commits. How do you get them back?
    2. Question 2 of 4StarterWhy do teams that deploy many times a day usually prefer trunk-based development over GitFlow?
    3. Question 3 of 4StarterA feature needs three weeks of work, but the team wants to merge to main every day. Which approach fits trunk-based development?
    4. Question 4 of 4StarterTwo PRs each pass CI on their own, but main breaks once both are merged. What prevents this?
  3. 03Stage 03, 3 weeksContainers with DockerPackage applications into small, fast-building, secure images that ship with an SBOM.
    The first Dockerfile I wrote for a Next.js app produced an image close to a gigabyte because it copied the whole node_modules. Understanding multi-stage builds and layer caching was my biggest leap in this area.

    What to learn

    How containers work
    A container is a process isolated by namespaces and limited by cgroups, not a virtual machine. Understanding the OCI image and runtime specs shows you that Docker, containerd and Podman are just different ways to run the same thing.
    Multi-stage builds and layer caching
    Split build and runtime stages, order instructions so rarely changing layers come first, and use .dockerignore and BuildKit cache mounts. The result is smaller images and much faster rebuilds.
    Base images and image security
    Pick minimal base images such as distroless, Alpine, Chainguard or Docker Hardened Images (free and open source since late 2025). Run as a non-root user, pin images by digest and scan for vulnerabilities with Trivy or Grype.
    SBOM
    Generate an SBOM (SPDX or CycloneDX) with Syft or docker buildx's --sbom option so you know what is inside an image. SBOMs feed vulnerability scanning and are increasingly required by supply chain regulations.
    Docker Compose for local environments
    Use Compose to bring up an app with its database, cache and queue in one command. Add healthchecks, depends_on with conditions and volumes so data survives restarts.
    Multi-platform builds
    Use docker buildx to build for both linux/amd64 and linux/arm64, which matters when developers use Apple Silicon while servers run x86, or when you run on ARM instances to save cost.

    Do

    • Always use multi-stage builds and copy only the required artifacts into the final image.
    • Run containers as a non-root user and enable a read-only filesystem where possible.
    • Pin base images by digest and let Renovate or Dependabot update them.
    • Never bake secrets into images through ARG or ENV; use BuildKit secret mounts.

    Watch out for

    • Using the latest tag so different environments end up running different images.
    • Treating a vulnerability scan as the finish line without a process for handling the CVEs it finds.
    • Ignoring SIGTERM so the container gets killed hard on every deploy.

    Checkpoint project: Containerize a full-stack app

    Write a multi-stage Dockerfile for a web app and an API, and add PostgreSQL with Compose. Done when the runtime image runs as non-root, is significantly smaller than your first version, ships with an SBOM and has no critical vulnerabilities according to Trivy.

    • DockerDocker
    • OCI
    • SBOM

    Quick check

    0/4 answered · 0 correct

    Get at least 3 of 4 right to mark this stage as passed.

    1. Question 1 of 4StarterTechnically, what is a running container?
    2. Question 2 of 4StarterIn a Node image, every code change reinstalls all dependencies. The Dockerfile copies the whole repo, then runs npm ci. What fixes it?
    3. Question 3 of 4StarterA Docker build needs a private npm token. Which approach keeps the token out of the image and its history?
    4. Question 4 of 4StarterWhy is deploying images by the latest tag risky?

Core04–08

  1. 04Stage 04, 4 weeksCI/CD with GitHub ActionsBuild fast, cached and secure pipelines that build, test, package and deploy with blue-green or canary support.
    This is the part I touched most while setting up CI for this blog's monorepo. The biggest lesson was that a pipeline is production code too: if it is slow, flaky or insecure, the whole team pays for it.

    What to learn

    Workflows, jobs and runners
    Understand triggers, parallel jobs, needs, matrix builds, concurrency groups and reusable workflows to avoid duplicated YAML. Know when you need self-hosted runners or autoscaling runners on Kubernetes with Actions Runner Controller.
    Caching and pipeline speed
    Use actions/cache or the built-in caching of setup actions, Docker layer caching through BuildKit, and Turborepo or Nx remote caching so only changed parts rebuild. Measure each step before optimizing.
    Artifacts and registries
    Distinguish temporary artifacts passed between jobs from long-lived release artifacts. Push images to a registry such as GHCR or ECR tagged with the commit SHA, build once, and promote the same image across environments.
    Pipeline security
    Use OIDC to get short-lived cloud credentials instead of storing access keys, set minimal permissions for GITHUB_TOKEN and pin actions to a commit SHA. The 2025 compromise of tj-actions/changed-files is a clear example of the risk of mutable tags.
    Deployment strategies
    Compare rolling updates, blue-green and canary releases and how each one rolls back. On Kubernetes, Argo Rollouts or Flagger can run metric-driven canaries that halt automatically when error rates rise.
    Environments and approvals
    Use GitHub environments to scope secrets per environment, require reviewers for production and add deployment protection rules. Record deploy data so you can track DORA metrics such as deployment frequency and change failure rate.

    Do

    • Build an artifact once and promote that same artifact from staging to production.
    • Default permissions to read and grant only what each job needs.
    • Use OIDC instead of long-lived cloud keys in secrets.
    • Keep PR pipelines under roughly ten minutes so nobody wants to skip them.

    Watch out for

    • Running pull_request_target workflows on code from forks, opening a path for secrets to leak.
    • Rebuilding the image per environment, so what was tested is not what gets deployed.
    • Retrying flaky tests until they pass instead of fixing them, until nobody trusts the pipeline.

    Checkpoint project: A complete pipeline for a monorepo

    Build a workflow that runs lint, tests and cached builds for a monorepo, builds an image tagged by SHA, deploys to staging automatically and to production with approval. Done when the pipeline uses OIDC, actions are pinned by SHA, the second run is clearly faster thanks to caching, and rollback is a single step.

    • GitHubGitHub Actions
    • CI/CD
    • Canary

    Quick check

    0/4 answered · 0 correct

    Get at least 3 of 4 right to mark this stage as passed.

    1. Question 1 of 4IntermediateWhy build the image once and promote that same image from staging to production?
    2. Question 2 of 4IntermediateA GitHub Actions workflow deploys to AWS with an access key stored in repository secrets. What is the recommended improvement?
    3. Question 3 of 4IntermediateWhy pin third-party actions to a full commit SHA instead of a tag like @v4?
    4. Question 4 of 4IntermediateA workflow triggered by pull_request_target checks out the fork's PR head and runs npm test. What is the risk?
  2. 05Stage 05, 5 weeksCloud fundamentals on AWSDesign a basic system on a major cloud with tight IAM, sensible networking, managed services and cost control.
    I use AWS as the example because it is the most common, but the concepts transfer to GCP or Azure fairly easily. What I saw DevOps engineers care about most was not knowing many services, but IAM, networking and the bill at the end of the month.

    What to learn

    IAM and least privilege
    Understand users, roles, policies, trust policies and how permissions are evaluated when policies overlap. Prefer roles with short-lived credentials, IAM Identity Center for people, and EKS Pod Identity or IRSA for workloads.
    Account structure
    Use AWS Organizations with separate accounts per environment or team and apply guardrails with Service Control Policies. A single account for everything makes both blast radius and cost allocation hard.
    VPC and networking
    Design public and private subnets across multiple Availability Zones, and understand route tables, NAT gateways, security groups, VPC endpoints and PrivateLink. NAT gateways and cross-AZ data transfer are frequently overlooked costs.
    Compute and managed services
    Compare EC2, ECS Fargate, Lambda and EKS by level of control and operational cost. Prefer managed services like RDS, ElastiCache, SQS and S3 so the team focuses on the product instead of patching databases.
    FinOps and cost
    Enforce tags for cost allocation, set budgets and alerts, and use Savings Plans, Spot and ARM (Graviton) instances for suitable workloads. The FinOps Framework turns cost into a shared engineering responsibility, not just finance's problem.

    Do

    • Enable MFA, remove root access keys and never use the root account for daily work.
    • Keep databases and internal services in private subnets, exposed only through a load balancer.
    • Tag every resource with owner, environment and cost-center from day one.
    • Set a budget alert before creating your first resource.

    Watch out for

    • Granting AdministratorAccess to everything because there is no time to write proper policies.
    • Leaving experimental resources running and getting a surprise bill at month end.
    • Putting everything in a single Availability Zone and calling it production.

    Checkpoint project: Deploy an app to AWS properly

    Build a two-AZ VPC, run a container app on ECS Fargate behind an Application Load Balancer, with the database on RDS in a private subnet and secrets in Secrets Manager. Done when the app is reachable only over HTTPS, there are no static credentials, every resource is tagged and a budget alert works.

    • AWS
    • IAM
    • VPC
    • FinOps

    Quick check

    0/4 answered · 0 correct

    Get at least 3 of 4 right to mark this stage as passed.

    1. Question 1 of 4IntermediateA Lambda function only reads objects from one S3 bucket. Which IAM setup follows least privilege?
    2. Question 2 of 4IntermediateWhy place the RDS database in a private subnet behind the application tier?
    3. Question 3 of 4IntermediateThe bill shows high NAT gateway charges from private instances pulling large files from S3 in the same region. Which fix is right?
    4. Question 4 of 4IntermediateWhy is running production in a single Availability Zone a problem?
  3. 06Stage 06, 4 weeksInfrastructure as CodeManage all infrastructure as code that is reviewed, tested, policy-checked and deployed through its own pipeline.
    The first time I watched a teammate run a plan and read the infrastructure diff like a code diff, I understood why they never change things by hand in the console.

    What to learn

    Terraform and OpenTofu
    Learn providers, resources, data sources, variables, outputs and the plan/apply lifecycle. OpenTofu is the open source fork under the Linux Foundation created after Terraform moved to the BSL license; the syntax is nearly identical and it adds features such as state encryption.
    State and environments
    Store state in a remote backend with locking such as S3, and split state by environment and blast radius so one apply cannot touch everything. Know how to use import, moved blocks and drift detection.
    Modules and repo structure
    Write small, versioned modules with clear inputs that can be reused. Use Terragrunt or an environment-based directory layout to avoid copy-paste as the number of environments grows.
    Pulumi and IaC in general-purpose languages
    Pulumi lets you write infrastructure in TypeScript, Python or Go, which suits teams that already code and want loops, types and normal tests. The trade-off is that it is easy to write logic too complex to review.
    Policy as code and testing
    Block bad configuration before apply with OPA/Conftest, Checkov or Trivy config scanning, for example public S3 buckets or security groups open to 0.0.0.0/0. Run plan in the PR so reviewers see exactly what will change.

    Do

    • Route every infrastructure change through a PR with an attached plan and a review.
    • Pin provider and module versions and upgrade deliberately.
    • Split state into small units by service and environment to reduce blast radius.
    • Run drift detection regularly and fix drift as soon as it appears.

    Watch out for

    • Keeping state locally or committing state files that contain secrets to Git.
    • Editing by hand in the console and having the next apply silently overwrite it.
    • One giant module taking dozens of variables to do everything.

    Checkpoint project: Rewrite stage 05 infrastructure as code

    Move all the AWS infrastructure from the previous stage into OpenTofu or Terraform with remote state, reusable modules and two environments, staging and production. Done when PRs show the plan automatically, a policy check blocks a deliberately bad config, and an environment can be rebuilt from scratch through the pipeline alone.

    • TerraformOpenTofu
    • TerraformTerraform
    • Pulumi
    • OPA

    Quick check

    0/4 answered · 0 correct

    Get at least 3 of 4 right to mark this stage as passed.

    1. Question 1 of 4IntermediateWhy store Terraform state in a remote backend with locking?
    2. Question 2 of 4IntermediateSomeone changed a Terraform-managed EC2 instance from t3.small to t3.large in the console. What happens on the next terraform apply?
    3. Question 3 of 4IntermediateWhy split Terraform state by service and environment instead of keeping one state for everything?
    4. Question 4 of 4IntermediateYou want to block pull requests that would create a publicly readable S3 bucket. Where should the check run?
  4. 07Stage 07, 6 weeksKubernetes and GitOpsRun applications on Kubernetes, packaged with Helm or Kustomize, autoscaled and deployed through GitOps.
    Kubernetes is where I think it is easiest to learn things in the wrong order. Understand Pods, Deployments, Services and how controllers drive actual state toward desired state first, then move on to Helm, service meshes or operators.

    What to learn

    Core objects
    Learn Pods, Deployments, StatefulSets, Jobs, Services, ConfigMaps, Secrets, Namespaces and the controller reconcile model. Understand probes (liveness, readiness, startup), resource requests and limits, and PodDisruptionBudgets so apps survive rolling updates and node drains.
    Networking and Gateway API
    Understand Services, cluster DNS, NetworkPolicy and CNIs such as Cilium. Gateway API is the standard successor to Ingress, especially now that Ingress-NGINX was retired in March 2026, and the ingress2gateway tool helps with migration.
    Helm and Kustomize
    Helm packages an application as a chart with templates and values, which suits distributing to many consumers. Kustomize uses template-free overlays, which suits patching config per environment; many teams use both together.
    Autoscaling
    Use HPA on CPU, memory or custom metrics, KEDA for event-driven scaling such as queue length, and Karpenter or Cluster Autoscaler for nodes. Wrong resource requests make every autoscaling mechanism misbehave.
    GitOps with Argo CD or Flux
    Git is the source of truth, and an in-cluster agent continuously syncs and reports drift. Keep config repos separate from code repos, let CI only update the image tag, and leave applying to Argo CD or Flux.
    Security and multi-tenancy
    Apply minimal RBAC, Pod Security Standards at the restricted level and a policy engine such as Kyverno or CEL-based ValidatingAdmissionPolicy to block dangerous config. Use External Secrets Operator to pull secrets from a secret manager instead of committing Secrets to Git.

    Do

    • Set requests and limits for every container based on real measurements.
    • Configure readiness probes and graceful shutdown so rolling updates do not drop requests.
    • Stop running kubectl apply by hand against production once GitOps is in place.
    • Use managed Kubernetes (EKS, GKE, AKS) unless you have a very clear reason to run the control plane yourself.

    Watch out for

    • Moving everything to Kubernetes when an ECS service or a serverless function would do.
    • Liveness probes that check the database, causing cascading restarts across the cluster when the DB slows down.
    • Committing base64 Secrets to Git and assuming that counts as encryption.

    Checkpoint project: A GitOps cluster for a multi-service app

    Stand up a cluster (kind locally or a managed cluster) and deploy an app with a frontend, an API and a worker using Helm or Kustomize, managed by Argo CD. Done when changing an image tag in Git updates the app automatically, HPA or KEDA scales under simulated load, NetworkPolicies are in place and secrets come from a secret manager.

    • KubernetesKubernetes
    • Helm
    • Argo CD
    • GitOps

    Quick check

    0/4 answered · 0 correct

    Get at least 3 of 4 right to mark this stage as passed.

    1. Question 1 of 4IntermediateWhy should a liveness probe avoid checking the database?
    2. Question 2 of 4IntermediateAn HPA targets 70% CPU, but pods never scale under heavy load. The containers have no CPU requests set. Why?
    3. Question 3 of 4IntermediateWith Argo CD managing the cluster, how should CI ship a new application version?
    4. Question 4 of 4IntermediateWhy is committing Kubernetes Secret manifests to Git unsafe, even though the values look scrambled?
  5. 08Stage 08, 5 weeksObservability, SLOs and on-callMeasure systems through metrics, logs and traces with OpenTelemetry, set SLOs with error budgets and handle incidents with a clear process.
    On the frontend I was used to seeing errors through the console and Sentry. Working with the DevOps team showed me the value of traces across many services and of agreeing up front on what healthy actually means.

    What to learn

    OpenTelemetry
    Use the OpenTelemetry SDKs and auto-instrumentation to collect traces, metrics and logs through one vendor-neutral standard, routed through the OpenTelemetry Collector before reaching a backend. The Collector lets you filter, sample and switch backends without code changes; the Profiles signal is still alpha, so do not rely on it in production yet.
    Metrics with Prometheus and Grafana
    Understand counters, gauges, histograms and label cardinality, and write PromQL for RED (rate, errors, duration) and USE metrics. Use Grafana for dashboards and Alertmanager to route alerts.
    Logs and traces
    Emit structured JSON logs that carry a trace_id linking them to traces. Understand context propagation through W3C Trace Context, head versus tail sampling, and backends such as Loki, Tempo or Jaeger.
    SLIs, SLOs and error budgets
    Pick SLIs that reflect user experience, such as request success rate or p99 latency, set realistic SLOs and use the error budget to balance shipping features against stability. Alert on multi-window burn rates instead of CPU thresholds.
    Incident response and on-call
    Define roles such as incident commander, communications lead and responders, with clear severity levels and a dedicated channel. Every page sent to on-call should require action and come with a runbook.
    Blameless postmortems
    Write postmortems that focus on systems and process rather than individuals, with a timeline, contributing factors and owned action items. Track the action items until they close, otherwise the postmortem is just a document on a shelf.

    Do

    • Alert on symptoms users can see, not on every internal metric.
    • Attach trace_id to logs and response headers so you can jump from an error to its trace quickly.
    • Control label cardinality and never put user IDs or full URLs into metrics.
    • Write a runbook for every alert before enabling it for on-call.

    Watch out for

    • Too many meaningless alerts, leading to alert fatigue and missed real incidents.
    • Setting a 100% or many-nines SLO with no business reason behind it.
    • Collecting everything without sampling and then being shocked by the observability bill.

    Checkpoint project: Observability for the stage 07 cluster

    Instrument the app with OpenTelemetry and set up a Collector, Prometheus, Grafana and a tracing backend. Define two SLOs with burn-rate alerts, then cause an incident on purpose, handle it with the process and write a postmortem. Done when you can go from an alert to the related trace and logs in a few clicks.

    • OpenTelemetry
    • Prometheus
    • SLO
    • SRE

    Quick check

    0/4 answered · 0 correct

    Get at least 3 of 4 right to mark this stage as passed.

    1. Question 1 of 4IntermediateWhy alert on multi-window error budget burn rate instead of a CPU threshold?
    2. Question 2 of 4IntermediateA developer adds a user_id label to the http_requests_total counter. What happens?
    3. Question 3 of 4IntermediateAn alert shows a spike in 500 errors. What is the fastest way to go from an error log line to the slow downstream call?
    4. Question 4 of 4IntermediateWhat makes a postmortem actually improve reliability?

Advanced09–10

  1. 09Stage 09, 3 weeksDevSecOps and supply chain securityProve where every production artifact came from and which pipeline built it, and manage secrets without leaking them.
    The supply chain attacks of the last few years show that dependencies and pipelines are attack surface too. I think every developer should know this part, not only DevOps.

    What to learn

    SLSA
    SLSA is a framework describing levels of assurance for builds, from having provenance to building on a hardened, tamper-resistant platform. Use it as a checklist to raise pipeline security step by step instead of aiming for the highest level at once.
    Signing and verification with Sigstore
    Use cosign to sign images keylessly via OIDC, with signatures recorded in the Rekor transparency log. GitHub artifact attestations use Sigstore to produce provenance, which you can verify with gh attestation verify or with an in-cluster policy.
    Admission policy at deploy time
    Block unsigned images or images without provenance at the cluster with Kyverno or the Sigstore policy-controller. This is the step that turns signatures from decoration into real protection for production.
    Secrets management
    Use a secret manager such as AWS Secrets Manager, HashiCorp Vault or OpenBao, preferring dynamic, short-lived and automatically rotated credentials. Scan repos with GitHub secret scanning or Gitleaks and have a revocation process ready for leaks.
    Dependency and repo security
    Use Renovate or Dependabot for steady updates, SCA to find vulnerable packages, and OpenSSF Scorecard to judge the health of open source projects you depend on. Add SAST in PRs but tune it so it does not drown people in false positives.

    Do

    • Sign every release image and verify the signature before it runs in production.
    • Generate SBOMs and provenance in the pipeline and store them alongside the artifact.
    • Use short-lived credentials through OIDC or dynamic secrets instead of static keys.
    • Prioritize vulnerabilities by real exploitability (EPSS, KEV) rather than CVSS score alone.

    Watch out for

    • Turning on a pile of scanners and leaving thousands of findings untriaged.
    • Signing images but never verifying the signatures anywhere.
    • Removing a leaked secret from Git but forgetting to revoke and rotate it.

    Checkpoint project: A pipeline with provenance and enforcement

    Extend the stage 04 pipeline to generate an SBOM, sign the image with cosign and produce build provenance, then configure the cluster to accept only signed images from the right repo. Done when an image built outside the pipeline is rejected by the cluster and the repo's OpenSSF Scorecard score is higher than when you started.

    • SLSA
    • Sigstore
    • Secrets

    Quick check

    0/4 answered · 0 correct

    Get at least 3 of 4 right to mark this stage as passed.

    1. Question 1 of 4AdvancedThe team signs every image with cosign, but nothing in the cluster verifies signatures. How much does that protect production?
    2. Question 2 of 4AdvancedAn AWS access key was committed and pushed. You removed it in the next commit. What else must you do?
    3. Question 3 of 4AdvancedA scan finds 2,000 CVEs across your images. How should you prioritize the work?
    4. Question 4 of 4AdvancedWhat is a sensible way to adopt SLSA for your build pipelines?
  2. 10Stage 10, 5 weeksPlatform engineering and AI workloadsBuild an internal platform with golden paths for developers and run AI/LLM workloads and AIOps tooling in a controlled way.
    As a platform user, I can clearly feel the difference between a service template that just works and a ten-step wiki page. On the AI side I have only integrated LLMs at the application layer, so this infrastructure is something I am learning alongside everyone else.

    What to learn

    Internal developer platforms
    A platform is a set of self-service tools and APIs that let developers create services, environments and databases without filing tickets. Treat it as a product with users, a roadmap, adoption and satisfaction metrics, and use the CNCF platform maturity model as a reference.
    Backstage and developer portals
    Backstage provides a software catalog, software templates to scaffold services to a standard, and TechDocs. The New Frontend System is now the default for new apps, so learn that approach if you start today; Port or Cortex are options if you do not want to run it yourself.
    Golden paths and abstractions
    A golden path is a paved road: templates with CI/CD, observability and security built in by default. Use Crossplane or similar controllers to expose infrastructure through Kubernetes-style APIs, and measure impact with DORA metrics and onboarding time.
    Infrastructure for LLMs and GPUs
    Dynamic Resource Allocation (DRA) is GA and lets you request and share GPUs far more flexibly than the old device plugins. Serve models with vLLM or KServe, route by KV cache and load with the Gateway API Inference Extension or llm-d, and scale on queue depth rather than CPU.
    Observability and cost for AI
    Use OpenTelemetry's GenAI semantic conventions to track tokens, latency, model and errors for every LLM call. Attribute token and GPU costs to teams or features, because this is the fastest-growing line item in many organizations.
    AIOps and operations agents
    Use LLMs to summarize alerts, suggest likely causes from logs and traces, or draft postmortems; agents usually reach systems through MCP servers. Keep humans approving every change, default agents to read-only access and log everything an agent does.

    Do

    • Interview developers and measure their pain points before building any platform component.
    • Make golden paths optional but good enough that people choose them.
    • Start with a thinnest viable platform and grow it based on real demand.
    • Scope AI agent permissions with least privilege and require approval for write actions.

    Watch out for

    • Standing up Backstage full of plugins while nobody maintains the catalog, so it goes stale quickly.
    • Leaving expensive GPUs idle because there is no autoscaling or sharing.
    • Giving AI agents write access to production without audit logs or a rollback path.

    Checkpoint project: A golden path with a built-in AI gateway

    Set up Backstage with a software template that creates a new service with its repo, pipeline, GitOps manifests and observability dashboard. Add a service that calls an LLM through a gateway with token tracking via OpenTelemetry. Done when a developer can get a new service running on staging in under an hour without asking anyone.

    • Backstage
    • Platform
    • GPU
    • AIOps

    Quick check

    0/4 answered · 0 correct

    Get at least 3 of 4 right to mark this stage as passed.

    1. Question 1 of 4AdvancedWhy should an internal developer platform be run as a product?
    2. Question 2 of 4AdvancedYou launch a new service template with CI/CD and observability built in. How do you get teams to use it?
    3. Question 3 of 4AdvancedA vLLM deployment autoscales on CPU, yet latency spikes while GPUs are saturated and CPU stays low. Which signal should drive scaling?
    4. Question 4 of 4AdvancedAn AIOps agent reaches your infrastructure through MCP servers. What is the safe default setup?

Where the role is going

What matters right now, and where things are heading in the next few years.

Now

  • Kubernetes is the default substrate for AI inference

    DRA is GA, GPU and TPU drivers have been donated to the community, and projects like llm-d bring KV-cache-aware routing into the CNCF ecosystem. DevOps engineers increasingly need to understand GPU scheduling and the specifics of model serving.

  • Gateway API replaces Ingress

    Ingress-NGINX was retired in March 2026, so many teams are moving to Gateway API with implementations such as Envoy Gateway, Cilium or NGINX Gateway Fabric. This is a real migration a newcomer may face right away.

  • Supply chain security is table stakes

    SBOMs, image signing, provenance and SHA-pinned actions are no longer bonus points but default expectations. Free hardened base images and built-in GitHub artifact attestations have lowered the barrier to getting started.

  • Platform engineering is maturing

    Organizations are moving from building portals to measuring outcomes: onboarding time, DORA metrics and developer satisfaction. Platforms are run as products, often with a dedicated product manager.

Next

  • Agents join operations

    AI agents will take over repetitive work such as alert triage, first-pass investigation and opening PRs that fix config. Prepare by investing in runbooks, observability and permissions, because an agent is only as good as the data and guardrails you give it.

  • Platforms serve both people and agents

    Golden paths and self-service APIs will be called by coding agents as often as by developers. Clear APIs with policy as code and audit logs are how you keep a platform safe as the volume of automated changes grows.

  • OpenTelemetry everywhere

    With Profiles on its way to stability and GenAI conventions spreading, OpenTelemetry is becoming the common layer for every signal, including LLM calls. Deep knowledge of the Collector and semantic conventions will outlast knowledge of any single vendor.

  • FinOps for GPUs and tokens

    AI costs will push infrastructure teams to measure and optimize per request and per model. Combining observability with cost data will be a major differentiator for DevOps engineers over the next few years.

By the end of this map you can

  • You can debug incidents systematically from Linux, DNS and TLS up to the application.
  • You can build CI/CD pipelines with caching, OIDC-based security and canary or blue-green releases.
  • You can provision cloud infrastructure entirely with OpenTofu or Terraform, guarded by policy as code.
  • You can run applications on Kubernetes through GitOps with autoscaling and baseline security.
  • You can define SLOs, build observability with OpenTelemetry and lead an incident through to a postmortem.
  • You can sign and verify artifacts and prove the origin of everything running in production.
  • You can design golden paths and bring AI workloads onto the platform with controlled cost and permissions.

Related articles

All articles

Feature Flags in the Frontend: Types, Evaluation, Rollout and Cleanup

Feature flags decouple deploy from release, but used carelessly they turn into tech debt and flickering UIs. This post covers the four kinds of flags, evaluating on the server vs the client, typed flag definitions in TypeScript, gradual rollout, A/B testing and a cleanup process.

Systems & architecture7 min

DevOps / Platform Engineer interview questions

See all 26

Other roles

Roadmap

Frontend Engineer

My main role

Building web interfaces that stay fast, accessible and maintainable as products grow

10 stages, 51 topics, ~34 weeks

Backend Engineer

Designs, builds and runs the APIs, data and services behind every product

10 stages, 52 topics, ~37 weeks

Mobile Engineer

Build iOS and Android apps that feel smooth, work offline and ship safely

10 stages, 50 topics, ~34 weeks

QA / Test Engineer

Find risk before users do and turn quality into something the team can measure

10 stages, 50 topics, ~36 weeks

AI Engineer

Build products on top of LLMs: APIs, RAG, agents, evals and running it all in production

10 stages, 58 topics, ~31 weeks