Cloud Engineer Job Description

A cloud engineer builds and runs the rented infrastructure that a company's software depends on: virtual networks, compute, storage, managed databases, identity, and the pipelines that push changes into all of it. The work happens on one or more public platforms such as AWS, Microsoft Azure and Google Cloud. On a well-run team, resources are declared in code, reviewed like application code, and applied through automation rather than by clicking through a console.

A typical week splits between project work and keeping production healthy. On the project side, an engineer might write a Terraform or OpenTofu module that stands up a new environment with its own network segments, firewall rules, IAM roles and logging, then wire it into a GitHub Actions or GitLab pipeline so the next team can request the same thing with a pull request. On the operations side, the same engineer reads dashboards, tunes alert thresholds, takes a turn on the on-call rotation, and writes up what broke and why after an incident.

Identity is now the front door

Platform identity rules change, and the engineer has to keep automation working through each change. Microsoft's mandatory multifactor authentication for Azure is one example: Microsoft says automation accounts are not in scope as long as they use a managed identity or service principal, while automation set up under a user identity is enforced on. For a cloud engineer, that turns an old shortcut, a shared human account running scripts, into a broken deployment, and it makes workload identities the expected pattern.

Cost data has a common format

Engineers also answer for the bill. FOCUS, the FinOps Open Cost and Usage Specification backed by the FinOps Foundation, is an open specification that defines how technology billing data generators should produce consistent datasets. Its steering committee ratified version 1.4 on June 4, 2026. AWS made its Data Exports for FOCUS 1.2 generally available on Nov. 19, 2025, letting customers send cost and usage data in that schema to Amazon S3. In practice, the engineer who tags resources correctly and builds the export pipeline is the one who makes per-team cost reporting possible across providers.

Where the role sits

Cloud engineers typically report into infrastructure, platform or site reliability groups, and they work alongside application developers, security staff and finance. The title covers a wide span, from an engineer who mostly maintains Kubernetes clusters to one who mostly designs network topology. What ties the variants together is ownership: the cloud engineer is the person expected to know how a change will behave once it reaches production, and to roll it back when it does not.

Education and entry routes

As a rough guide, the starting point is a bachelor's degree in computer science, computer engineering or information systems. Some engineers arrive by a side door instead: a few years as a Linux or Windows systems administrator, a network engineer, or a backend developer who kept volunteering for deployment work. Evidence of hands-on work helps any route: a public repository with infrastructure code, a home lab, or a clear account of an outage the candidate helped fix. As a rough guide, two to five years in an adjacent operations or development role comes before the cloud engineer title, with senior titles following once an engineer has owned production systems end to end.

Where the occupation sits in federal data

Government data has no cloud engineer category, so it helps to know where the role lands. ONET's keyword search for the title returns Computer Network Support Specialists (15-1231.00) and Computer Systems Engineers/Architects (15-1299.08) as its first two matches. The second is the better fit for the design and build work described here: ONET defines it as designing and developing solutions to complex applications problems, system administration issues or network concerns, and lists sample titles such as Infrastructure Engineer, Solutions Architect and Systems Engineer.

Technical skills that carry the job

• One cloud platform at depth: accounts or subscriptions, identity, virtual networking, storage classes, and the managed database and container services.
• Infrastructure as code with Terraform, OpenTofu, CloudFormation, Bicep or Pulumi, including state handling and module design.
• Containers and Kubernetes operations on EKS, AKS or GKE: deployments, autoscaling, network policy and upgrades.
• Scripting in Python, Bash or Go for glue code, and enough SQL to query billing exports.
• Observability: metrics, logs and traces, plus alert design that wakes people only for real problems.
• Security basics: least-privilege roles, secrets handling, encryption settings and audit logging.

Certifications

Vendor certifications are one way to show platform depth. Credentials relevant to the role include AWS Certified Solutions Architect - Associate and AWS Certified Solutions Architect - Professional from Amazon Web Services, Microsoft Certified: Azure Administrator Associate from Microsoft, the Professional Cloud Architect certification from Google Cloud, the Certified Kubernetes Administrator (CKA) from The Linux Foundation, HashiCorp Certified: Terraform Associate from HashiCorp, and FinOps Certified Practitioner from the FinOps Foundation for engineers who own cost work.

