Cloud Platform Engineer Job Description

A Cloud Platform Engineer builds and runs the internal platform that an organization's software teams use to ship and operate code in the cloud. CNCF's TAG App Delivery glossary defines platform engineering as "the design, construction, operation, and evolution of a platform," and the last word in that list matters: the platform is a product with internal customers, and it is never finished. In an IT organization the job sits between the cloud accounts and the application teams, inside a central infrastructure, cloud or developer-productivity group.

The purpose of the work, in the CNCF Platforms White Paper's phrasing, is to reduce the cognitive load on product teams. An application developer should be able to request a database, a namespace or a deployment pipeline without learning the provider's identity model or the cluster's network layout. The Cloud Platform Engineer makes that possible by wrapping infrastructure in interfaces; the white paper gives web portals, custom APIs and golden path templates as examples of the interfaces platform teams are responsible for.

The layers of the job

A typical week can touch several layers of the stack:

• Clusters. Where the platform runs on Kubernetes, the engineer owns version upgrades, node pools, autoscaling, ingress and storage classes, and debugs the scheduler and networking faults that application teams cannot see.
• Infrastructure as code. Terraform or OpenTofu modules turn cloud networking, identity and managed services into versioned components that teams consume through a pull request rather than a ticket.
• Delivery. GitOps controllers such as Argo CD and Flux keep what runs in each cluster matched to what is declared in Git, so a rollback is a commit revert.
• Observability. Prometheus, OpenTelemetry and a log pipeline give every service metrics, traces and logs from its first deploy, with alerts routed to the team that owns the code.
• Guardrails. Admission policies, network policies, workload identity and secrets delivery let the platform reject an unsafe configuration before it is applied, instead of after an incident.

Product work, not just plumbing

What separates a platform from a pile of shared scripts is product discipline. A Cloud Platform Engineer interviews internal developers, watches where onboarding stalls, reads the ticket queue for repeat requests and turns the frequent ones into self-service actions. A developer portal such as Backstage can hold the service catalog, so a new service starts from a template with logging, alerts, ownership metadata and a pipeline already wired in.

The role also writes real software: Kubernetes operators and controllers in Go, internal CLIs, portal plugins and the glue between the cloud provider's APIs and the organization's own systems. That code has users, so it needs tests, versioning, deprecation notices and documentation like any product.

Who they work with

The customers are application developers, but the job also runs through security, networking, finance and site reliability teams. Security writes policy that the platform enforces. Finance wants spend tagged by team and service. SREs share on-call for the platform's own components. An engineer who can explain a constraint to each of those groups in its own terms keeps the platform adopted instead of routed around.

Education and path in

As a rough guide, Cloud Platform Engineers start with a bachelor's degree in computer science, information systems or software engineering, and a solid record of production infrastructure work can stand in for the degree. People typically reach the title after three to five years in an adjacent role: systems administration, site reliability engineering, DevOps or backend development. The useful thread through all of them is time on call for production systems, which teaches what a platform has to prevent.

Skills that matter

• Kubernetes operations: RBAC, CNI networking, persistent storage, upgrades, admission control and the controller pattern
• Infrastructure as code: Terraform or OpenTofu module design, state management and policy checks in CI
• Programming: Go or Python written to the standard of code other teams depend on, with tests and release notes
• Delivery tooling: Argo CD or Flux for GitOps, plus GitHub Actions, GitLab CI or Tekton for builds
• One cloud in depth: compute, networking, identity and managed data services on AWS, Azure or Google Cloud
• Observability: Prometheus, Grafana, OpenTelemetry and log shipping
• Product habits: short design documents, user interviews with internal developers, and adoption tracking

Certifications

Platform engineering has its own credentials from the Cloud Native Computing Foundation. The Certified Cloud Native Platform Engineering Associate (CNPA) is an online, proctored, multiple-choice exam whose largest domain, platform engineering core fundamentals, carries 36% of the weight. The Certified Cloud Native Platform Engineer (CNPE), which CNCF announced as globally available on Nov. 11, 2025, is a performance-based, 120-minute exam that builds on the associate level. Its domain weights read like a job description: GitOps and continuous delivery (25%), platform APIs and self-service capabilities (25%), observability and operations (20%), platform architecture and infrastructure (15%), and security and policy enforcement (15%). CNCF points the CNPE at people moving toward senior or principal platform engineer and platform architect roles.

