Skip to content
SkillPilotNavigate Your Career

Cloud Security Engineer Roadmap

A path into cloud security as an engineering discipline, covering the shared responsibility model, identity, network segmentation, encryption, workload hardening, detection, governance as code, threat modelling and incident response.

Entry level
$134,792
Cloud Security Engineer salary estimate, 25th percentile (US, 431 salaries)
Mid level
$169,173
Cloud Security Engineer salary estimate (overall average, US, 431 salaries)
Senior level
$180,921
Senior Cloud Security Engineer salary estimate (average, US, 95 salaries)
Glassdoor

This path assumes working knowledge of one public cloud and comfort on the command line. It treats cloud security as engineering rather than as a review gate — controls you build and test, not findings you file.

The reason identity is the longest phase: in the cloud, identity is the perimeter. There is no network edge to stand behind, and almost every serious cloud breach reduces to a credential or a role that could do more than it needed to. A misconfigured IAM policy outranks an unpatched host.

Detection sits after the preventive phases deliberately. Alerts on a system you have not hardened produce a queue nobody works, and the queue becomes the control.

Expect 9–12 months, the longest path here. Phase five spans containers and supply chain because that is one attack surface, not two.

New to Linux and the command line?

This path assumes fundamentals you may not have yet. Our Foundations Pack is out and free — Linux, the shell and Git, with exercises that mark your work and explain why you got it wrong. We're writing an agents pack next; leave your email if you want to hear when it ships.

One email when the pack launches. No spam, unsubscribe any time.

Your progress0%

