Cloud Security Engineer Job Description

A Cloud Security Engineer makes a company's AWS, Azure or Google Cloud estate defensible by design rather than by after-the-fact inspection. In an information technology organization that means working inside the platform team's world: reading the same Terraform modules and pull requests, and adding the guardrails that stop a public storage bucket, an over-privileged service role or an unlogged account before it ever reaches production. Analysts in the security operations center work the alerts. The cloud security engineer builds much of the machinery that produces them.

Where the line of responsibility falls

The provider secures the hardware, the hypervisor and the internals of its managed services. The customer owns identities, data, network rules and configuration. NSA's Top Ten Cloud Security Mitigation Strategies, issued in March 2024, puts "Uphold the Cloud Shared Responsibility Model" first on its list and states plainly that "Many cloud breaches occur due to misconfigurations in cloud tenants." NSA and CISA released five joint information sheets on March 7, 2024 that expand on individual items, including identity and access management, key management and network segmentation. Closing that gap is the core of the job.

Identity, keys and networks

Identity work is a core part of the job. Engineers design the account or subscription structure, write service control policies and permission boundaries, federate sign-in from the corporate identity provider, and swap long-lived access keys for short-lived role credentials and workload identities. They hunt for privilege-escalation paths, such as a role that can attach a more powerful policy to itself, and they keep break-glass accounts locked down and monitored.

Keys and data follow: customer-managed keys in AWS KMS, Azure Key Vault or Cloud KMS, key policies that separate who can use a key from who can administer it, and classification tags that drive encryption and retention. Network work covers private endpoints, segmentation between production and development, egress filtering and web application firewall rules in front of public APIs.

Detection and response

The engineer makes sure CloudTrail, Azure Activity Logs and Google Cloud Audit Logs are enabled in every account and shipped to a central store that workload owners cannot delete. From there they write detection rules in the SIEM's query language and tune the provider's native threat detection. During an incident they scope the exposure, rotate credentials, write the containment script and later turn the emergency fix into a standing control.

Policy as code and containers

Guardrails ship as code. Rules written in Open Policy Agent's Rego, AWS Config, Azure Policy or Google Cloud organization policies run in the deployment pipeline and continuously against live resources, while a cloud security posture management (CSPM) tool reports drift across accounts. The engineer owns the rule set, the exception process and the conversation with any team whose deploy just failed a check. Kubernetes adds its own layer: RBAC, Pod Security Standards, admission control, image signing and runtime monitoring on EKS, AKS or GKE.

The evidence side

Architecture reviews, threat models for new services and control evidence for SOC 2, PCI DSS or FedRAMP assessors all land on this desk. Because the engineer wrote the control, they are the natural person to show an assessor that it works.

Education

A bachelor's degree in computer science, information systems, cybersecurity or a related engineering field is the usual starting point. O*NET places Information Security Analysts in Job Zone Four and notes that "most of these occupations require a four-year bachelor's degree, but some do not." Engineers without a degree who can show real infrastructure-as-code and security work, in a public repository or a portfolio of past projects, can still compete.

Experience

As a rough guide, people reach a cloud security engineer title after three to six years in cloud or systems engineering, DevOps, site reliability or a security operations role. The common thread is hands-on time running production cloud infrastructure: someone who has been paged for an outage understands why a guardrail that breaks deployments gets ripped out.

Certifications

AWS and Microsoft both changed their cloud security credentials between December 2025 and August 2026, so check the current version before studying.

• AWS Certified Security - Specialty (Amazon Web Services): the SCS-C03 version has been in use since December 2, 2025. AWS says it brings "dedicated focus on generative AI and machine learning security" and splits detection and incident response into separate domains. Identity and access management rose from 16% of scored content on SCS-C02 to 20% on SCS-C03.
• Microsoft Certified: Cloud and AI Security Engineer Associate (SC-500) (Microsoft): it replaced the Azure Security Engineer Associate (AZ-500), which Microsoft retired on August 31, 2026. The replacement became available on July 21, 2026, and Microsoft says a retiring certification completed before its retirement date remains valid for one year.
• Professional Cloud Security Engineer (Google Cloud): Google recommends 3+ years of industry experience, including more than 1 year designing and managing solutions on Google Cloud, and the certification is valid for 2 years.
• Certificate of Cloud Security Knowledge (CCSK) (Cloud Security Alliance): vendor-neutral; version 5 launched on July 16, 2024.
• CCSP, Certified Cloud Security Professional (ISC2) and CISSP (ISC2): vendor-neutral credentials with work-experience requirements, aimed at engineers moving toward architecture or program ownership.
• Certified Kubernetes Security Specialist (CKS) (Cloud Native Computing Foundation): for roles with heavy container scope.
• HashiCorp Certified: Terraform Associate (HashiCorp): useful proof of infrastructure-as-code fluency.