For cluster depth, the Linux Foundation's Certified Kubernetes Administrator (CKA) is a performance-based exam, and its Certified Kubernetes Security Specialist (CKS) covers the security side. Cloud-specific options include AWS Certified DevOps Engineer - Professional from Amazon Web Services and Professional Cloud DevOps Engineer from Google Cloud, and HashiCorp Certified: Terraform Associate from HashiCorp covers infrastructure as code. Pick the cloud credential that matches the employer's provider.

What a strong candidate can show

A platform feature other teams adopted, with the before and after in their own words. A cluster or runtime upgrade the candidate planned and ran. A postmortem they wrote that led to a guardrail. Those three artifacts show readiness for the role directly.

BLS does not publish projections for Cloud Platform Engineers as a separate title. For the wider group that contains it, Computer Occupations, All Other, O*NET reports projected growth of 5% to 6% from 2025 to 2035, which it rates faster than average, and about 27,000 openings a year on average. That group spans many kinds of computer work, so read it as context for the job family rather than a forecast for this title.

Kubernetes in production

The Cloud Native Computing Foundation's annual survey, a global poll of 628 respondents taken in September 2025 and published in January 2026, found Kubernetes in production at 82% of container users. The same report argues that the main obstacle is no longer technical: 47% of organizations cited "cultural changes with the development team" as their top obstacle, and CNCF calls that "the 'why' behind platform engineering." That matches the shape of the job: a platform succeeds only when teams adopt it.

The survey also uses GitOps as a maturity marker. CNCF sorts organizations into four stages, explorers, adopters, practitioners and innovators, and reports that none of the explorers had implemented GitOps while 58% of innovators ran GitOps-compliant deployments.

Upgrade work never stops

Platform teams absorb lifecycle changes so application teams do not have to. Kubernetes v1.35, released Dec. 17, 2025, retired the legacy cgroup v1 support; on nodes running Linux distributions without cgroup v2, the kubelet fails to start. The same release deprecated the ipvs mode in kube-proxy, with nftables named as the recommended replacement, and it was the final version to support containerd 1.7 and other 1.x LTS releases. Each change like that turns into node image rebuilds, staged rollouts and communication to every team on the platform, which is routine work for this role.

New tenants on the platform

Organizations that host AI models add new kinds of workloads to the catalog: GPU node pools, model-serving stacks, vector databases and sandboxes for agents that run code. Each one needs the same paved road the platform already offers web services, including quotas, cost tags, observability and policy, plus scheduling rules for scarce accelerators.

Where the career goes

From the engineer level, the technical track runs to senior, staff and principal platform engineer, then platform architect. The management track leads to platform or infrastructure engineering manager and director of developer productivity. Some engineers move sideways into site reliability leadership, security engineering or platform product management, where the same knowledge of internal customers carries over.

Within the IT industry, the employers include software and SaaS companies, cloud and hosting providers, IT services and consulting firms, and the in-house technology groups of banks, insurers, health systems and government agencies.

Dear Hiring Manager,

I am applying for the Cloud Platform Engineer role on your developer platform team. For the past four years I have worked on the infrastructure group at a regional insurance carrier, where I moved from maintaining build servers to owning the Kubernetes platform that our application teams deploy to every day.

The project I am proudest of started with our ticket queue. Teams were waiting days for new environments because each one needed a namespace, network policies, a database and secrets set up by hand. I wrote a Terraform module for the cloud resources and a small Go controller for the cluster side, then exposed both through a Backstage template. Developers now fill in one form and get a working environment with logging and alerts already attached. The ticket category for environment requests is close to empty, and I spend that time on the next request.

I also led our last two cluster upgrades. I built a staging fleet that mirrors production, wrote the runbook, tested each deprecation against our workloads and rolled the change out in waves with clear notice to every team. Neither upgrade caused an application outage, and the runbook is now the template for the next one.

I hold the Certified Kubernetes Administrator credential and am preparing for the platform engineer exam. I work mostly in Go and Python, and I review every module I ship as if another team will maintain it.

Your posting describes a platform that serves many product teams and a plan to move them onto GitOps delivery. I have done that migration once and would like to do it again at a larger scale. I would welcome a conversation about where your platform is today and where you want it next year.

Sincerely, Jordan Avery