What Platform Engineering actually is — and what it is not
Platform Engineering is the practice of building and operating Internal Developer Platforms (IDPs): curated sets of self-service tools, workflows, and golden paths that reduce cognitive load for application developers. The platform team is a product team whose internal customers are the engineers building the business applications. The product they ship is not a user-facing feature — it is the ability for a developer to push code, provision a database, spin up a staging environment, or roll back a deployment without filing a ticket, waiting for an ops team, or understanding Kubernetes YAML in depth.
This distinction from traditional DevOps is structural, not cosmetic. In embedded DevOps models, DevOps engineers work within feature teams and are measured by the delivery velocity of that team’s software. In Platform Engineering, the platform team measures its success by developer experience (how long does it take a new engineer to deploy their first service?) and platform adoption (what fraction of teams are using the golden path rather than ad-hoc infrastructure?). The platform is a product, and platform engineers are accountable for its reliability, usability, and adoption — not just its technical correctness.
The confusion with Site Reliability Engineering (SRE) is also common. SRE focuses on production reliability: SLOs, error budgets, incident response, and the toil-reduction practices that keep live systems stable. Platform Engineering focuses on developer enablement: the pre-production workflows, self-service interfaces, and infrastructure abstractions that determine how fast and safely new code reaches production. In practice, many organisations have both functions, with the platform team responsible for the IDP and the SRE team responsible for production observability — though at smaller companies, the boundary is blurry and the same engineers often do both.
The core components of an Internal Developer Platform
An IDP is not a single tool — it is an integrated set of capabilities built on top of existing infrastructure. In 2026, most enterprise IDPs share a recognisable stack, though the specific choices vary by organisation:
Developer Portal — Backstage
Backstage (open-sourced by Spotify, now a CNCF incubating project) is the de-facto developer portal standard in 2026. It provides a software catalog (a searchable registry of all services, libraries, APIs, documentation, and infrastructure components in the organisation), scaffolding templates for creating new services from golden-path templates, and a plugin ecosystem that surfaces CI/CD status, cloud costs, SLO dashboards, on-call schedules, and security findings in a single developer-facing UI.
- Software Catalog: every service registers itself with a
catalog-info.yamlfile in its repo. Backstage indexes these files and builds the catalog automatically from GitHub or GitLab. Teams can see who owns a service, what APIs it exposes, what its current build status is, and what its SLO status is without leaving the portal. - Scaffolding / Golden Paths: new services are created from Backstage software templates that pre-configure the repo structure, CI/CD pipeline, monitoring setup, and cloud resource configuration in a single self-service workflow. This is the mechanism that enforces architectural standards at the point of creation rather than in code review.
- Plugin ecosystem: Backstage has hundreds of community plugins. High-adoption plugins include GitHub Actions status, ArgoCD deployment status, PagerDuty on-call display, Grafana dashboards, SonarQube code quality scores, and cloud cost visibility via Infracost or similar tooling. Most large enterprises build internal plugins for their proprietary systems.
Infrastructure Provisioning — Crossplane and Terraform
Platform engineers own the infrastructure provisioning layer. Two approaches have consolidated in 2026. Crossplane (CNCF graduated project) enables infrastructure provisioning as Kubernetes custom resources — a developer creates a PostgreSQLInstance object in their Kubernetes namespace and Crossplane provisions the actual RDS instance on AWS (or Cloud SQL on GCP, or Flexible Server on Azure) and injects the connection secret. This “infrastructure as Kubernetes resources” model is gaining adoption because it integrates naturally with GitOps workflows. Terraform remains dominant for platform-team-managed infrastructure and for organisations not yet running Crossplane. Most IDP stacks use both: Terraform for foundational infrastructure (VPCs, EKS clusters, IAM roles) and Crossplane for developer-self-service database and messaging provisioning.
- Crossplane Compositions: the key Crossplane abstraction for platform engineers. A Composition defines a composite resource type (e.g.,
AppDatabase) and the set of managed resources it provisions (an RDS instance, a security group, a parameter group, an IAM role). Application developers interact only with the composite resource — the underlying cloud provider details are opaque to them. - Terraform modules: platform teams publish internal Terraform module registries (via Terraform Enterprise, Spacelift, or Atlantis) that expose curated, compliance-checked infrastructure components. Application teams consume modules rather than writing raw Terraform — the same golden-path principle applied to IaC.
GitOps and CD — ArgoCD and Flux
GitOps is the deployment model where the desired state of every environment is declared in Git, and an automated operator continuously reconciles the running cluster toward that state. ArgoCD (CNCF graduated, most widely adopted in 2026) and Flux (the other CNCF graduated GitOps engine) are the two dominant implementations. Platform engineers own the ArgoCD/Flux installation and configure it as the deployment mechanism for all application teams — direct kubectl apply access to production clusters is typically removed once GitOps is in place.
- ApplicationSets: ArgoCD ApplicationSets enable a single template to generate Application objects for every team, service, or environment combination — the platform team defines the template, and new services automatically get ArgoCD Applications created from the software catalog or a directory listing.
- Progressive delivery: many platform teams layer Argo Rollouts on top of ArgoCD to provide canary and blue/green deployment strategies with automated analysis (Prometheus metrics, synthetic tests) and rollback. The platform team configures the analysis templates; application teams declare the rollout strategy per deployment.
Observability Platform — the LGTM stack
Platform teams own the observability infrastructure: metrics, logs, traces, and dashboards. In 2026, the LGTM stack (Loki for logs, Grafana for visualisation, Tempo for traces, Mimir for long-term metrics storage) has emerged as the dominant open-source choice, often deployed via the kube-prometheus-stack Helm chart and Grafana Operator. The platform team runs the stack and provides application teams with self-service dashboard templates, pre-built alert rules, and OpenTelemetry collector configurations. The key platform engineering challenge here is multi-tenancy: ensuring that each team’s metrics, logs, and traces are isolated so that one team’s high-cardinality queries cannot degrade observability for others.
- OpenTelemetry (OTel): the platform team deploys the OTel Collector as a DaemonSet and provides auto-instrumentation libraries for the primary language stacks (Java, Go, Python, Node.js). Application teams add a single annotation to enable auto-instrumentation; the platform handles the rest.
The certification stack for Platform Engineers
No single certification maps perfectly to Platform Engineering as a discipline, because the role spans Kubernetes, IaC, GitOps, CI/CD, and developer experience. In practice, hiring managers in 2026 look for a combination of certifications that together demonstrate the breadth of skills the role requires. The most useful certifications, in priority order:
CKA — Certified Kubernetes Administrator (highest priority)
CKA is the foundational credential for Platform Engineering. Kubernetes is the infrastructure backbone of every modern IDP — the compute layer on which Backstage, ArgoCD, Crossplane, and the observability stack all run. The CKA exam tests cluster administration: kubeadm bootstrapping, etcd backup and restore, RBAC configuration, NetworkPolicy, PersistentVolumes, node maintenance, and troubleshooting. Platform engineers spend more time on RBAC, NetworkPolicy, and resource quotas than on kubeadm bootstrapping in practice, but the exam covers the full administration surface at a depth that validates genuine Kubernetes competency. The exam is performance-based (hands-on tasks in a live cluster via browser terminal), which makes it more credible than multiple-choice exams for hiring purposes.
Terraform Associate (003) — HashiCorp / IBM
The Terraform Associate validates core IaC skills: HCL syntax, state management, modules, workspaces, backend configuration, and the Terraform Cloud/Enterprise workflow. In 2026, the exam is offered by IBM (which acquired HashiCorp in 2024) under the same format and objectives as the original HashiCorp version. For Platform Engineering roles, Terraform is the primary tool for foundational infrastructure and is the prerequisite skill for working with Crossplane (which builds on the same provider ecosystem). Candidates who hold Terraform Associate and are fluent with modules and remote state are well-positioned for the IaC components of platform engineering work. A cloud-provider associate certification (AWS SAA, AZ-104, or GCP ACE) alongside Terraform Associate demonstrates both the IaC and cloud provider competency that platform engineers need.
CKAD — Certified Kubernetes Application Developer
CKAD tests the developer-facing surface of Kubernetes: Pod specs, Deployments, Services, ConfigMaps, Secrets, Ingress, resource requests and limits, probes, and Helm chart deployment. For platform engineers, CKAD is valuable because it forces fluency with the exact API surface that application developers use daily — which is the surface the platform team is responsible for making usable and reliable. Platform engineers who hold both CKA and CKAD can think simultaneously from the operator’s perspective (cluster stability, RBAC, node management) and the developer’s perspective (why is my Pod stuck in CrashLoopBackOff, why is my Ingress not routing traffic, why is my HPA not scaling). That dual perspective is what makes platform engineers effective at designing golden paths that actually work for the teams using them.
GitHub Foundations — GitHub Certification
GitHub Foundations validates proficiency with GitHub as a collaboration and automation platform: repository management, branch protection rules, GitHub Actions workflows, GitHub Packages (container registry), security features (Dependabot, code scanning, secret scanning), and GitHub Projects for work tracking. For platform engineers, GitHub (or GitLab) is the source-of-truth system that underpins everything — the software catalog ingests from it, the GitOps operator watches it, the CI/CD pipelines run in it, and the self-service scaffolding templates live in it. Deep GitHub fluency is prerequisite for configuring Backstage’s GitHub integration, setting up ArgoCD’s webhook-triggered sync, and authoring the GitHub Actions workflows that power the golden-path CI/CD pipelines the platform team publishes.
KCNA — Kubernetes and Cloud Native Associate
KCNA is an entry-level certification covering the CNCF ecosystem: Kubernetes fundamentals, container fundamentals, cloud native architecture patterns, GitOps, service mesh concepts, and observability basics. It is a knowledge-based multiple-choice exam (not hands-on) and is best suited to engineers transitioning into platform engineering from adjacent roles (traditional ops, software development, DevOps) who want to demonstrate awareness of the cloud native landscape before sitting CKA. Hiring managers at companies with mature platform teams rarely treat KCNA as a standalone signal for senior platform engineer roles, but it pairs well with CKA to demonstrate both theoretical breadth and hands-on depth.
Salaries in 2026: what Platform Engineers earn
Platform Engineering has become one of the highest-compensated individual contributor roles in cloud infrastructure. The premium reflects both the breadth of skills required and the direct impact on engineering productivity — a high-functioning IDP demonstrably reduces time-to-production across hundreds of engineers, which makes platform engineering headcount defensible at even the most cost-conscious organisations.
- Junior Platform Engineer (1–3 years, holds CKA or Terraform Associate): $110,000–$140,000 in major US technology markets. Entry-level platform roles typically focus on a specific component of the IDP — maintaining the ArgoCD installation, authoring Backstage plugins, or managing the Terraform module registry — rather than the full platform surface.
- Mid-Level Platform Engineer (3–6 years, CKA + Terraform + cloud associate): $145,000–$190,000. At this level, engineers own significant components of the IDP end-to-end: designing Crossplane Compositions, building self-service Backstage templates, running the observability platform, or leading the GitOps migration for a large engineering organisation. Companies with active IDP programmes pay at the upper end of this range; companies building their first IDP pay closer to the lower end.
- Senior Platform Engineer / Platform Architect (6+ years, CKA + CKAD + Terraform + cloud specialty or CISSP): $185,000–$220,000. Senior platform roles carry architectural accountability for the full IDP stack, developer-facing API design, and technical leadership of junior platform engineers. At this level, platform engineers are evaluated on platform adoption metrics, developer experience NPS scores, and the measurable reduction in time-to-production for the engineering organisation they serve.
- Staff / Principal Platform Engineer (10+ years, multi-cloud, org-wide impact): $210,000–$280,000+, often with equity that can significantly exceed cash compensation at growth-stage technology companies. These roles define the long-term platform strategy, evaluate new tooling (service mesh adoption, eBPF-based networking, WebAssembly workloads), and represent the platform team at the architectural governance level of the organisation.
The platform engineering roles attracting the highest compensation in 2026 are not the ones with the deepest Kubernetes expertise alone — they are the ones that combine Kubernetes depth with strong developer empathy and product thinking. The best platform engineers understand that adoption is the metric that matters: a technically excellent IDP that engineers route around is a failure. If you are studying for CKA, also study how to run a developer survey and how to measure time-to-first-deployment for a new engineer joining the organisation.
How to transition into Platform Engineering
The most common transition paths into Platform Engineering in 2026 come from three adjacent roles: traditional DevOps/SRE engineers who already manage Kubernetes and CI/CD infrastructure, backend software engineers who have become the “infrastructure-aware” person on their team and want to formalise that role, and cloud engineers (AWS, Azure, GCP) who are comfortable with infrastructure provisioning but want to move into the developer-enablement layer.
The fastest transition path is to get hands-on with Backstage, ArgoCD, and Crossplane in a personal project or a dedicated lab environment before interviewing for platform engineering roles. The Backstage documentation includes a full tutorial for spinning up a local Backstage instance with the GitHub integration, a software catalog, and a scaffolding template. ArgoCD can be installed on any Kubernetes cluster (including local clusters via kind or k3d) in under ten minutes. Crossplane requires a cloud account and a cluster but has comprehensive getting-started guides for AWS, Azure, and GCP. Building a working demo IDP that includes all three components — even a minimal one — is a more effective signal in technical interviews than any single certification.
For certification, the recommended sequence for a DevOps-to-Platform-Engineering transition: CKA first (validates the Kubernetes depth the role requires), then Terraform Associate (if not already held), then CKAD (to round out the Kubernetes coverage with the developer-facing surface). Engineers coming from a cloud-native background who already hold a cloud associate certification (AWS SAA, AZ-104, GCP ACE) should prioritise CKA and Terraform Associate. Engineers coming from a software development background who are less comfortable with Kubernetes should consider adding KCNA as a starting point before CKA.
CKA is a hands-on exam — you work in a live Kubernetes cluster via a browser terminal for two hours. The single most effective preparation is building the habit of working entirely in the terminal without IDE assistance. Practice every exam task using kubectl, kubeadm, and vim (or nano) with no autocomplete beyond what the exam terminal provides. The Killer.sh CKA simulator (included with exam registration) provides a realistic environment and harder-than-real-exam tasks — use it for both your final preparation sessions and your post-registration warm-up.
CertQuests includes a free CKA question pack covering Kubernetes administration concepts, RBAC, networking, storage, and cluster troubleshooting. Practice the theory foundation before your hands-on lab sessions — understanding the conceptual model behind RBAC bindings, NetworkPolicy selectors, and PersistentVolume binding modes makes the hands-on tasks significantly easier to reason about under exam pressure.
Practice Kubernetes, Terraform, and cloud infrastructure certification questions for free on CertQuests.
Browse All Certifications →