Technical skills

• Identity: AWS IAM policy grammar, Azure RBAC and Microsoft Entra ID, Google Cloud IAM, and the privilege-escalation paths in each
• Infrastructure as code: Terraform or Pulumi modules, state handling and plan review
• Policy as code: Rego, AWS Config rules, Azure Policy
• Detection: KQL, SPL or Sigma rules, plus serverless functions for automated response
• Secrets and keys: AWS Secrets Manager, Azure Key Vault, HashiCorp Vault
• Programming: Python for automation and API work; Go is useful for internal tooling

BLS does not count cloud security engineers on their own. The federal figures that come closest describe Information Security Analysts as a whole, the occupation ONET maps the title to, which had 190,650 jobs in the May 2025 wage survey. ONET rates that occupation's projected growth from 2025 to 2035 as "much faster than average (7% or higher)," with about 14,100 openings a year on average.

Where the jobs are

BLS publishes industry-level wages for the occupation, and three information technology rows are relevant to cloud security work:

• Computer systems design and related services (consultancies, managed service providers, integrators): 43,440 information security analysts, with a May 2025 median of $132,410.
• Computing infrastructure providers, data processing and web hosting (the industry that includes cloud and hosting operators): a median of $129,810 and a 90th percentile of $239,990.
• Software publishers (SaaS and software companies): a median of $144,970.

Those figures cover every information security analyst in those industries, not cloud specialists alone, so treat them as context for where the occupation is paid and employed rather than a pay scale for this title.

What changed by 2026

Two shifts stand out for anyone in or entering the field, on top of the exam changes covered above.

AI workloads are now part of the estate. Model endpoints, vector stores, training data buckets and agent tool permissions sit in the same accounts as everything else, and the providers now publish security guidance for them. Google's current best-practice guide for AI workloads on GKE covers defense against prompt injection attacks alongside the familiar items of workload authentication, network controls and encryption, and describes protecting proprietary assets such as model weights. For the engineer, the practical result is more identity policies, more data classification and a new set of threat models to write.

Control frameworks moved. The Cloud Security Alliance released version 4.1 of its Cloud Controls Matrix on January 27, 2026, describing it as "made up of 207 controls across 17 security domains." The release came with a matching v4.1 of CSA's Consensus Assessment Initiative Questionnaire (CAIQ), so control mappings and questionnaire answers built on the older version may need review. For a cloud security engineer, that is concrete work: each guardrail in the codebase should point to the control it satisfies, and those pointers have to be rechecked whenever the framework moves.

Career paths

O*NET's Job Titles file lists cloud security architect alongside cloud security engineer under the same occupation, and architecture is the obvious next step: owning the reference designs and the multi-year control roadmap rather than individual guardrails. Other routes run toward staff or principal engineer roles that build internal security platforms, toward detection engineering or incident response leadership, and toward security engineering management. Product security at cloud and SaaS companies is another route, where the same skills protect the product customers run on rather than the company's own accounts.

The work rewards people who can write code, talk a platform team into a breaking change and explain a control to an auditor in the same week. Those skills transfer across employers and across clouds.

Dear Hiring Manager,

I am writing to apply for the Cloud Security Engineer opening on your platform security team. For the past three years I have been the security engineer embedded with the infrastructure group at a regional payments processor, where I own the guardrails for our AWS organization and a smaller Azure footprint that came with an acquisition.

The project I am proudest of started with an uncomfortable audit finding: dozens of IAM users with access keys older than a year, several attached to people who had left. Rather than chase owners one by one, I built a short-lived credential path using IAM Identity Center for people and role assumption for pipelines, wrote a Terraform module that every new service now uses to request its role, and added a Config rule that flags any new long-lived key within an hour. Within two quarters the old keys were gone, and the platform team now treats the module as the default rather than a security request.

On the detection side, I moved our CloudTrail and Azure Activity Logs into a dedicated log archive account that application teams cannot modify, then rewrote our noisiest SIEM rules so the on-call analyst sees a short, triaged list instead of raw events. When a contractor's laptop was compromised last spring, those logs let us confirm within an afternoon which roles had been touched and rotate exactly what needed rotating.

I hold the AWS Certified Security - Specialty and am preparing for the Certified Kubernetes Security Specialist, because our next platform migration moves most services onto EKS. Your team's work securing a Kubernetes-heavy, multi-cloud environment is exactly where I want to grow.

Thank you for your time. I would welcome the chance to walk through any of this in more detail.

Sincerely,

Jordan Avery