The path, phase by phase

  1. Cloud Security Fundamentals

    Every cloud security mistake starts with a wrong answer to one question: who secures this? The line moves between IaaS, PaaS and SaaS, and it moves per service. Done when you can take one real workload, draw the responsibility boundary for every service it uses, and name the controls that fall to you rather than the provider.

    3-4 weeks
    8 Skills
    Shared Responsibility Model
    Cloud Threat Landscape
    Security Design Principles
    Defence in Depth
    Blast Radius Reasoning
    Control Types & Placement
    Cloud Service Taxonomy
    Reading Security Documentation
    Show details, projects and resources

    Skills you'll master

    Shared Responsibility Modelintermediate
    Cloud Threat Landscapeintermediate
    Security Design Principlesintermediate
    Defence in Depthintermediate
    Blast Radius Reasoningadvanced
    Control Types & Placementintermediate
    Cloud Service Taxonomybeginner
    Reading Security Documentationbeginner

    Hands-on projects

    1. 01Take one real workload and draw the shared responsibility boundary per service, naming which controls are yours and which the provider already owns
    2. 02Review a published cloud breach report and classify each contributing failure as a customer-side or provider-side control gap
    3. 03Assess one account against the AWS Well-Architected Security Pillar and record every question you could not answer with evidence
    4. 04Write down the blast radius of your most privileged credential — what it reaches, and what stops it — then verify the answer rather than assuming it
    5. 05Compare the shared responsibility split for the same workload run on IaaS and on a managed equivalent, and say which controls you gave up
    6. 06Build a one-page control map for a service you already run, marking each control as preventive, detective or responsive

  2. Identity & Access Management

    The spine of the whole path. In cloud, identity is the perimeter — the network boundary you inherited from the datacentre no longer decides who reaches what. Done when you have replaced a permissive policy on a real workload with a least-privilege one derived from observed access, and proved the old one granted more than the workload ever used.

    5-6 weeks
    9 Skills
    IAM Policy Authoring
    Least Privilege Derivation
    Roles & Temporary Credentials
    Federation & SSO
    Permission Boundaries & SCPs
    Policy Evaluation Logic
    Workload Identity
    Privilege Escalation Paths
    Access Reviews
    Show details, projects and resources

    Skills you'll master

    IAM Policy Authoringadvanced
    Least Privilege Derivationadvanced
    Roles & Temporary Credentialsadvanced
    Federation & SSOadvanced
    Permission Boundaries & SCPsadvanced
    Policy Evaluation Logicadvanced
    Workload Identityadvanced
    Privilege Escalation Pathsadvanced
    Access Reviewsintermediate

    Hands-on projects

    1. 01Write a least-privilege IAM policy for a real workload from its observed access activity, and prove the previous policy granted permissions it never used
    2. 02Eliminate long-lived access keys from one workload by moving it to role-based temporary credentials, and confirm no key remains by auditing the account
    3. 03Trace the policy evaluation for a request that is denied and explain which of identity policy, resource policy, boundary and SCP produced the deny
    4. 04Map the privilege escalation paths inside one account — which role can grant itself more — and close the highest-risk one
    5. 05Implement a permissions guardrail with an SCP, test it on a single account before the organisation, and document what it broke
    6. 06Run an access review that removes unused roles and permissions, and report the percentage of privileges withdrawn

  3. Network Security in the Cloud

    The network is no longer the perimeter, but it is still a control. Segmentation, private connectivity and egress restriction limit what a compromised workload can reach next. Done when you have segmented a real environment so one workload cannot reach a service it has no reason to call, and demonstrated the block with a connection test rather than a diagram.

    4-5 weeks
    8 Skills
    VPC & Subnet Design
    Security Groups & NACLs
    Network Segmentation
    Egress Control
    Private Endpoints
    TLS & Certificate Management
    Flow Log Analysis
    DNS Security
    Show details, projects and resources

    Skills you'll master

    VPC & Subnet Designadvanced
    Security Groups & NACLsintermediate
    Network Segmentationadvanced
    Egress Controladvanced
    Private Endpointsadvanced
    TLS & Certificate Managementintermediate
    Flow Log Analysisadvanced
    DNS Securityintermediate

    Hands-on projects

    1. 01Segment an environment so one workload cannot reach a service it has no reason to call, and prove the block with a connection test
    2. 02Restrict egress on a workload that previously had open internet access, then find every dependency the restriction broke and allow only those
    3. 03Replace public service access with private endpoints so traffic never traverses the internet, and verify with flow logs that it no longer does
    4. 04Enable flow logs and use them to find one connection nobody could justify, then remove the path that allowed it
    5. 05Audit security groups for rules allowing 0.0.0.0/0, and for each one either close it or write down why it must stay
    6. 06Enforce TLS on a service using a policy condition rather than trusting clients to opt in, and confirm plaintext requests are rejected

  4. Data Protection & Encryption

    Encryption is easy to enable and easy to get wrong, because the interesting question is never the cipher — it is who can use the key. Done when you have encrypted a real dataset with a customer-managed key, written a key policy that denies access to an identity that can read the data store, and shown the denial in practice.

    4-5 weeks
    8 Skills
    Key Management Services
    Key Policies & Grants
    Envelope Encryption
    Encryption at Rest & in Transit
    Secrets Management
    Data Classification
    Key Rotation & Lifecycle
    Exfiltration Controls
    Show details, projects and resources

    Skills you'll master

    Key Management Servicesadvanced
    Key Policies & Grantsadvanced
    Envelope Encryptionadvanced
    Encryption at Rest & in Transitintermediate
    Secrets Managementadvanced
    Data Classificationintermediate
    Key Rotation & Lifecycleadvanced
    Exfiltration Controlsadvanced

    Hands-on projects

    1. 01Encrypt a dataset with a customer-managed key and write a key policy that denies an identity which can otherwise read the store, then demonstrate the denial
    2. 02Move hardcoded credentials out of an application into a secrets manager, then grep the repository history to find the ones still committed
    3. 03Implement key rotation for one key and verify that data encrypted before rotation is still readable afterwards
    4. 04Classify the data in one system into tiers, and apply a different control set to each tier rather than the same one everywhere
    5. 05Block public access on an object store at the account level, then attempt to make a bucket public and confirm the guardrail wins
    6. 06Write the exfiltration control for one sensitive store — a policy restricting which network paths and identities can read it — and test it from outside

  5. Workload, Container & Supply Chain Security

    Where the code actually runs, and where the software you did not write arrives. Image hardening, runtime restriction and build provenance. Done when you have hardened a container workload so it runs unprivileged with a read-only filesystem, and can produce the signed provenance for the image running in production.

    5-6 weeks
    9 Skills
    Container Image Hardening
    Pod Security Standards
    Kubernetes RBAC
    Admission Control
    Vulnerability Scanning
    Software Supply Chain & SBOM
    Build Provenance
    Runtime Hardening
    Serverless Security
    Show details, projects and resources

    Skills you'll master

    Container Image Hardeningadvanced
    Pod Security Standardsadvanced
    Kubernetes RBACadvanced
    Admission Controladvanced
    Vulnerability Scanningintermediate
    Software Supply Chain & SBOMadvanced
    Build Provenanceadvanced
    Runtime Hardeningadvanced
    Serverless Securityintermediate

    Hands-on projects

    1. 01Harden a container workload to run unprivileged with a read-only root filesystem and dropped capabilities, and confirm it still works under load
    2. 02Enforce the restricted Pod Security Standard on a namespace, then find every existing workload it rejects and fix them rather than exempting them
    3. 03Generate an SBOM for one application and identify which dependencies you could not attribute to a known source
    4. 04Sign build artefacts and verify the signature at deploy time, so an unsigned image cannot reach the cluster
    5. 05Write Kubernetes RBAC for one team that grants only the verbs they use, and check it against the cluster-admin binding it replaces
    6. 06Add an admission policy that blocks a specific unsafe configuration, and record how many existing manifests it would have caught

  6. Detection & Security Monitoring

    Prevention fails eventually, and the only thing separating a contained incident from a breach report is whether anyone noticed. Audit logs, threat detection and the queries that turn them into findings. Done when you have written a detection that fires on a simulated misuse in your own account, and tuned it until it stops firing on normal activity.

    4-5 weeks
    8 Skills
    Audit Logging
    Threat Detection Services
    Detection Engineering
    SIEM & Log Pipelines
    MITRE ATT&CK Mapping
    Alert Triage & Tuning
    Log Integrity & Retention
    Baseline & Anomaly Detection
    Show details, projects and resources

    Skills you'll master

    Audit Loggingadvanced
    Threat Detection Servicesadvanced
    Detection Engineeringadvanced
    SIEM & Log Pipelinesadvanced
    MITRE ATT&CK Mappingadvanced
    Alert Triage & Tuningadvanced
    Log Integrity & Retentionintermediate
    Baseline & Anomaly Detectionintermediate

    Hands-on projects

    1. 01Write a detection that fires on a simulated misuse in your own account, then tune it until normal activity stops triggering it
    2. 02Enable organisation-wide audit logging with tamper-resistant storage, and verify an administrator cannot quietly delete a log
    3. 03Map your current detections to MITRE ATT&CK cloud techniques and name the three highest-risk gaps
    4. 04Take a week of findings from a managed threat detection service and triage each one, recording how many were actionable
    5. 05Build a log pipeline that routes security events to a queryable store, and answer a question about last month using only that store
    6. 06Measure how long it takes you to answer "which identity made this change?" for a real change, and shorten it

  7. Compliance & Governance as Code

    Compliance is where cloud security most often degenerates into a questionnaire. The engineering version is a control that enforces itself and emits its own evidence. Done when you have expressed one written control as executable policy, blocked a non-compliant change with it, and produced the audit evidence automatically rather than by screenshot.

    3-4 weeks
    8 Skills
    Policy as Code
    Open Policy Agent & Rego
    Configuration Compliance
    Control Frameworks
    Continuous Evidence Collection
    IaC Security Scanning
    Drift Detection & Remediation
    Exception Management
    Show details, projects and resources

    Skills you'll master

    Policy as Codeadvanced
    Open Policy Agent & Regoadvanced
    Configuration Complianceadvanced
    Control Frameworksintermediate
    Continuous Evidence Collectionadvanced
    IaC Security Scanningadvanced
    Drift Detection & Remediationadvanced
    Exception Managementintermediate

    Hands-on projects

    1. 01Express one written control as executable policy, block a non-compliant change with it, and generate the audit evidence without a screenshot
    2. 02Add infrastructure-as-code scanning to a pipeline, then measure its false-positive rate before you make it blocking
    3. 03Detect configuration drift on a resource somebody changed by hand, and automate the correction with an audit trail
    4. 04Map one compliance framework's controls to the technical checks that actually enforce them, and mark the ones with no automated check at all
    5. 05Build a continuous compliance dashboard that reports control coverage as a percentage rather than a pass or fail
    6. 06Design an exception process for a guardrail, including expiry, so temporary exemptions do not become permanent

  8. Threat Modelling Cloud Architectures

    A defensive discipline that borrows an attacker's perspective. You model a system, ask what can go wrong, and decide what to do about it — before the design is concrete. Done when you have threat modelled a real architecture, ranked the threats, and shipped a mitigation for the highest-ranked one that the design review would otherwise have missed.

    3-4 weeks
    8 Skills
    Threat Modelling Methodology
    STRIDE
    Data Flow Diagramming
    Trust Boundary Identification
    Attack Path Analysis
    Risk Ranking
    Secure Design Review
    Mitigation Selection
    Show details, projects and resources

    Skills you'll master

    Threat Modelling Methodologyadvanced
    STRIDEadvanced
    Data Flow Diagrammingintermediate
    Trust Boundary Identificationadvanced
    Attack Path Analysisadvanced
    Risk Rankingadvanced
    Secure Design Reviewadvanced
    Mitigation Selectionintermediate

    Hands-on projects

    1. 01Threat model a real architecture with STRIDE, rank the threats, and ship a mitigation for the top one that a normal design review would have missed
    2. 02Draw the data flow diagram for a system you run and mark every trust boundary, then check whether a control exists at each one
    3. 03Analyse the attack path from a compromised low-privilege workload to your most sensitive data store, and break the path at its cheapest link
    4. 04Run a threat modelling session with the engineers who own a service, and record which threats they raised that you had not
    5. 05Re-threat-model a system after a real design change, and note which mitigations the change invalidated
    6. 06Write the secure design review checklist your team applies before a new service ships, and run it against one already in production

  9. Incident Response in the Cloud

    Cloud incident response breaks the habits built on physical machines: the host you want to image may be gone, and the evidence lives in an API. Done when you have run a simulated incident end to end — contained a compromised identity, preserved evidence, and written the timeline from logs — and can state how long containment took.

    3-4 weeks
    8 Skills
    Cloud Incident Response
    Credential Compromise Containment
    Forensic Evidence Preservation
    Timeline Reconstruction
    Automated Response
    Runbook Authoring
    Blameless Postmortems
    Incident Communication
    Show details, projects and resources

    Skills you'll master

    Cloud Incident Responseadvanced
    Credential Compromise Containmentadvanced
    Forensic Evidence Preservationadvanced
    Timeline Reconstructionadvanced
    Automated Responseadvanced
    Runbook Authoringintermediate
    Blameless Postmortemsintermediate
    Incident Communicationintermediate

    Hands-on projects

    1. 01Run a simulated incident end to end — contain a compromised identity, preserve evidence, reconstruct the timeline from logs — and report the containment time
    2. 02Write the runbook for a leaked credential, then have someone unfamiliar with the account follow it while you say nothing
    3. 03Preserve forensic evidence from an ephemeral workload before it is replaced, and document what you lost anyway
    4. 04Automate one containment action — isolating a resource or revoking a session — with an audit log and a way to disable it quickly
    5. 05Reconstruct the full timeline of a change made in your account using only audit logs, and note every question the logs could not answer
    6. 06Run a blameless postmortem for a simulated incident, with an owner and a date on every action item

  10. Security at Organisational Scale

    The multiplier. Securing one account is engineering; making a hundred accounts secure by default is what changes an organisation. Landing zones, account structure and guardrails inherited rather than applied. Done when a team you do not sit with shipped into your landing zone and inherited its controls without you reviewing the change.

    4-5 weeks
    8 Skills
    Landing Zone Design
    Multi-Account Strategy
    Organisational Guardrails
    Secure Baselines
    Paved Road Platforms
    Security Metrics & Reporting
    Developer Enablement
    Influence Without Authority
    Show details, projects and resources

    Skills you'll master

    Landing Zone Designadvanced
    Multi-Account Strategyadvanced
    Organisational Guardrailsadvanced
    Secure Baselinesadvanced
    Paved Road Platformsadvanced
    Security Metrics & Reportingadvanced
    Developer Enablementintermediate
    Influence Without Authorityintermediate

    Hands-on projects

    1. 01Build a landing zone a team can ship into and inherit its controls without you reviewing the change, then confirm one team did exactly that
    2. 02Design an account structure that isolates production from everything else, and migrate one real workload into it
    3. 03Publish a secure baseline other teams consume as a module rather than as documentation, and count adoptions after you stop promoting it
    4. 04Define the five security metrics you report to leadership, with the query behind each so nobody recalculates them by hand
    5. 05Make the secure path the easy path for one common task, then measure whether the insecure path is still being used
    6. 06Run a security review with a team you do not manage and record which decisions changed without you escalating