Exam content moves with the platforms. For a new version of the Solutions Architect - Professional exam, AWS set Nov. 16, 2026 as the last day to take SAP-C02 and Nov. 17, 2026 as the start of general delivery for SAP-C03. SAP-C03 adds material on resilience engineering with AWS Fault Injection Service and AWS Resilience Hub, and on post-quantum cryptography through AWS KMS with ML-DSA and ML-KEM. Candidates using older study guides should check them against AWS's current exam guide.

What the federal projections cover

BLS does not publish a projection for cloud engineers by name. The closest figures come from ONET's page for Computer Systems Engineers/Architects, which reports employment and wage data for the broader group it belongs to, Computer Occupations, All Other. For 2025 to 2035, ONET rates that group's projected growth as faster than average (5% to 6%), with about 27,000 openings a year on average. One level up, the BLS Occupational Outlook Handbook projects overall employment in computer and information technology occupations to grow faster than the average for all occupations from 2025 to 2035, with about 280,000 openings projected each year on average from growth and from replacing workers who leave. BLS put the median annual wage for that whole group at $109,470 in May 2025, against $50,980 for all occupations.

Those numbers describe broad groups rather than this title, so treat them as context. They project growth for computer work as a whole; they do not measure how many employers are hiring people called cloud engineers.

Reliability is a shared problem

The outage record shows why the role carries real accountability. In its Annual outage analysis 2026, Uptime Institute, a digital infrastructure standards and research organization headquartered in New York, reports that over 10 years of tracking publicly reported outages, third-party IT and data center providers, including cloud, telecommunications and colocation companies, have consistently accounted for a majority of incidents. It links that to the continued shift toward outsourced services. The same report found that in 2025, outages involving cloud and internet providers fell below average, which it says likely results from ongoing investments in distributed resiliency.

For the engineer on the customer side, the lesson is that a provider's resilience does not transfer automatically. Multi-zone or multi-region designs, tested failover, and clear runbooks are what keep a provider incident from becoming a company outage.

Compliance reaches the configuration layer

Public-sector work adds its own requirements. CISA issued Binding Operational Directive 25-01, Implementing Secure Practices for Cloud Services, on Dec. 17, 2024. It requires Federal Civilian Executive Branch agencies to implement Secure Configuration Baselines from CISA's SCuBA project for certain widely used software-as-a-service products, deploy CISA-developed automated configuration assessment tools, and remediate deviations. Agencies had to implement the mandatory policies by June 20, 2025. Final baselines first covered Microsoft Office 365; CISA's implementation guidance, updated July 27, 2026, says it has since published final baselines for Google Workspace and may release more for other cloud products. At covered agencies, someone has to run those assessment tools and fix what they flag, and that is cloud configuration work.

Where the path leads

Next steps can include senior and staff cloud engineer, cloud or solutions architect, site reliability engineer, platform engineering lead, and infrastructure management. Cost ownership, security depth or a second platform are worth adding along the way.

Dear Hiring Manager,

I am applying for the Cloud Engineer position on your platform team. For the last three years I have worked as the second of two infrastructure engineers at a regional logistics software company, where I own our Azure environment and a smaller AWS footprint that supports a customer data feed.

When I joined, most of our resources had been created by hand and nobody could say with confidence what a given subscription contained. I imported the core networking, Key Vault and App Service resources into Terraform, split them into modules each product team could reuse, and moved every change behind a pull request with a plan attached. The first month was slow. After that, environment requests that used to take days of back-and-forth became something a developer could open on their own.

Identity was the next project. Several of our deployment scripts ran under a shared user account, which I replaced with managed identities and narrowly scoped service principals. I documented each role assignment so an auditor, or a new teammate, could follow who can change what.

I also took on our cloud bill. I set up a tagging policy, enforced it in the pipeline, and built a weekly report that shows each team its own spend. Those conversations go much better when the data is not in dispute, and two teams found savings on their own once they could see their numbers.

Your posting mentions a move toward self-service infrastructure for product teams. That is the work I enjoy most, and I would welcome the chance to talk about how I could help build it.

Sincerely,

Jordan Ellis