What the job is actually like

Day to day
Split between building and reviewing, and the ratio tells you whether the job is a good one. Building looks like writing policy as code, wiring detection rules, and closing an identity gap a scan surfaced. Reviewing looks like reading pull requests and design docs for the thing that will be hard to change later — a permission granted broadly because it was easier, a bucket whose safety rests on the network rather than on identity. Underneath runs a steady current of alerts, most of them noise, and one of the quiet skills is deleting a detection rather than tuning it forever. On-call exists in most teams and it is real.
The interview
Expect a cloud-specific scenario rather than security theory: here is an account, here is a finding, what is the blast radius and what do you do first. Identity comes up in nearly every round, because it is where cloud security is actually won or lost, and a candidate who reaches for network controls first is signalling an on-premises mental model. A code round is common — reading a Terraform or policy file for what it permits rather than what it says. Incident response is probed for method, not heroics. Certifications carry more weight here than in most engineering hiring, and the specialty ones get asked about by name.
How people get in
Three routes, and the middle one is the most common. Traditional security engineers arrive with the threat modelling and have to unlearn the perimeter. Cloud, DevOps and platform engineers arrive knowing how the infrastructure actually works and have to learn to think adversarially — the largest group, and usually the fastest to become useful. A smaller number come from compliance and audit, strong on frameworks and needing the engineering. What transfers from any of them is being able to read infrastructure code. What does not is assuming a control exists because a document says it does.
After senior
The technical fork leads to security architecture, setting the patterns rather than reviewing each use of them, and it overlaps heavily with the cloud architect path. A second fork specialises: detection engineering, incident response, or the AI security work currently pulling engineers out of this discipline faster than it replaces them. A third is security leadership, which arrives earlier here than on most engineering ladders because the field is short of people who can both build and explain. The certification ladder is unusually well defined at every one of those steps, which is rare and worth using.
Why people leave
Alert fatigue is the one everybody names and the one that actually ends careers here — a queue that is mostly noise trains you to close things fast, which is exactly the habit that misses the real one. The structural version is a team measured on findings raised rather than risk removed. The second failure is becoming a gate: security that only says no gets excluded from the design conversation, then blamed for what ships without it. The third is a compliance-shaped job wearing an engineering title, where the work is producing evidence for an auditor and the systems never actually get safer.

Frequently asked questions

Related certifications

Related roadmaps