Cloud Security Roadmap

Cloud computing means renting computing power, storage, and software over the internet from a provider instead of buying and operating your own physical servers. You pay for what you use, capacity can grow or shrink on demand, and the provider handles the physical data center you never see or touch. Every other concept in this roadmap builds on this one shift from owning infrastructure to renting it as a metered service.

Infrastructure as a Service (IaaS) gives you raw virtual machines, storage, and networking that you configure yourself, such as AWS EC2 or GCP Compute Engine. Platform as a Service (PaaS) hands you a managed runtime where you deploy code without touching the underlying servers, such as AWS Elastic Beanstalk or Google App Engine. Software as a Service (SaaS) is a finished application you simply use, such as Gmail or Slack. As you move from IaaS toward SaaS you control less of the stack, but you also inherit less responsibility for securing it.

A public cloud is infrastructure owned by a third-party provider and shared across many customers, like AWS or GCP. A private cloud is dedicated to a single organization, either self-hosted or hosted by a provider on isolated hardware. A hybrid cloud connects on-premises infrastructure with a public cloud, often to keep sensitive workloads local while bursting capacity to the cloud. Multi-cloud means deliberately using more than one public cloud provider, which this roadmap prepares you for by covering both AWS and GCP.

Virtualization lets one physical server run many isolated virtual machines, each with its own operating system, by inserting a layer called a hypervisor between the hardware and the guest OS. This is the technology that makes multi-tenant cloud computing economically possible: a provider can carve one machine into many billable, isolated units. Understanding this layer matters for security because a flaw that breaks isolation between virtual machines on the same physical host is one of the most severe classes of cloud infrastructure risk.

A virtual machine virtualizes an entire computer, including its own kernel, which makes it heavyweight but strongly isolated. A container instead packages an application with its dependencies and shares the host operating system's kernel, which makes it lightweight and fast to start but means isolation between containers is weaker by default than between VMs. Docker popularized containers, and Kubernetes (offered as EKS on AWS and GKE on GCP) is the dominant system for running many containers reliably at scale.

A region is a geographic area, such as 'US East' or 'Europe West,' containing multiple physically separate data centers called availability zones. Availability zones within the same region are close enough for fast, low-latency connections but far enough apart that a fire, flood, or power outage in one is unlikely to take down another. Spreading resources across zones is how cloud architectures achieve resilience, and understanding this layout is a prerequisite for reasoning about data residency, latency, and disaster recovery.

A content delivery network (CDN) caches copies of content at edge locations physically closer to end users, so a request does not need to travel all the way to a distant region to be served. This reduces latency and absorbs traffic spikes before they ever reach your origin servers. CloudFront on AWS and Cloud CDN on GCP are the major examples, and they also double as a first line of defense against certain denial-of-service and web attacks, which later stages cover.

The shared responsibility model draws a line between what the cloud provider secures and what you, the customer, must secure yourself. In simple terms, the provider is responsible for the security 'of' the cloud — the physical data centers, hardware, and core infrastructure — while you are responsible for security 'in' the cloud, meaning how you configure identity, network access, and data protection on top of it. This single concept explains why the overwhelming majority of real-world cloud breaches trace back to customer misconfiguration rather than a failure by the provider, and it gets a full deep dive in the next stage.

CIDR (Classless Inter-Domain Routing) notation, like 10.0.0.0/16, expresses an IP address range as a base address plus a prefix length that says how many bits are fixed for the network portion. Subnetting takes a larger address block and divides it into smaller ranges, each of which can be assigned different routing and access rules. You cannot design a secure cloud network — deciding what should and should not be reachable from the internet — without being fluent in reading and writing CIDR blocks.

A public subnet has a route to an internet gateway, so resources inside it can be reached from the internet if their other settings allow it. A private subnet has no such direct route, so resources inside it can only be reached from within the network or through a controlled path like a load balancer or bastion host. The standard secure pattern places internet-facing components like load balancers in a public subnet while keeping databases and application servers in private subnets, drastically shrinking what an outside attacker can even attempt to reach.

DNS (Domain Name System) translates human-readable names like example.com into the IP addresses computers actually use to route traffic. In the cloud, DNS also plays a security role: it is how load balancers get friendly names, how services discover each other, and how attackers sometimes hijack traffic by manipulating or exploiting stale DNS records. Understanding record types like A, CNAME, and TXT is assumed knowledge in nearly every cloud networking and security document you will read from here on.

A load balancer sits in front of a group of servers and distributes incoming traffic across them, so no single server is overwhelmed and traffic can keep flowing even if one server fails. In cloud architectures a load balancer is also frequently the only component directly exposed to the internet, with everything behind it living in private subnets — which makes the load balancer's own configuration, including its listeners, TLS settings, and attached web application firewall, a high-value point to get right.

A VPN (Virtual Private Network) creates an encrypted tunnel over the public internet so traffic between two points, such as your laptop and a cloud network, cannot be read or tampered with in transit. Cloud providers also offer site-to-site VPN options to connect an entire on-premises network to a cloud network, and dedicated private-line services for organizations that need guaranteed bandwidth without touching the public internet at all. Knowing this distinction matters because it defines the realistic set of paths an attacker could use to reach otherwise 'private' cloud resources.

In a traditional on-premises data center, the network perimeter — firewalls at the edge of a building or campus — was the primary security boundary, and most trust was assumed once you were 'inside.' In the cloud, there is no physical perimeter to defend: every resource is reachable via an API call, identity and configuration are the real boundary, and a single misissued permission or public storage bucket can expose data to the entire internet instantly. This is why identity and configuration management, not network firewalls alone, become the center of gravity for cloud security.

'Compute' is the umbrella term for anything that runs your code or workloads: virtual machines, containers, and serverless functions all fall under it. When a cloud document says 'compute resources' it generally means the things that consume CPU and memory to actually execute work, as distinct from storage (which holds data at rest) or networking (which moves data between things). Getting comfortable with this vocabulary now will make every service-specific stage later far easier to follow.

Cloud storage generally comes in three flavors: object storage (like AWS S3 or GCP Cloud Storage) for storing files and blobs accessed over HTTP APIs, block storage (like AWS EBS or GCP Persistent Disk) that behaves like a virtual hard drive attached to a VM, and file storage that provides a shared network filesystem. Object storage in particular deserves early attention because misconfigured object storage buckets are one of the single most common sources of real-world cloud data breaches.

A 'managed service' is one where the cloud provider operates the underlying software for you — a managed database, for instance, means the provider handles patching, backups, and replication while you just use it. 'Serverless' takes this further: with services like AWS Lambda or GCP Cloud Functions, you deploy only your code and the platform handles provisioning, scaling, and even turning off compute entirely when nothing is running. Serverless does not mean there are no servers; it means you never have to think about them.

Running your own database on a virtual machine gives you full control but makes you responsible for patching, backups, replication, and every security setting. Using a managed database service shifts that operational burden to the provider in exchange for less flexibility and a different, narrower set of things you are still responsible for, like access policies and encryption keys. Recognizing which category a service falls into is the fastest way to know where your responsibility actually starts within the shared responsibility model.

Before moving on, make sure you can define in your own words: instance, image, snapshot, endpoint, API, SDK, provisioning, and orchestration. These terms appear constantly across every provider's documentation with only minor variations in meaning, and pausing here to nail them down will save far more time later than it costs now, since the rest of this roadmap assumes fluency with this vocabulary.

Confidentiality means only authorized parties can read data, integrity means data cannot be altered undetected, and availability means systems keep working when legitimate users need them. In the cloud these translate concretely: confidentiality is enforced through IAM policies and encryption, integrity through checksums, versioning, and audit trails, and availability through redundancy across availability zones and protection against denial-of-service traffic. Every security control you will learn about in this roadmap exists to strengthen one or more of these three properties.

The line between provider and customer responsibility moves depending on the service model. For IaaS (like a raw EC2 instance) you are responsible for the guest OS, network configuration, and everything above the hypervisor. For PaaS (like a managed database) the provider takes on OS and runtime patching, leaving you responsible mainly for access control and data. For SaaS (like an email platform) the provider runs almost everything, but you are still fully responsible for your own user access management and how you configure the application's security settings. Misunderstanding where this line sits for a specific service is one of the most common root causes of real breaches.

Cloud-native attacks differ from classic on-prem attacks in both speed and starting point: instead of scanning a network perimeter, attackers often start by hunting for exposed credentials, overly permissive IAM roles, or publicly accessible storage found through automated internet-wide scanning. Once inside, attackers commonly pivot through identity — using one compromised role to assume another with broader permissions — rather than through traditional lateral movement across a flat network. Framing your mental model around identity and API access, rather than network position, will make every later stage click faster.

Across the industry, the largest share of publicly disclosed cloud security incidents trace back not to a flaw in the provider's platform but to a customer mistake: a storage bucket left public, a security group left open to the entire internet, or an IAM policy granted far more access than intended. The provider's infrastructure is generally extremely well defended; the weak point is almost always how a specific customer configured it. This is precisely why this roadmap spends so much more time on configuration hardening than on provider platform vulnerabilities.

Because every cloud resource is reachable through an authenticated API call rather than through physical network proximity, the question 'who is allowed to do what' replaces 'what is allowed to connect to what' as the primary security question. A single over-privileged IAM role or leaked access key can grant an attacker capabilities that no network firewall was ever positioned to stop. This is the conceptual thread that ties together the entire IAM Core stage that follows.

A handful of patterns recur across almost every real-world cloud incident: credential exposure (keys committed to a public repository), privilege escalation (using a permission you legitimately have to grant yourself one you should not have), data exposure through public storage or snapshots, and lateral movement between accounts or roles once an initial foothold is gained. Recognizing these patterns by name now means you will spot them immediately in the provider-specific hardening stages ahead, instead of encountering each as an unfamiliar surprise.

Identity and Access Management (IAM) is the system every cloud provider uses to decide who (a human, a service, an application) can do what (an action, like reading a file) to which resource. It is built from identities, permissions, and policies that bind the two together, and it is deliberately the very next stage in this roadmap because so much of cloud security in practice reduces to getting IAM right.

Encryption at rest protects data while it is stored on disk, so that if the underlying storage medium were somehow accessed directly, the data would be unreadable without the correct key. Most managed cloud storage and database services offer this as a checkbox-simple setting, but understanding what it actually protects against — physical media theft or provider-side storage compromise, not a misconfigured access policy — is important so you do not mistake it for a substitute for access control.

Encryption in transit, almost always implemented with TLS, protects data while it travels across a network so it cannot be read or altered by anyone positioned between the sender and receiver. In the cloud this applies not just to traffic between your users and your application, but also to traffic between internal services, which is easy to overlook when everything appears to live 'inside' a private network that feels implicitly trusted.

Envelope encryption solves a practical key management problem: instead of encrypting large amounts of data directly with a master key, you generate a unique data key for each piece of data, encrypt the data with that key, and then encrypt the (small) data key itself with the master key stored in a managed key service. This means the expensive, sensitive master key never has to touch large volumes of data directly, and it can be rotated or have its access revoked without needing to re-encrypt everything it ever touched.

A Key Management Service (KMS) is a dedicated, hardened service for creating, storing, rotating, and controlling access to the encryption keys used throughout your cloud environment. Rather than every application handling its own cryptographic keys — a recipe for keys ending up hardcoded, logged, or leaked — a KMS centralizes key material behind an access-controlled API and, in most implementations, ensures the raw key material never leaves specialized hardware. Understanding this concept up front makes both AWS KMS and GCP Cloud KMS, covered in later stages, immediately intuitive.

Every major cloud provider offers a service that records every API call made against your account: who made it, from where, when, and what the result was. This audit trail is not optional bookkeeping — it is frequently the only way to detect that a breach happened at all, to reconstruct what an attacker did, and to prove compliance with regulatory requirements. A cloud environment with logging disabled or misconfigured is effectively flying blind, regardless of how well everything else is locked down.

Compliance frameworks are external sets of security and privacy requirements — sometimes legally mandated, sometimes contractually required by customers or partners — that an organization must demonstrate it meets. In the cloud, meeting a framework typically means proving both that the provider's infrastructure is certified (which the provider publishes evidence for) and that you configured your own account in a compliant way (which is your responsibility). Compliance is not the same thing as security, but a well-designed framework is a useful checklist of security practices that matter.

SOC 2 focuses on how a service organization protects customer data across security, availability, and confidentiality. ISO 27001 is an international standard for an information security management system. PCI DSS governs anyone handling payment card data. HIPAA governs health information in the United States, and GDPR governs personal data of individuals in the European Union. You do not need to memorize their clauses yet, only recognize which domain each one governs so that later references to them make immediate sense.

A Cloud Security Posture Management (CSPM) tool continuously scans a cloud account's actual configuration against a set of security best practices and compliance benchmarks, flagging things like public storage buckets, disabled logging, or overly permissive IAM policies. CSPM tools do not stop an attack in progress; they exist to catch the misconfigurations that would let one happen, which — given that misconfiguration is the leading cause of breaches — makes them one of the highest-leverage tools you can add to a cloud security practice. Prowler and ScoutSuite are widely used free, open-source examples you will get hands-on with in later stages.

Data classification means labeling data by sensitivity — public, internal, confidential, restricted — before deciding how to protect it, because applying uniform maximum protection everywhere is expensive and applying uniform minimal protection everywhere is dangerous. In practice this means knowing which storage buckets, database tables, or log streams contain sensitive information so that encryption, access restrictions, and monitoring can be prioritized where they matter most, rather than spread evenly and thinly across everything.

Responding to a cloud security incident follows the same broad phases as traditional incident response — detect, contain, eradicate, recover, and learn — but the mechanics differ: containment might mean revoking a credential or isolating a resource via API in seconds rather than physically unplugging a cable, and evidence lives in audit logs rather than on a seized hard drive. Knowing this exists as a discipline now will make the logging, monitoring, and detection services covered later feel purposeful rather than abstract.

Security-by-design means building access control, encryption, and logging into a system from the first architecture decision, rather than bolting them on after something is already running in production. In cloud environments this is especially practical because most of these controls are just configuration, not custom-built software — meaning there is rarely a good excuse for deferring them. Carrying this mindset forward is what turns this roadmap from a list of facts into an actual practice you apply on every project.

Least privilege means granting an identity only the exact permissions it needs to do its job, and nothing more. In practice this is far harder than it sounds: it is always faster to grant broad access and move on, and that shortcut is exactly why over-permissioned identities are so common in real cloud environments. Every IAM hardening technique in this roadmap is, at its core, a technique for approximating least privilege more closely.

Role-Based Access Control (RBAC) grants permissions by assigning identities to predefined roles, each bundling a fixed set of permissions, like 'database-admin' or 'read-only-auditor.' Attribute-Based Access Control (ABAC) instead grants permissions dynamically based on attributes — tags on the resource, tags on the identity, or contextual conditions like time of day — evaluated at request time. RBAC is simpler to reason about and audit; ABAC scales better in large, fast-changing environments because you tag resources and identities once instead of managing an ever-growing list of roles.

A user represents a single human identity. A group is a collection of users that lets you assign permissions once and have them apply to everyone in it. A role is a set of permissions that can be assumed temporarily by a user, application, or another role, rather than being permanently attached to an identity. A service account (or its AWS equivalent, an IAM role for a service) represents a non-human identity — an application or workload — and is how most machine-to-machine access in the cloud is actually granted.

Federation lets users authenticate with one trusted identity provider — a company's existing directory, for example — and use that single identity to access multiple separate systems, including cloud provider consoles, without creating and managing a separate password for each one. Single sign-on (SSO) is the user-facing result of federation: log in once, gain access everywhere it has been configured. For organizations, federation is a security win because it means access can be revoked centrally the moment someone leaves, rather than chasing down accounts across a dozen separate systems.

SAML (Security Assertion Markup Language) is an older but still widely used XML-based standard for exchanging authentication and authorization data between an identity provider and a service provider. When you log into a cloud console through your company's SSO portal and get redirected back in already authenticated, SAML is very often the protocol making that handoff happen behind the scenes, using digitally signed assertions the service provider can trust without needing to verify a password itself.

OpenID Connect is a modern, JSON- and REST-based identity layer built on top of the OAuth 2.0 authorization framework, widely used for both human single sign-on and, importantly for cloud security, for letting workloads outside the cloud (like a CI/CD pipeline) authenticate without ever storing a long-lived cloud credential. OIDC issues signed tokens that a cloud provider can verify came from a trusted issuer, which is the exact mechanism behind workload identity federation covered later in the AWS and GCP security stages.

Multi-factor authentication (MFA) requires proving your identity with more than one independent factor — typically something you know (a password) plus something you have (a hardware key or authenticator app) or something you are (biometrics). Enabling MFA on every human identity with meaningful access, and especially on any account with administrative privileges, is one of the single most effective controls against credential-based compromise, because a stolen password alone is no longer sufficient for an attacker.

A long-lived credential, like a traditional access key, remains valid indefinitely until someone manually rotates or revokes it — which in practice often never happens, leaving a permanently valid secret sitting in code, config files, or a developer's laptop. A temporary credential, obtained by assuming a role, automatically expires after a short window, typically minutes to hours, drastically shrinking the useful lifetime of any single leaked credential. Modern cloud security practice treats long-lived keys as a last resort, not a default.

Secrets — database passwords, API keys, tokens, certificates — need to exist somewhere for applications to use, but hardcoding them into source code or configuration files means they end up in version control history, build logs, and backups indefinitely. A dedicated secrets management service stores secrets encrypted, controls exactly which identities can retrieve them, and can automatically rotate them on a schedule, which turns 'a secret leaked once' from a permanent liability into a temporary one.

Privilege escalation in cloud IAM does not usually mean exploiting a software bug — it means using a permission you were legitimately granted to obtain a broader permission you were not supposed to have. Classic examples include an identity with permission to modify its own policy, permission to create a new identity and attach an administrative policy to it, or permission to pass a highly privileged role to a service it controls. Understanding these patterns in the abstract now makes the AWS- and GCP-specific escalation paths in later stages far easier to recognize and defend against.

When multiple policies apply to the same request, cloud providers evaluate them using a consistent logic: by default everything is denied, an explicit allow in any applicable policy grants access, but an explicit deny in any applicable policy overrides every allow, no matter where else that allow came from. This means a single explicit deny statement is the strongest possible tool for guaranteeing an action can never happen, which is exactly why guardrail policies (like AWS SCPs or GCP Organization Policies) rely on explicit denies rather than trying to avoid granting allows everywhere.

A break-glass account is a highly privileged emergency-access identity, kept deliberately separate from everyday federated or SSO-based access, for the rare case where the normal identity provider is unreachable or compromised and someone still needs to get into the cloud account to fix things. These accounts should be protected with strong, unique credentials and hardware MFA stored securely offline, used only in genuine emergencies, and every use should trigger an alert and a subsequent access review, since by design they bypass the organization's usual access controls.

Machine identities — service accounts, workload roles, application credentials — now outnumber human identities in most cloud environments by a wide margin, yet they are frequently secured more loosely because no single person feels directly responsible for them. Applying the same discipline to machine identities as to human ones — least privilege, credential rotation or elimination of static credentials, and regular access review — closes a gap that attackers increasingly target precisely because it tends to be overlooked.

Instead of granting standing elevated permissions that sit active around the clock, just-in-time access grants a specific elevated permission for a limited time window, only when it is actually needed and often only after an approval step. This shrinks the window during which a privileged identity could be misused, whether by an external attacker who compromised it or by legitimate insider error, and is considered an advanced but increasingly standard practice for the most sensitive permissions in mature cloud environments.

Cross-account access lets an identity in one cloud account assume a role in a different account, which is the standard mechanism for letting a security team's tooling account inspect or manage resources in many separate workload accounts, or for a third-party vendor to be granted narrow, auditable access without ever receiving a standing credential in your environment. It is a powerful and legitimate pattern, but it is also a common attack vector when the trust relationship granting that access is configured more broadly than intended.

Identity lifecycle management covers what happens to an identity's access over its entire life: provisioning access when someone joins, adjusting it as their role changes, and — critically — fully revoking it the moment they leave or a service is decommissioned. The 'leaver' step is the one most often neglected in practice, and orphaned accounts or credentials belonging to people who left the organization months or years ago are a recurring finding in real-world cloud security reviews.

An AWS account is the fundamental unit of isolation and billing in AWS: resources, permissions, and costs are all scoped to a specific account by default. Most real organizations use many AWS accounts rather than one — separating production from development, or separating teams from each other — because account boundaries provide a strong, hard-to-accidentally-cross isolation layer that permissions alone do not reliably provide.

AWS Organizations lets you centrally manage multiple AWS accounts as a single hierarchy, with a management account at the top and member accounts arranged into organizational units below it. It enables consolidated billing across all accounts and, more importantly for security, lets you apply guardrail policies across many accounts at once instead of configuring each one individually — a capability the AWS security stage builds on heavily with service control policies.

The root user is created automatically with a new AWS account and has unrestricted access that cannot be limited by any policy, making it the single highest-value target in the entire account. Best practice is to enable hardware or virtual MFA on it immediately, avoid generating access keys for it entirely, use it only for the small handful of tasks that genuinely require the root user, and do all day-to-day work through an individual IAM identity instead.

An AWS IAM user is an identity for a person or application within a single account, and an IAM group is a way to attach the same permissions to many users at once by adding them to it. AWS documentation and best practices increasingly steer away from standing IAM users with long-lived passwords or keys in favor of federated access through IAM Identity Center, but understanding users and groups is still essential since they remain common in existing environments and simpler setups.

An AWS IAM role is an identity with permission policies attached that is not tied to one specific person or application — instead, it is assumed temporarily by whoever is trusted to do so, whether that is a human, an EC2 instance, a Lambda function, or an identity in another AWS account. Roles are the backbone of the temporary-credential pattern covered in the IAM Core stage, and learning to configure a role's trust policy (who can assume it) separately from its permissions policy (what it can do once assumed) is essential.

An AWS IAM policy is a JSON document made of statements, each specifying an effect (Allow or Deny), one or more actions (like s3:GetObject), one or more resources the action applies to, and optionally conditions that narrow when the statement applies. Reading and writing these documents fluently is a foundational AWS skill, since nearly every hardening technique in the AWS security stage comes down to writing a tighter, more specific policy.

AWS lets you configure billing alarms that notify you when spending crosses a threshold you define, which serves two purposes for a learner: it protects you from an unexpectedly large bill while experimenting, and unusually high, unexplained spending is also frequently the first visible sign that a leaked credential is being used to mine cryptocurrency or spin up resources at your expense. Setting this up in your very first session with a new account costs a few minutes and can save real money.

AWS Free Tier offers a set of services free up to specific usage limits, either for twelve months after account creation, always-free within a monthly cap, or free for a short trial period depending on the service, and it is the intended way to get genuine hands-on practice with real AWS services without financial risk. Reading the specific limits for each service you plan to practice with, and pairing this with the billing alerts above, keeps a learning account from turning into a surprise expense.

Amazon EC2 (Elastic Compute Cloud) provides resizable virtual machines, called instances, that you launch from a machine image, attach storage to, and place inside a VPC's subnets. It is AWS's flagship IaaS compute service and the one where the shared responsibility line sits furthest toward the customer, since you are responsible for the guest operating system and everything running on it.

Amazon S3 (Simple Storage Service) is AWS's object storage service, storing arbitrary files as objects inside containers called buckets, each object addressable by a unique key. S3's flexibility and low cost make it one of the most widely used AWS services, and it is also, not coincidentally, one of the most common sources of accidental public data exposure in the entire industry — which is why it receives an unusually deep treatment in the AWS security stage.

Amazon VPC (Virtual Private Cloud) is your own logically isolated network within AWS, where you define IP address ranges, subnets, route tables, and gateways. Nearly everything else you deploy in AWS — EC2 instances, RDS databases, many managed services — lives inside a VPC, which makes VPC design the networking foundation for essentially every other AWS security decision you will make.

Amazon RDS (Relational Database Service) is a managed database service supporting several database engines, handling patching, backups, and replication for you. It illustrates the PaaS point on the shared responsibility spectrum well: AWS manages the underlying OS and database engine, while you remain responsible for schema design, access control, and whether the database is exposed to the public internet at all.

AWS Lambda runs your code in response to events without you provisioning or managing any server, embodying the serverless model described in the fundamentals stage. Each Lambda function runs with an IAM execution role that determines what it can access, which makes IAM role scoping, covered later, the single most important security decision for any Lambda-based architecture.

Amazon CloudFront is AWS's content delivery network, caching content at edge locations around the world to reduce latency for end users and reduce direct load on origin servers. Because CloudFront often sits as the single public-facing entry point to an application, it is also a natural place to attach a web application firewall and enforce TLS, both covered in the AWS security stage.

The AWS Command Line Interface lets you interact with any AWS service from a terminal, script repeatable tasks, and — critically for security work — inspect and audit account configuration far faster than clicking through the console one page at a time. Nearly every open-source security tool covered later in this roadmap, including Prowler and ScoutSuite, relies on AWS CLI credentials being configured correctly to function.

The AWS Management Console is the web interface for browsing and configuring every AWS service, and while security-conscious workflows often move toward CLI and infrastructure-as-code, the console remains the fastest way to explore a service's settings for the first time and to visually confirm a configuration change took effect. Spend real time exploring the console for each core service before assuming you understand it purely from documentation.

Tags are key-value labels you attach to AWS resources, and a consistent tagging strategy — marking resources with owner, environment, and cost center at minimum — pays off directly in security work: tags let you scope IAM policies with ABAC-style conditions, filter security tool output by team or environment, and quickly identify who to contact about a risky resource during an incident.

AWS IAM Identity Center (formerly AWS SSO) is the recommended way to manage human access to AWS accounts, letting users authenticate once against a central identity source and be granted temporary, role-based access into one or many AWS accounts, rather than each account maintaining its own separate set of standing IAM users. Learning this service early sets you up to follow current AWS guidance rather than older patterns built around long-lived IAM user credentials.

Not every AWS service is available in every AWS region, and newer services in particular often launch in a handful of major regions before expanding globally. Checking regional availability before designing an architecture, and being deliberate about which region your resources and data live in, matters both practically and for data residency and compliance reasons covered earlier.

The AWS Well-Architected Framework is AWS's own set of best-practice pillars — including a dedicated Security pillar — for designing and operating workloads in the cloud, developed from patterns AWS observed across a huge number of real customer architectures. The Security pillar in particular is a genuinely useful, free, and continuously updated reference that overlaps heavily with the AWS security stage that follows, and is worth bookmarking rather than reading once.

AWS charges primarily on a pay-as-you-go basis, with additional discount models like Reserved Instances or Savings Plans for predictable, sustained usage. Understanding the basic shape of AWS pricing is not just a cost-management skill — unexplained changes in resource usage patterns, and therefore cost, are a practical, low-tech signal that something in your account may be misconfigured or compromised.

In practice, achieving least privilege in AWS means starting from a narrow policy and adding only the specific actions and resources a workload genuinely needs, rather than starting from a broad managed policy and hoping to trim it later. Scoping the Resource element to specific ARNs instead of a wildcard, and adding Condition blocks to restrict things like source IP or request time, are the two most effective everyday techniques for tightening a policy beyond the action list alone.

Watch specifically for wildcard actions like "Action": "*" or wildcard resources like "Resource": "*" combined with a sensitive action, both of which are the single most common source of unintended over-permissioning found in real AWS audits. Reviewing every policy for these two patterns before it is attached, and periodically re-scanning existing policies for them, catches a large share of realistic IAM risk with comparatively little effort.

IAM Access Analyzer examines resource policies across your account or organization and identifies resources — like S3 buckets or IAM roles — that are accessible from outside your trusted zone, such as from another AWS account or the public internet, by using automated logical reasoning over the policy rather than simple pattern matching. Running it regularly is one of the highest-signal, lowest-effort checks available for catching accidental external exposure before an attacker does.

Beyond enabling MFA on individual accounts, AWS lets you write IAM policies that deny most actions unless the requester has authenticated with MFA, effectively making MFA mandatory rather than optional for a given identity. Applying this consistently across every human identity — and pairing it with IAM Identity Center so there are as few standing IAM users as possible to enforce it on — closes off one of the most common initial access vectors in real incidents.

S3 Block Public Access is an account-wide setting that overrides any individual bucket policy or ACL that would otherwise make a bucket or object public, acting as a backstop against accidental exposure even if someone misconfigures an individual bucket later. Enabling it at the account level by default, and only disabling it for the rare bucket that genuinely needs to be public, is widely regarded as one of the single highest-value AWS security settings available.

A bucket policy is a resource-based IAM policy attached directly to an S3 bucket, and because it is resource-based rather than identity-based, it can grant access to identities outside your own account if written imprecisely. Always specify the narrowest possible Principal, avoid combining a wildcard Principal with an Allow effect, and use the Condition element to restrict access by source VPC or IP address wherever practical.

S3 supports server-side encryption by default, and you can further require every uploaded object to be encrypted with a specific key by using a bucket policy condition that denies uploads lacking the correct encryption header. Using a customer-managed KMS key rather than the default AWS-managed key additionally gives you fine-grained control over exactly which identities can decrypt the data, layering IAM control on top of the encryption itself.

Versioning keeps every previous version of an object when it is overwritten or deleted, rather than replacing it in place, which protects against both accidental deletion and a class of ransomware-style attack where an attacker overwrites or deletes data to cause damage. Combining versioning with MFA Delete, which requires MFA to permanently remove a version, adds meaningful protection against destructive actions taken with a compromised but non-MFA-authenticated session.

A security group is a stateful virtual firewall attached to individual resources like EC2 instances, meaning if you allow inbound traffic, the matching outbound response is automatically allowed too. A network ACL (NACL) is a stateless firewall attached to an entire subnet, evaluated in numbered rule order, where you must explicitly allow both directions of traffic yourself. Security groups are the primary tool for day-to-day access control; NACLs are typically used as a coarser, subnet-wide backstop.

VPC Flow Logs capture metadata about the IP traffic flowing through your network interfaces — source, destination, port, protocol, and whether it was accepted or rejected — without capturing the actual packet contents. They are frequently the deciding piece of evidence during an incident investigation, showing exactly what a compromised resource was communicating with, and they are cheap and straightforward to enable relative to the visibility they provide.

Following the public/private subnet pattern introduced earlier, databases, internal application servers, and anything that does not need to be directly reachable from the internet should sit in private subnets with no route to an internet gateway. Outbound internet access, when genuinely needed from a private subnet, should go through a NAT gateway rather than granting the resource a public IP, so nothing outside your network can ever initiate a connection directly to it.

A VPC endpoint lets resources in a private subnet reach AWS services like S3 or DynamoDB directly over AWS's internal network, without the traffic ever traversing the public internet through a NAT gateway or internet gateway. Beyond the security benefit of never exposing that traffic path externally, this also lets you write bucket or resource policies that require access to come only through a specific VPC endpoint, closing off an entire category of external access attempts.

AWS KMS implements the envelope encryption pattern directly: services like S3, EBS, and RDS integrate with KMS so that enabling encryption is often a checkbox, while the underlying data-key generation and master-key wrapping happen automatically. The security decision that actually matters is choosing between the default AWS-managed key (simplest, but with less granular access control) and a customer-managed key (lets you write a key policy controlling exactly who can use it, and gives you full control over rotation and revocation).

AWS CloudTrail records every API call made in your account as an event, including who made it, from what IP, and what the result was, and it should be enabled in every account, in every region, from day one. In a multi-account organization, configuring an organization-wide trail that delivers logs to a centralized, access-restricted logging account ensures that even if an attacker compromises a workload account, they cannot tamper with or delete the evidence of what they did.

AWS Config continuously records the configuration state of your resources and can evaluate that configuration against rules you define or choose from a managed library, flagging (and in some cases automatically remediating) resources that drift out of compliance, such as an EBS volume that becomes unencrypted or a security group that becomes overly permissive. Unlike a one-time scan, Config's continuous evaluation catches configuration drift that happens after the initial secure setup, which is often when real-world misconfigurations actually creep in.

Amazon GuardDuty is a managed threat detection service that continuously analyzes CloudTrail logs, VPC Flow Logs, and DNS logs using threat intelligence and machine learning to flag suspicious activity, such as an EC2 instance communicating with a known malicious IP or API calls consistent with credential compromise. Because it works passively from logs you likely already have enabled, turning it on is a comparatively low-effort way to add real detection capability on top of the preventive controls covered elsewhere in this stage.

AWS Security Hub aggregates findings from GuardDuty, IAM Access Analyzer, Config, and other AWS security services, plus supported third-party tools, into a single dashboard and normalizes them into a common finding format. It also runs automated checks against standards like the CIS AWS Foundations Benchmark, giving you a single place to see both real-time threats and configuration compliance status rather than checking each service separately.

Access keys accidentally committed to a public code repository, pasted into a public forum, or embedded in a mobile app are found and abused by automated scanners within minutes in many documented cases, often before the person who leaked them even notices. Treat any suspected key exposure as an active incident: deactivate or delete the key immediately, then investigate what it was used for using CloudTrail, rather than waiting to confirm malicious use before responding.

AWS Secrets Manager is purpose-built for secrets: it supports automatic rotation on a schedule, integrates natively with RDS and other services for credential rotation, and charges per secret. Systems Manager Parameter Store (in its standard tier) is a more general-purpose, free key-value store that can hold encrypted values but does not natively support automatic rotation. For anything genuinely sensitive that benefits from rotation, prefer Secrets Manager; for simple configuration values, Parameter Store is usually sufficient and more cost-effective.

AWS WAF is a web application firewall that inspects HTTP requests reaching services like CloudFront or an Application Load Balancer and can block requests matching rules for common attack patterns like SQL injection or cross-site scripting, or simply based on rate limits. AWS Shield provides distributed denial-of-service protection, with a free Standard tier automatically applied to every AWS customer and a paid Advanced tier offering more comprehensive protection and response support for internet-facing applications at higher risk.

The EC2 instance metadata service exposes information (and, for instances with an attached role, temporary credentials) to any process running on the instance via a simple HTTP request. The original version 1 of this service is vulnerable to being reached indirectly through a server-side request forgery vulnerability in an application running on the instance; version 2 requires a session token obtained through a separate request first, which most naive SSRF exploitation cannot replicate. Requiring IMDSv2 account-wide closes off a well-documented path attackers have used to steal instance role credentials through an otherwise unrelated application vulnerability.

AWS Systems Manager Session Manager lets you get a shell on an EC2 instance through the AWS API, authenticated and authorized entirely through IAM, without opening an inbound SSH port or managing SSH key pairs at all. This eliminates an entire class of risk tied to exposed port 22 and mismanaged key distribution, while also giving you a full, centrally logged audit trail of every session and command, which plain SSH does not provide out of the box.

Every Lambda function runs with an IAM execution role, and it is common to see functions given the broad AWSLambdaBasicExecutionRole-style permissions plus far more resource access than the function's code actually uses, simply because it is fast to attach an existing policy. Reviewing each function's actual code to determine exactly which resources it reads or writes, and scoping the execution role's policy to match, closes off a large share of the blast radius if that specific function is ever exploited.

Lambda environment variables are encrypted at rest by default, but they are visible in plaintext to anyone with permission to view the function's configuration in the console or API, and they show up unencrypted in some logging and tooling contexts. Fetching secrets at runtime from Secrets Manager or Parameter Store, rather than baking them into environment variables, keeps the secret's access control tied to IAM permissions on the secret itself rather than to whoever can view the function's configuration.

Amazon ECS runs containers using task definitions, each of which can specify its own IAM task role, distinct from the role of the EC2 instance or Fargate infrastructure running it — always use the task role rather than relying on the underlying instance's role, so that one compromised container cannot access permissions meant for the whole host. On EC2-backed ECS clusters specifically, also make sure the container instance's role is not overly broad, since a container escape could expose it.

Amazon EKS runs managed Kubernetes, and the security model layers Kubernetes-native concepts (like RBAC and network policies) on top of AWS IAM. Two AWS-specific pieces matter most for a beginner: mapping IAM identities to Kubernetes RBAC roles correctly through the cluster's access configuration, and using IAM Roles for Service Accounts (IRSA) or EKS Pod Identity so individual pods get scoped AWS permissions instead of sharing the broader permissions of the underlying worker node.

RDS encryption at rest, backed by KMS, must be enabled at the time a database instance is created — it cannot be turned on for an existing unencrypted instance without creating an encrypted snapshot and restoring from it, which makes getting this right from the start far cheaper than fixing it later. Encryption also automatically extends to the database's automated backups, read replicas, and snapshots derived from it.

An RDS instance marked as publicly accessible receives a public IP address and can accept connections directly from the internet if the associated security group allows it, which is rarely the intended architecture for a production database. Databases should almost always sit in a private subnet, reachable only from the specific application servers that need them, with public accessibility left disabled by default.

A security group rule allowing inbound traffic from 0.0.0.0/0 (the entire internet) on a sensitive port like SSH (22), RDP (3389), or a database port is one of the most consistently exploited misconfigurations found by automated internet-wide scanners, which routinely probe the entire public IPv4 address space within hours of a port opening. Regularly auditing every security group for broad inbound rules on sensitive ports, and restricting them to specific known IP ranges or removing direct exposure entirely in favor of SSM Session Manager, is one of the highest-return checks in this entire stage.

EBS volume snapshots and RDS database snapshots can be marked public, making them downloadable or restorable by anyone with an AWS account, and this setting is easy to select accidentally when sharing a snapshot with a specific partner account. Because a snapshot is a full point-in-time copy of the underlying data, an exposed public snapshot is functionally equivalent to a full data breach and should be treated with the same urgency as a public S3 bucket.

While enabling default encryption for new EBS volumes and S3 buckets is straightforward, resources created before that setting existed, or created through a process that bypassed it, can remain unencrypted indefinitely without anyone noticing. A periodic sweep specifically looking for unencrypted storage resources — easy to automate with a CSPM tool — catches this gradual drift before it becomes a compliance finding or, worse, a real exposure.

Every IAM role that trusts another AWS account (including third-party vendor accounts) should be reviewed periodically to confirm the trust is still needed, still scoped to the narrowest possible external principal, and ideally still requires an External ID condition to prevent the well-documented 'confused deputy' problem where a third party's own role could be tricked into being assumed by an unrelated party. Stale cross-account trusts left over from a discontinued vendor relationship are a realistic and often-overlooked source of risk.

Service Control Policies (SCPs) are guardrail policies applied at the AWS Organizations level that set the maximum available permissions for every identity in the accounts they cover, no matter what a local IAM policy in that account grants. Because SCPs can only restrict, never grant, and because an explicit deny at this layer cannot be overridden by any account-level policy, they are the strongest tool available for enforcing rules like 'this region can never be used' or 'this service can never be disabled' across an entire organization.

Install and run an open-source CSPM tool like Prowler or ScoutSuite against your own AWS Free Tier practice account and work through the findings it generates, treating each one as a prompt to go understand the specific control being checked rather than just fixing it mechanically. This exercise is the single most effective way to convert everything in this stage from abstract knowledge into a skill you can actually perform, since it forces you to reconcile a tool's automated judgment against your own understanding of the account's real configuration.

GCP resources are organized into a hierarchy: an Organization node at the top (tied to a company's domain), containing Folders that group related projects (often by team or environment), containing Projects, which are the actual container for resources and billing, similar in role to an AWS account. Permissions granted at a higher level in this hierarchy are inherited by everything beneath it, which makes understanding this structure a prerequisite for reasoning about GCP IAM at all.

GCP IAM binds members (users, groups, service accounts, or domains) to roles (collections of permissions) at a specific level of the resource hierarchy, and because of inheritance, a binding at the organization or folder level applies to every project beneath it unless explicitly overridden. This inheritance model is one of the clearest differences from AWS IAM, where permissions do not flow down an account hierarchy in the same automatic way, and it is worth sitting with until it feels intuitive.

Primitive roles (Owner, Editor, Viewer) are broad, legacy roles that grant sweeping permissions across an entire project and are generally discouraged for anything beyond quick experimentation. Predefined roles are curated, narrower role bundles maintained by Google for specific services, like 'Storage Object Viewer.' Custom roles let you assemble your own precise set of permissions when even the narrowest predefined role still grants more than a specific identity needs.

A GCP service account is a special kind of identity meant for applications and workloads rather than humans, and unlike an AWS IAM role, a GCP service account is itself a first-class identity that can be granted roles directly and can also have its own IAM policy controlling who is allowed to act as it. This dual nature — an identity that is both a principal and a resource — is a distinctly GCP concept worth understanding clearly before the GCP security stage covers the risks around service account keys.

Compute Engine is GCP's IaaS virtual machine service, roughly analogous to AWS EC2: you launch instances from an image, attach persistent disks, and place them inside a VPC network. Like EC2, it sits at the IaaS end of the shared responsibility spectrum, meaning you are responsible for the guest OS and everything you run on it.

Cloud Storage is GCP's object storage service, analogous to S3, storing objects inside containers called buckets with globally unique names. As with S3, misconfigured public access on Cloud Storage buckets is a common source of real-world data exposure, which is why the GCP security stage gives it dedicated attention.

A GCP VPC network is global rather than regional in scope — a single VPC can span multiple regions with subnets in each — which is a meaningful structural difference from AWS, where a VPC is confined to one region. Most resources you deploy in GCP attach to a VPC network the same way AWS resources attach to a VPC, making this the networking foundation for GCP just as VPC is for AWS.

Cloud SQL is GCP's managed relational database service, analogous to RDS, supporting engines like MySQL, PostgreSQL, and SQL Server while Google handles patching, backups, and replication. As with RDS, the customer's core responsibilities are schema and access control, encryption key choices, and whether the instance is exposed to the public internet.

Cloud Functions is GCP's serverless, event-driven compute service, analogous to Lambda, running your code in response to triggers without you managing any underlying server. Like Lambda, each function runs as a specific service account, and the permissions granted to that service account are the primary security lever available for a given function.

Google Kubernetes Engine (GKE) is GCP's managed Kubernetes service, analogous to EKS, and it is worth knowing that Kubernetes itself originated as an internal Google project before being open-sourced, which is part of why GKE is often considered a particularly mature managed Kubernetes offering. GKE security layers Kubernetes-native RBAC and network policy concepts on top of GCP IAM, mirroring the same layered model EKS uses with AWS IAM.

GCP lets you define a budget for a project or billing account and configure alerts that trigger as actual or forecasted spend crosses percentage thresholds you choose. As with AWS billing alarms, this protects a learner from accidental overspend and doubles as an early warning sign of misuse if a credential or service account key is ever compromised and used to spin up unexpected resources.

The gcloud command-line tool is GCP's equivalent of the AWS CLI, letting you manage every GCP service from a terminal and script repeatable, auditable tasks. Many GCP-focused open-source security tools, including ScoutSuite's GCP module, rely on gcloud application default credentials being configured correctly to run.

The Google Cloud Console is the web interface for browsing and configuring GCP services, and as with the AWS console, it is the fastest way to explore a new service's settings and visually confirm a change took effect before you commit to automating it with the CLI or infrastructure as code.

GCP labels are the equivalent of AWS tags — key-value pairs attached to resources — and a consistent labeling strategy for owner, environment, and cost center pays off in the same ways it does in AWS: filtering security tool output, scoping IAM conditions, and quickly identifying resource ownership during an incident.

GCP's free offering combines an initial spending credit for new accounts with an always-free tier of specific services available in limited quantities indefinitely. Understanding these limits before experimenting, combined with the budget alerts covered above, is the same low-risk sandbox approach recommended for AWS Free Tier practice.

A GCP project maps roughly to an AWS account as the primary billing and resource-isolation boundary, but the comparison is not exact: GCP layers projects underneath an explicit Organization and Folder hierarchy by default, while AWS achieves a similar structure through the separate AWS Organizations service applied on top of otherwise independent accounts. Keeping this mapping in mind as you move between the two providers will make translating concepts back and forth much faster.

Shared VPC lets one project (the host project) own a VPC network's subnets and share them with other projects (service projects), so multiple teams' resources can live in separate projects for billing and IAM purposes while still communicating over a shared network without complex peering. This pattern is commonly used to centralize network administration while still giving individual teams project-level autonomy over everything else.

App Engine is GCP's original PaaS offering, letting you deploy application code directly without managing servers, containers, or clusters, sitting conceptually between Compute Engine's full IaaS control and Cloud Functions' narrower event-driven serverless model. It is a useful example for solidifying the IaaS-PaaS-serverless spectrum introduced in the fundamentals stage using a single provider's own service lineup.

GCP pricing is primarily pay-as-you-go with automatic sustained-use discounts for many services, plus committed-use discounts for predictable long-term workloads. As with AWS, watching for unexplained changes in spend is a practical, low-tech signal worth pairing with the more direct detection tooling covered in the GCP security stage.

Unlike AWS, where most services are simply available the moment an account exists, GCP requires each service's API to be explicitly enabled per project before it can be used, which is managed through the API Library in the console or the gcloud CLI. This is a useful, if minor, security-relevant detail: reviewing which APIs are enabled in a project is a quick way to understand its actual attack surface, since a disabled API generally cannot be reached at all.

The single most impactful GCP IAM hardening step is eliminating primitive roles (Owner, Editor, Viewer) from day-to-day use in favor of predefined or custom roles scoped to what an identity actually needs, since a primitive role like Editor grants sweeping write access across nearly the entire project. Regularly reviewing IAM bindings at every level of the resource hierarchy matters more in GCP than in a flat permission model, precisely because a binding higher up silently applies to everything beneath it.

Organization Policy lets you set constraints at the organization, folder, or project level that restrict what configurations are allowed at all, regardless of what IAM permissions an identity holds — for example, disallowing public IP addresses on VMs or restricting which identity domains can be granted access. This is GCP's structural equivalent of AWS Service Control Policies: a restriction layer that sits above and cannot be overridden by ordinary IAM grants.

VPC Service Controls create a security perimeter around GCP resources like Cloud Storage buckets or BigQuery datasets, restricting data access to within that perimeter even if an identity's IAM permissions would otherwise allow it, which specifically defends against data exfiltration through a compromised or malicious identity that still has valid credentials. This is a genuinely advanced control with no direct AWS equivalent covered so far in this roadmap, and it is worth understanding conceptually even before you have a use case that needs it.

Cloud KMS implements the same envelope encryption pattern as AWS KMS: services like Cloud Storage and Cloud SQL integrate with it so encryption is largely a configuration choice, while the security decision that matters most is choosing between Google-managed keys (simplest) and customer-managed keys (which let you write an IAM policy controlling exactly who can use the key, and control its rotation schedule directly).

Public Access Prevention is Cloud Storage's equivalent of S3 Block Public Access: an organization- or bucket-level setting that blocks a bucket or its objects from ever being made publicly readable, regardless of what an individual IAM binding or ACL might otherwise allow. Enforcing it through an Organization Policy constraint across every project is one of the highest-value single settings available in GCP, for exactly the same reasons it is in AWS.

By default, Cloud Storage supports legacy per-object ACLs alongside bucket-level IAM policies, and the interaction between the two is a frequent source of confusion and accidental over-exposure. Uniform Bucket-Level Access disables per-object ACLs entirely and makes IAM the single source of truth for access to that bucket, which is simpler to audit correctly and is recommended for essentially every bucket that does not have a specific, well-understood reason to use legacy ACLs.

Security Command Center is GCP's centralized security and risk dashboard, combining asset inventory, vulnerability and misconfiguration findings, and threat detection in one place — functionally similar to the combination of AWS Config, GuardDuty, and Security Hub together. The free Standard tier already surfaces meaningful misconfiguration findings, making it a reasonable starting point even before considering the paid Premium tier's additional threat detection capabilities.

Cloud Armor is GCP's web application firewall and DDoS protection service, applied at the load balancer layer to inspect and filter incoming HTTP(S) traffic against rules for common attack patterns, geographic restrictions, or custom conditions, functioning as GCP's rough equivalent of AWS WAF combined with Shield.

Unlike AWS, where a new VPC has no default rules until you add security groups, a new GCP VPC network created in 'auto mode' comes with default firewall rules that can be more permissive than intended, including rules allowing internal traffic broadly. Reviewing and tightening the default firewall rule set immediately after creating a new VPC — rather than assuming a clean starting point — is a GCP-specific habit worth building deliberately.

Private Google Access lets VM instances that only have internal IP addresses still reach Google APIs and services without needing a public IP or a NAT gateway, mirroring the role VPC endpoints play in AWS for reaching services like S3 without traversing the public internet. Combining this with subnets that never assign external IPs at all meaningfully shrinks a workload's exposed attack surface.

GCP VPC Flow Logs record metadata about IP traffic to and from VM network interfaces, the same category of evidence AWS VPC Flow Logs provide, and they are similarly indispensable during incident investigation for reconstructing what a compromised resource actually communicated with. Enable them at the subnet level for any subnet carrying meaningful traffic, not only after an incident has already happened.

A GCP service account key is a downloadable, long-lived JSON credential file that, once created, behaves exactly like a long-lived AWS access key: if it leaks into a public repository, a laptop backup, or a misconfigured artifact, it remains valid and usable until someone notices and manually revokes it. Because GCP offers strong alternatives that avoid this risk entirely (covered next), the current best practice is to avoid creating downloadable service account keys wherever possible rather than trying to manage their exposure risk after the fact.

Workload Identity Federation lets an external identity provider — a CI/CD platform, another cloud provider, or an on-premises identity system — exchange its own token for short-lived GCP credentials, without ever creating or storing a downloadable service account key at all. This is the direct GCP counterpart to OIDC-based role assumption in AWS, and adopting it wherever a workload needs to authenticate to GCP from outside GCP itself eliminates an entire category of long-lived-credential risk by design rather than by policy.

Cloud Audit Logs record who did what, where, and when across GCP services, split into Admin Activity logs (always on, cannot be disabled, and record configuration changes) and Data Access logs (off by default for most services because of their volume, and must be explicitly enabled to record read/write access to data itself). Explicitly enabling Data Access logs for your most sensitive services is a deliberate step most learners miss, since the always-on Admin Activity logs alone do not capture data access.

GKE Workload Identity lets individual Kubernetes pods authenticate as a specific, scoped GCP service account without needing a downloadable service account key stored in the cluster, directly paralleling how IRSA/Pod Identity works for EKS in AWS. Without it, pods typically fall back to inheriting the permissions of the underlying node's service account, which is almost always far broader than any single pod actually needs.

By default, every pod in a GKE cluster can communicate with every other pod, regardless of which application or team owns them, which means a single compromised pod can potentially reach anything else in the cluster. Kubernetes NetworkPolicy resources let you explicitly restrict which pods can talk to which, applying a least-privilege model to pod-to-pod traffic the same way security groups restrict VM-to-VM traffic.

Binary Authorization enforces that only container images meeting a policy you define — such as being signed by a trusted, specific build pipeline — can actually be deployed to a GKE cluster, preventing an attacker who gains write access to a container registry or CI system from simply deploying an arbitrary malicious image. It is a supply-chain-focused control, complementing the network- and identity-focused controls covered elsewhere in this stage.

Cloud Functions security centers on the same two levers as Lambda: scoping the function's runtime service account to only the permissions it genuinely needs, and controlling who can invoke the function at all, since a function left invocable by unauthenticated callers when it was only meant to be triggered internally is a realistic and easy-to-make mistake. Reviewing the invoker IAM binding alongside the runtime service account, rather than just one or the other, gives a complete picture of a function's exposure.

Secret Manager is GCP's dedicated secrets storage service, directly analogous to AWS Secrets Manager, supporting versioned secrets, fine-grained IAM access control per secret, and integration with automatic rotation workflows. As with AWS, the guiding principle is the same: fetch secrets at runtime through IAM-controlled access rather than embedding them in code, container images, or environment configuration.

Just as with S3, Cloud Storage buckets accidentally granted allUsers or allAuthenticatedUsers read access are found and scraped by automated internet-wide scanners in short order, and this remains one of the most common and highest-impact GCP misconfigurations found in real audits. A recurring, automated scan specifically for these two special IAM members across every bucket in an organization is one of the highest-value checks available.

It is common in real GCP environments to find service accounts granted the Editor or even Owner primitive role at the project level simply because it was the fastest way to unblock a task during initial setup, and these grants often outlive the task that prompted them by months or years. A recurring review specifically targeting service accounts bound to primitive roles, cross-referenced against what the account's workload actually needs, closes a gap that is easy to create and easy to forget about.

Compute Engine and GKE automatically provision a default service account for new projects, and historically this default account was granted the broad Editor role on the project by default, meaning any VM or pod that inherited it — often without anyone deliberately deciding it should — carried far more access than it needed. Explicitly creating scoped, purpose-specific service accounts for each workload, and avoiding reliance on the default service account, removes this often-invisible source of over-permissioning.

IAM Recommender analyzes an identity's actual permission usage over time and suggests a narrower role that would have covered everything it actually did, giving you a data-driven starting point for tightening an over-permissioned identity instead of manually guessing which permissions are safe to remove. This is a genuinely practical tool for closing the gap between an idealized least-privilege policy and the messy, gradually-accumulated permissions real environments tend to end up with.

Because IAM bindings can grant access to identities from outside a project's own organization domain, and because Shared VPC and other patterns intentionally create cross-project dependencies, a periodic review specifically looking for bindings that grant access across project or organization boundaries is necessary to catch access that has outlived its original purpose, mirroring the same discipline recommended for AWS cross-account trust review.

Run ScoutSuite's GCP module (or a similar open-source tool) against your own Free Tier practice project and work through every finding, using each one as a prompt to understand the underlying control rather than fixing it mechanically. Doing this for both AWS and GCP with the same practice discipline is what turns this entire roadmap from something you have read into something you can actually do in a real environment.

An Azure AD/Entra tenant is the top-level identity boundary for an organization, subscriptions sit underneath it as billing and access-control containers, and resource groups sit under subscriptions to bundle related resources for lifecycle management. Almost every access-control and policy decision in Azure inherits down this chain, so understanding it precisely is the single most important prerequisite for everything else in this stage. Draw the hierarchy out for a small hypothetical company before moving on.

Management groups sit above subscriptions and let an organization apply policy and access assignments consistently across many subscriptions at once, which matters once a company grows past a handful of them. Understand how a management group tree mirrors organizational structure, such as separating production, non-production, and sandbox subscriptions under different branches.

Resource groups are the unit most day-to-day work happens inside: they group resources that share a lifecycle, and deleting a resource group deletes everything inside it. Practice creating resource groups with a consistent naming convention and placing related resources such as a virtual network and its subnets together.

Every action in Azure, whether from the portal, CLI, or an SDK, ultimately goes through the Resource Manager API, which exposes a consistent resource type, property, and provider model across the whole platform. Understanding that everything is a typed resource under a resource provider makes both automation and later role-based access control far more intuitive.

Microsoft Entra ID is the identity backbone for Azure: it holds users, groups, service principals, and the authentication and authorization decisions that gate access to almost everything else in the platform. Spend real time here because identity mistakes in Entra ID tend to be the root cause behind most serious Azure incidents you will read about later.

Practice creating internal users, assigning them to security groups, and inviting an external guest user through Entra ID's B2B collaboration feature. Understand that guest accounts have a distinct lifecycle and default permission set from internal accounts, which matters a great deal once you start reasoning about access review hygiene.

Azure RBAC controls who can do what to which resources by assigning roles to a security principal at a particular scope, such as a subscription, resource group, or individual resource. Learn the three core pieces of every role assignment: the security principal, the role definition, and the scope, since every access decision in Azure is expressed in those terms.

Owner can manage resources and also grant access to others, Contributor can manage resources but cannot change access, and Reader can only view. Get comfortable checking which built-in role a task actually requires instead of defaulting to Owner or Contributor out of convenience, since that habit is the root of a large share of real-world over-permissioning.

The portal is useful for exploration and one-off changes, while the Azure CLI and Cloud Shell let you script repeatable, auditable actions. Practice performing the same task, such as creating a resource group and a storage account, through both the portal and the CLI so you can move fluidly between them later.

Virtual Machines are Azure's core infrastructure-as-a-service compute offering, giving you a full guest operating system you are responsible for patching and securing. Know the basic building blocks: an image, a size (SKU), a virtual network interface, and attached managed disks.

Blob Storage is Azure's object storage service for unstructured data such as files, backups, and static website assets, organized into storage accounts and containers. Know that access to a container can be configured anywhere from fully private to fully public, a setting you will revisit closely in the next stage because misconfigured public access is one of the most common Azure findings in the wild.

A Virtual Network is an isolated network space within Azure that you subdivide into subnets to place resources like VMs and private endpoints. Learn how VNets relate to address spaces, peering between VNets, and the basic idea that resources inside a VNet can only reach each other and the outside world according to rules you define.

Azure SQL Database is a platform-as-a-service relational database, meaning Microsoft handles patching, backups, and high availability while you manage schemas, data, and access. Note that being managed does not mean it is automatically secure by default; firewall rules, authentication mode, and encryption settings are still your responsibility to configure correctly.

Azure Functions run small units of code in response to triggers such as HTTP requests, queue messages, or timers, without you managing the underlying servers. Recognize that serverless does not mean security-less: the code, its dependencies, its trigger bindings, and the identity it runs as are all still attack surface.

AKS is Azure's managed Kubernetes offering: Microsoft runs the control plane while you manage the worker nodes and the workloads deployed to the cluster. Get a basic mental model of clusters, node pools, and pods before the dedicated container and Kubernetes security stage later in this roadmap goes deep on hardening them.

Tags are key-value pairs attached to resources that support cost allocation, ownership tracking, and automation targeting. Practice tagging resources consistently with fields like owner, environment, and cost center, since a lack of tagging discipline is one of the quiet root causes behind both cost overruns and forgotten, unmanaged resources.

Cost Management gives visibility into what you are spending and where, broken down by subscription, resource group, service, or tag. Beyond the obvious financial benefit, unexpected cost spikes are often the first visible signal of a security incident, such as an attacker spinning up cryptomining VMs in a compromised subscription.

Set a budget on a subscription or resource group and configure an alert to fire before it is exceeded. This is both a financial guardrail and an early-warning security control, since a sudden unexplained cost jump often means unauthorized resource creation.

Azure offers a free account with a credit allowance and a set of always-free service tiers, which is enough to work through most of this roadmap's Azure exercises without incurring real cost. Set a low budget alert immediately after signing up as a safety net against accidental spend while you experiment.

As with every major cloud provider, Microsoft secures the underlying physical infrastructure and, for managed services, an increasing share of the platform itself, while you remain responsible for identity, data, configuration, and, for IaaS resources like VMs, the guest operating system. Where that line sits shifts depending on whether you are using IaaS, PaaS, or SaaS-style services, so re-evaluate it for every service you adopt rather than assuming a single fixed split.

Conditional Access lets you require conditions such as MFA, a compliant device, or a trusted network location before granting access, evaluated per sign-in based on signals like user, location, and device. Practice building a policy that blocks legacy authentication and requires MFA for all administrative roles, which is one of the highest-leverage identity controls in Azure.

Practice enforcing MFA broadly, ideally through Conditional Access rather than the older per-user MFA settings, and confirm break-glass accounts are excluded deliberately and documented, not by accident. Understand the difference between requiring MFA at every sign-in versus relying on risk-based or session-based re-evaluation.

PIM lets eligible users activate privileged roles for a limited time window with justification and, optionally, approval, instead of holding standing privileged access permanently. Practice making a role like Global Administrator or a subscription Owner role PIM-eligible rather than permanently assigned, and require approval and MFA for activation.

Audit existing role assignments in a subscription and identify ones broader than necessary, such as Contributor granted at the subscription level when a resource-group-scoped role would suffice. Assign roles at the narrowest scope and with the narrowest permission set that still lets people do their jobs, and prefer groups over individual user assignments so access changes as team membership changes.

When no built-in role fits, define a custom role with only the specific actions a task requires, such as restarting VMs without being able to delete them. Practice writing a custom role definition in JSON and assigning it, which also builds intuition for how Azure's permission strings are structured.

Key Vault centralizes storage of secrets, encryption keys, and certificates so they are not scattered across configuration files and source code. Practice storing a secret in Key Vault and retrieving it from an application using a managed identity instead of an embedded credential.

Key Vault historically used its own vault access policy model separate from Azure RBAC, and both still exist; understand which one a given vault uses, since mixing assumptions between them is a common source of unexpected access. The RBAC-based model is generally the more consistent and auditable choice for new vaults because it uses the same role assignment mechanism as the rest of Azure.

A SAS token grants time-limited, scoped access to storage resources without sharing the account key itself, but a leaked or overly broad SAS token is effectively a bearer credential anyone can use until it expires or is revoked. Practice generating a narrowly scoped, short-lived SAS token and understand the difference between account-level and stored-access-policy-based SAS tokens, since the latter can be revoked centrally.

By default, storage accounts can allow anonymous read access to blob containers, and leaving this enabled unintentionally is one of the most common real-world Azure misconfigurations. Practice disabling anonymous access at the storage account level and confirm it cannot be re-enabled at the container level without an explicit account-level opt-in.

Azure Storage encrypts data at rest by default using Microsoft-managed keys, but you can switch to customer-managed keys in Key Vault for tighter control over key lifecycle and revocation. Understand the difference and know how to check which mode a given storage account is using.

Defender for Cloud is Azure's native cloud security posture and workload protection service, continuously assessing resources against security recommendations and, for enabled plans, detecting active threats. Enable it in a sandbox subscription and walk through the recommendations it surfaces for a deliberately under-secured resource.

Secure Score aggregates Defender for Cloud recommendations into a single weighted number that reflects overall posture, and each recommendation shows exactly how many points fixing it would add. Use it as a triage tool to decide what to fix first rather than treating the number itself as the end goal.

Azure Policy evaluates resources against rules and can audit, deny, or even automatically remediate non-compliant configurations, such as blocking the creation of storage accounts that allow public access. Practice assigning a built-in policy, then author a simple custom policy definition of your own.

Blueprints packaged policies, role assignments, and resource templates together for repeatable environment setup, and the concept has largely evolved into the broader Azure landing zone pattern, which composes management groups, policy, and network baselines into a repeatable enterprise-scale foundation. Understand the landing zone concept even if the specific tooling used to implement it continues to evolve.

NSGs filter inbound and outbound traffic to resources in a subnet or on a network interface using allow and deny rules evaluated by priority. Practice building an NSG that denies all inbound traffic by default and opens only the specific ports a workload genuinely needs.

Azure Firewall is a managed, stateful network firewall that centralizes outbound and cross-VNet traffic filtering with application and network-level rules, typically placed in a hub VNet in a hub-and-spoke topology. Understand when a centralized firewall adds value over NSGs alone, namely when you need consistent egress filtering and threat intelligence-based blocking across many spokes.

A Private Endpoint gives an Azure PaaS service like Storage or Azure SQL a private IP address inside your VNet, so traffic to it never traverses the public internet. Practice attaching a Private Endpoint to a storage account and confirm you can then disable its public network access entirely.

Service Endpoints extend a VNet's identity to a PaaS service over the Microsoft backbone without giving the service a private IP, restricting access to traffic originating from the specified VNet or subnet. Know the tradeoff: Service Endpoints are simpler to set up but the service itself still has a public endpoint, whereas Private Endpoints fully remove it from public reachability.

Azure Monitor collects metrics and logs from across Azure resources, and Log Analytics workspaces let you query that data with Kusto Query Language (KQL) for both operational and security investigations. Practice writing a basic KQL query against activity or diagnostic logs to find a specific type of event.

The Activity Log records every control-plane operation performed against a subscription, such as who created, modified, or deleted a resource and when. Practice filtering the Activity Log for a specific resource group over the last day and identifying who made a given change, since this is a foundational incident-response skill.

AKS can be configured so that Kubernetes RBAC role bindings map to Entra ID users and groups, meaning cluster access follows the same identity source and MFA policies as the rest of the organization instead of relying on a separate static kubeconfig credential. Practice enabling Entra ID integration on a test cluster and binding a Kubernetes role to an Entra group.

By default, pods in an AKS cluster can generally reach each other freely; network policies let you restrict pod-to-pod traffic to only what is explicitly allowed. Deploy a default-deny network policy in a test namespace and then add narrow allow rules for the traffic a sample application actually needs.

Secure Functions by restricting the function's network exposure, storing configuration secrets in Key Vault rather than app settings, using a managed identity for outbound calls to other Azure services, and enabling authentication in front of HTTP-triggered functions rather than relying on function keys alone. Function keys embedded in a client or leaked in logs behave like any other static credential, so treat them with the same caution as an API key.

A service principal is an identity for an application or automation that typically authenticates with a client secret or certificate you must store and rotate yourself, while a managed identity is a special case where Azure creates and rotates the credential automatically behind the scenes for a specific resource. Prefer managed identities wherever a workload runs on Azure infrastructure, since they eliminate an entire class of credential-leakage risk.

Every service principal secret, storage account key, SAS token, and connection string is a standing credential that can leak, and the more of them an organization accumulates across pipelines, scripts, and application configuration, the larger its exposed attack surface becomes. Periodically inventory where long-lived credentials exist in an environment and push toward managed identities, Key Vault references, and short-lived tokens wherever possible.

Before considering an Azure environment reasonably hardened, check for the recurring offenders: public blob storage access, Contributor or Owner roles assigned too broadly, management ports like RDP or SSH exposed directly to the internet, storage account keys instead of managed identities in application configuration, and resources with no diagnostic logging enabled. Treat this list as a starting checklist to expand with your own findings as you review real environments.

OCI is Oracle's cloud platform, notable for its tenancy-and-compartment resource hierarchy, which is conceptually similar to AWS accounts or Azure subscriptions but with its own terminology. At a glance level, understand that OCI is common in enterprises with existing Oracle database and applications investments, and that its security model still rests on the same core primitives you already know: identity, network isolation, and policy.

OCI Identity and Access Management uses compartments to isolate resources and a natural-language-like policy syntax to grant groups access to resource types within a compartment. The concepts map closely to Azure RBAC or AWS IAM policies, so the learning curve here is mostly vocabulary rather than new ideas.

Alibaba Cloud is the dominant cloud provider in China and has a significant footprint across Asia-Pacific, with its own IAM (RAM), security center, and compliance tooling that mirror the same identity, network, and monitoring concepts found on other major clouds. Know it exists and roughly what it offers even without deep hands-on practice, since you may encounter it in a multinational environment.

DigitalOcean, Linode, and similar providers target smaller teams and individual developers with a simplified product set and a comparatively minimal but real security surface: SSH key management, firewalls, and a lightweight IAM model. Understand that a simpler platform does not mean a lower bar for good practice; the same principles of least privilege and network restriction still apply, just with fewer knobs to configure.

Smaller and regional cloud providers often ship fewer built-in security services than the hyperscalers, such as no native equivalent to GuardDuty or Defender for Cloud, which shifts more detection and hardening responsibility onto you. When evaluating any less-familiar provider, ask what identity model it uses, what is logged by default, and what third-party tooling exists to fill the gaps.

Every additional cloud provider brings its own identity system, permission model, logging format, and default settings, which multiplies the number of things that can be misconfigured and the amount of tooling needed to get a single unified view. Multi-cloud is sometimes adopted for legitimate reasons such as avoiding vendor lock-in or meeting a specific service's strengths, but it is rarely a free strategic win from a security standpoint.

Rather than maintaining separate user directories per cloud, federate each provider's identity system to a single source of truth, such as using Entra ID or Okta as an identity provider that AWS, GCP, and Azure all trust via SAML or OIDC. Centralized identity means a single offboarding action disables a departing employee everywhere at once, instead of requiring separate cleanup in every cloud console.

Cloud Security Posture Management tools that support multiple providers let a security team see misconfigurations across AWS, Azure, and GCP in one place instead of switching between three native consoles with three different vocabularies. Practice running an open-source multi-cloud CSPM tool against a sandbox account in two different providers and compare how it normalizes findings across them.

Teams sometimes deliberately design workloads to be portable across clouds, which can mean avoiding a provider's more advanced native security services in favor of a lowest-common-denominator, self-managed alternative. Weigh that tradeoff explicitly: portability has real value, but so does a managed detection service you chose not to use for the sake of abstraction.

A site-to-site VPN encrypts traffic between an on-premises network and a cloud VNet or VPC over the public internet, and is usually the fastest and cheapest way to establish hybrid connectivity. Know its tradeoffs: it depends on internet path quality and throughput, so it suits lower-bandwidth or non-latency-sensitive connections better than a dedicated interconnect.

Services like Azure ExpressRoute, AWS Direct Connect, and Google Cloud Interconnect provide a private, dedicated network link between an on-premises data center and a cloud provider, bypassing the public internet entirely for lower latency and more predictable throughput. Understand that a dedicated link still needs its own access controls and encryption considerations; private does not automatically mean encrypted at the network layer.

When running workloads in more than one cloud, adopt a shared naming and tagging scheme for environment, owner, and cost center so that inventory and governance tooling can reason about resources uniformly regardless of which provider they live in. Inconsistent conventions across clouds are a quiet but persistent source of untracked, unowned resources.

Tools like Terraform for provisioning, and Steampipe or a multi-cloud CSPM for posture visibility, let a team build muscle memory that transfers across providers instead of relearning a workflow for each one. Recognize the tradeoff: cloud-agnostic tooling often lags behind a provider's own native tools in covering that provider's newest features.

Legitimate reasons to run more than one cloud include regulatory data residency requirements, negotiating leverage, avoiding a single point of organizational failure, or genuinely needing a specific service unique to another provider. Treat multi-cloud as a deliberate tradeoff decision with real ongoing operational and security cost, not a default best practice to reach for without a concrete driving reason.

Image scanners inspect the layers of a container image against vulnerability databases to flag outdated packages and libraries before an image ever reaches a running cluster. Practice scanning a sample image locally and integrating that scan as a required step in a build pipeline so vulnerable images are caught before deployment rather than after.

A minimal or distroless base image ships only the runtime dependencies an application actually needs, stripping out shells, package managers, and other tooling that a full general-purpose OS image includes by default. Smaller images have a proportionally smaller attack surface and fewer packages to track for vulnerabilities, and the missing shell also makes certain post-exploitation techniques significantly harder to carry out.

Kubernetes RBAC controls what actions a user or service account can perform against which API resources within a namespace or cluster-wide, expressed through Roles, ClusterRoles, and their corresponding bindings. Practice writing a namespace-scoped Role that only allows reading pods and logs, then bind it to a test user, reinforcing the same least-privilege thinking you applied to cloud IAM earlier in this roadmap.

Pod Security Standards define three preset levels, Privileged, Baseline, and Restricted, that control which risky pod capabilities are allowed, such as running as root or mounting the host filesystem. Practice applying the Restricted level to a namespace and observe which pod specifications get rejected as a result.

Admission controllers intercept requests to the Kubernetes API server after authentication and authorization but before an object is persisted, letting a cluster validate or mutate objects, such as rejecting a pod that requests privileged mode. Tools built on this mechanism let you write custom policy rules well beyond what built-in Pod Security Standards cover.

By default, Kubernetes allows all pods within a cluster to communicate with each other freely, which means a single compromised pod can reach everything else in the cluster. NetworkPolicies let you define a default-deny posture and then explicitly allow only the traffic paths a workload legitimately needs, similar in spirit to security groups but enforced at the cluster networking layer.

Environment variables are easy to accidentally expose through crash dumps, logging middleware, debugging endpoints, or child processes that inherit the full environment, and they are visible to anything with exec access into the container. Kubernetes Secrets are a step up but are only base64-encoded by default, not encrypted, unless you explicitly enable encryption at rest for the cluster's etcd store.

Tools like the External Secrets Operator sync secrets from a dedicated secrets manager such as Key Vault, AWS Secrets Manager, or HashiCorp Vault into the cluster on demand, keeping the actual source of truth outside etcd and benefiting from centralized rotation and auditing. Practice wiring an external secrets operator to pull a single test secret into a namespace.

A service mesh like Istio or Linkerd can automatically encrypt and mutually authenticate traffic between services inside the cluster using short-lived certificates, without application code needing to implement TLS itself. This closes a real gap: plain pod-to-pod traffic within a cluster is otherwise typically unencrypted, meaning anyone who can sniff cluster network traffic can read it.

The API server is the control point for the entire cluster, and an API server reachable from the open internet without strong authentication is one of the most severe possible cluster misconfigurations, since it can allow full cluster takeover. Confirm the API server endpoint is restricted to trusted networks or requires strong authentication such as Entra ID, IAM, or a private cluster configuration, and never rely on obscurity alone.

The kubelet is the node-level agent that manages containers on each worker node, and it exposes its own API which, if left unauthenticated, can allow arbitrary command execution inside any pod on that node. Confirm kubelet anonymous authentication is disabled and that its API is not reachable outside the cluster's trusted network.

Provenance is the verifiable record of where a container image came from and how it was built, which matters because a pipeline that pulls unverified base images or dependencies from arbitrary public registries is trusting every upstream maintainer in that chain implicitly. Frameworks for supply chain integrity describe levels of build and provenance guarantees you can work toward as a pipeline matures.

Image signing cryptographically attaches proof of who built an image and that it has not been tampered with since, and admission policies can then require that only signed images from trusted signers are allowed to run in a cluster. Practice signing a sample image and configuring a policy that rejects unsigned images.

Runtime security tools observe running containers for suspicious behavior, such as an unexpected shell spawned inside a container that normally never execs into one, using kernel-level instrumentation to detect activity that static image scanning could never catch. Deploy a runtime detection tool in a lab cluster and trigger a deliberately suspicious action to see what it flags.

A privileged pod runs with essentially all the same access to the host as a process running directly on the node, including the ability to access host devices and bypass most container isolation. Audit workloads for privileged mode and unnecessary added Linux capabilities, and drop everything not explicitly required, following the same least-privilege instinct as IAM.

A hostPath volume mounts a directory from the underlying node's filesystem directly into a pod, which can let a compromised or misconfigured pod read or write sensitive host files, including in some cases the container runtime's own socket. Restrict or outright block hostPath mounts through policy unless there is a specific, well-understood operational reason to allow one.

By default, every pod automatically gets a token for its namespace's default service account mounted into its filesystem, even if the workload never calls the Kubernetes API. Disable automatic mounting for workloads that do not need API access, since an unused mounted token is simply unnecessary attack surface a compromised pod could otherwise use to talk to the API server.

Namespaces logically separate resources within a cluster and are the scope at which RBAC roles, network policies, and resource quotas most commonly apply. Design namespace boundaries around trust boundaries, such as separating teams or environments, not merely around convenience of organization.

Requests and limits constrain how much CPU and memory a container can consume, which prevents a single misbehaving or compromised workload from starving every other pod on the same node through resource exhaustion. This is a reliability control with a real security dimension, since resource exhaustion is a straightforward denial-of-service vector inside a shared cluster.

The CIS Kubernetes Benchmark is a detailed, community-maintained checklist covering control plane, node, and workload configuration, and automated tools can check a running cluster against it directly. Run one against a lab cluster and work through the findings it reports, treating it as a comprehensive capstone check on everything covered in this stage.

A container escape is when a process inside a container manages to break out of its isolation and gain access to the underlying host, typically through a combination of running as root, having excessive Linux capabilities, mounting sensitive host paths, or exploiting a flaw in the container runtime itself. Understanding this concept is what makes the earlier items in this stage, like avoiding privileged mode and hostPath mounts, click as a coherent defense rather than a checklist of unrelated rules.

A container registry should require authentication for pushes and, ideally, pulls, restrict who can push to production-tagged images, and be scanned continuously rather than only at build time since new vulnerabilities are disclosed against already-published images regularly. Treat the registry as a high-value target, since write access to it effectively means the ability to influence what code runs across every cluster that pulls from it.

When infrastructure is defined in code, a security review can happen before a single resource is ever created, by reading and scanning the code itself rather than auditing a live environment after the fact. This shifts security left, catching a misconfiguration in a pull request instead of in production, but it also means the code and its pipeline become just as security-critical as the infrastructure they describe.

Terraform is the most widely used cloud-agnostic IaC tool, describing infrastructure as declarative configuration and tracking real-world resource state in a state file. When reviewing Terraform code, look specifically for hardcoded credentials, overly permissive IAM policy blocks, resources left with public network access, and modules pulled from unverified sources.

AWS CloudFormation and Azure's ARM templates and Bicep are each provider's native IaC languages, and while their syntax differs from Terraform, the review priorities are the same: check for public exposure, overly broad permissions, and disabled encryption or logging settings. Familiarity with at least one native format alongside Terraform is useful since some organizations standardize on their cloud provider's own tooling.

Checkov scans Terraform, CloudFormation, ARM/Bicep, and Kubernetes manifests against a large library of built-in policies covering common misconfigurations, and can be run locally, in CI, or as a pre-commit hook. Practice running it against a Terraform module with a deliberately public storage bucket and confirm it flags the issue.

tfsec is a Terraform-focused static analysis tool that parses configuration directly and flags security issues with clear explanations and links to the specific rule triggered. Add it as a required check in a sample CI pipeline so a pull request cannot merge while a high-severity finding is unresolved.

Terrascan scans Terraform and other IaC formats against policies written in Rego, the same policy language used by Open Policy Agent, which makes it a natural fit for teams already investing in policy-as-code elsewhere in their stack. Comparing its findings against Checkov or tfsec on the same codebase is a useful exercise in understanding how different scanners weigh the same misconfiguration.

Drift happens when the real state of a resource diverges from what the IaC code says it should be, typically because someone made a manual change directly in the console outside the normal pipeline. Drift is a security concern because it means the code you reviewed no longer accurately describes what is actually running, undermining the entire premise of reviewing infrastructure as code in the first place.

Secrets accidentally committed to a git repository, such as an API key pasted into a config file, remain retrievable in the repository's history even after the file is later removed, unless the history itself is rewritten. Practice running a secret scanner against a repository's full commit history, not just its current state, to appreciate how much a single scan of the latest commit alone would miss.

Beyond scanning a repository occasionally, wire a secret scanner into the CI pipeline itself so a commit containing a credential is blocked from merging in the first place, and pair it with a pre-commit hook so developers catch the mistake locally before it ever reaches the remote repository. Layering both catches the same class of mistake at two different points, which matters because any single layer can be skipped or misconfigured.

A pipeline that deploys infrastructure typically needs a credential with real permissions in the target cloud account, and that credential is an extremely attractive target since compromising the pipeline is often easier than attacking the cloud environment directly. Scope pipeline credentials as narrowly as possible to only the actions and resources a given job actually needs, and never reuse one broad, all-powerful credential across every pipeline.

Most major CI/CD platforms can now exchange a short-lived OIDC token for temporary cloud credentials at pipeline run time, which means no long-lived cloud access key needs to be stored as a pipeline secret at all. Migrate a sample pipeline from a stored static credential to OIDC federation and confirm the pipeline still authenticates successfully without ever holding a long-lived secret.

An SBOM is a structured inventory of every component, library, and dependency that makes up a piece of software, which lets a team quickly determine exposure when a new vulnerability is disclosed in a widely used package. Practice generating an SBOM for a sample application build and inspecting what it reveals about the dependency tree.

Dependency scanners check a project's declared libraries against vulnerability databases and flag ones with known issues, ideally as an automated pipeline step rather than a manual, occasional check. Combine this with SBOM generation, since a scan tells you what is vulnerable right now, while an SBOM lets you quickly answer the same question again the next time a new vulnerability is disclosed.

OPA lets you express security and compliance rules as code using the Rego language, and Conftest applies those rules to structured configuration files like Terraform plans or Kubernetes manifests as an automated pipeline gate. Practice writing a simple Rego policy that denies a Terraform plan containing a security group open to the entire internet.

Pipeline injection happens when untrusted input, such as a pull request title, branch name, or commit message from an external contributor, gets interpolated directly into a shell command the pipeline executes, letting an attacker run arbitrary commands with the pipeline's own credentials. Review pipeline definitions for places where untrusted, attacker-controlled strings flow into a shell step without sanitization.

A Terraform state file can contain sensitive values in plaintext, including database passwords and other secrets that were passed as resource attributes, so it must be stored in an encrypted, access-controlled remote backend rather than committed to a repository or left on a local disk. Confirm remote state storage has encryption at rest enabled and that access to it is scoped as tightly as access to the infrastructure it describes.

Confirm that the artifact a deployment pipeline promotes to production is exactly the one that was built and scanned earlier in the pipeline, typically by checksum or cryptographic signature, rather than trusting that a differently-named or separately-fetched artifact is equivalent. This closes a gap where a scan can pass against one artifact while a different, unscanned one is what actually gets deployed.

Require pull request review and passing status checks, including the security scans covered earlier in this stage, before code can merge into a branch that triggers deployment, and disable the ability to push directly to that branch. This is a simple control, but it is what actually makes every static analysis and secret scanning tool in this stage effective, since a check that can be bypassed provides no real assurance.

Encryption at rest protects data while it is stored on disk, so that someone who obtains the physical or logical storage medium cannot read it without the key, while encryption in transit protects data as it moves across a network, typically via TLS, so it cannot be read by anyone intercepting the traffic. Both are necessary and neither substitutes for the other; data can be perfectly encrypted at rest and still be exposed in plaintext the moment it travels over an unencrypted connection.

Envelope encryption encrypts data with a fast, locally generated data encryption key, and then encrypts that data key itself with a separate, more tightly controlled key held in a key management service, rather than encrypting large volumes of data directly with the master key. This design means the expensive, tightly audited master key rarely needs to touch the actual data, while still allowing central control and revocation over every data key it ever wrapped.

Every major provider offers a managed key management service, such as Azure Key Vault Managed HSM, AWS KMS, and Cloud KMS, that generates, stores, and controls access to encryption keys without ever exposing the raw key material to you directly. Learn the shared vocabulary across them: key rings or vaults, key versions, key policies, and grants or access control on who may use a key to encrypt or decrypt.

Rotating a key periodically generates a new key version while retaining old versions for decrypting previously encrypted data, which limits how much data any single compromised key version could expose. Practice enabling automatic rotation on a key in a cloud KMS and confirm that data encrypted before rotation can still be decrypted afterward.

Provider-managed keys are the simplest option, with the cloud handling generation, storage, and rotation entirely behind the scenes, while customer-managed keys let you control the key's lifecycle, rotation schedule, and access policy yourself, and revoke it independently of the resource it protects. Choose customer-managed keys when a compliance requirement or specific threat model demands that level of control, and accept provider-managed keys elsewhere to reduce operational overhead.

Data classification labels information by sensitivity, such as public, internal, confidential, and restricted, so that handling requirements like encryption strength, access restrictions, and retention period can be applied consistently based on that label rather than decided ad hoc for every dataset. Practice classifying a handful of example datasets and mapping each classification level to a concrete set of required controls.

DLP tooling inspects data in motion or at rest for patterns that match sensitive information, such as credit card numbers or government ID formats, and can block, quarantine, or alert on matches before that data leaves an approved boundary. Understand DLP as a detective and preventive control layered on top of classification and encryption, not a replacement for either.

A backup is a full copy of production data and deserves the same or stronger access controls and encryption as the original, yet backups are frequently overlooked in security reviews because they are considered purely an operational concern. Confirm backup storage is encrypted, access to it is separately restricted from general production access, and that backup deletion requires an elevated or separately authorized action.

Immutable storage prevents data from being modified or deleted for a defined retention period, even by an account administrator, which is specifically designed to defeat ransomware or a compromised-credential scenario where an attacker tries to destroy backups to prevent recovery. Practice enabling an immutability policy on a test storage container and confirm a delete attempt is rejected during the retention window.

Regardless of provider, the same core rules apply: never commit secrets to source control, store them in a dedicated secrets manager rather than configuration files or environment variables where avoidable, prefer short-lived and automatically rotated credentials over long-lived static ones, and grant access to a given secret as narrowly as possible. Treat this as the unifying thread connecting Key Vault, AWS Secrets Manager, and Google Secret Manager, which you have now seen across three different providers.

It is tempting to assume traffic that never leaves a cloud provider's internal network does not need encryption, but that assumption breaks down the moment a network is shared, misconfigured, or partially compromised. Configure services to reject plaintext connections wherever a TLS option exists, including for internal service-to-service and database traffic, not only for internet-facing endpoints.

Managed database services typically offer transparent data encryption for the data files at rest, separate and additional column- or field-level encryption for especially sensitive fields, and enforced TLS for client connections. Know that enabling transparent encryption at the storage layer does not protect data from someone with legitimate database query access; that requires field-level encryption or access controls instead.

Access to use a key for encryption or decryption should be reviewed with the same rigor as access to the data it protects, since a key with overly broad usage permissions effectively grants indirect access to everything it encrypts. Practice reviewing a KMS key's access policy in a lab environment and identifying any principal with broader access than its actual role requires.

Data residency refers to physically constraining where data is stored, often to satisfy a specific regulation, while data sovereignty extends that idea to which legal jurisdiction's laws govern the data regardless of where it is processed. Understand that most major cloud providers let you pin resources to specific regions to help meet these requirements, but that configuring the right region is a necessary step, not by itself a complete compliance solution.

Route logs from every cloud account, service, and, where relevant, multiple providers into a single centralized destination rather than leaving them scattered across dozens of individual service consoles. Centralization is what makes correlation possible: an incident that touches identity, network, and storage logs is nearly impossible to investigate efficiently if those three log sources live in three separate places nobody thought to cross-reference.

Retention that is too short means evidence of an intrusion may already be gone by the time it is discovered, since many real-world breaches are not detected for a considerable stretch of time after initial access. Balance retention length against storage cost and any compliance-mandated minimum, and consider a tiered approach that keeps recent logs readily queryable while archiving older logs to cheaper, still-accessible cold storage.

AWS GuardDuty, Google Security Command Center, and Microsoft Defender for Cloud each continuously analyze account activity and network telemetry to surface likely threats, such as credential compromise indicators or reconnaissance behavior, without you having to build that detection logic yourself. Having now seen the AWS, GCP, and Azure equivalents, articulate what signals each one draws on and where their coverage differs.

A SIEM aggregates logs from many sources and applies correlation rules across them, letting you detect patterns that span services or even multiple clouds that a single provider's native detection tool would never see in isolation. Practice forwarding a sample log source into a SIEM and building one basic correlation rule, such as alerting when the same account triggers a failed login followed shortly by a successful one from a different country.

The most privileged identity in any cloud account should almost never be used for routine work, so any sign-in event from it is inherently notable and worth an immediate alert to a human, not just a log entry to review later. Configure this alert in a lab environment and confirm it fires within a reasonable time of a test sign-in.

Changes to identity permissions, role assignments, or organization-wide policies are exactly the kind of action an attacker takes to escalate privileges or establish persistence after an initial compromise, which makes them high-value alerting targets even though they are individually rare and legitimate most of the time. Build an alert that fires on any change to a privileged role assignment or a security-relevant policy, and practice tuning it to reduce noise from routine, expected changes.

Configure alerting for the moment a storage bucket, database, or security group rule becomes reachable from the public internet, since this class of misconfiguration is one of the most common root causes of real breaches and is detectable the instant it happens rather than only after data has already been accessed. Test this alert against a deliberately misconfigured resource in a sandbox account.

A playbook documents, in advance, the concrete steps to take for a specific type of incident, such as a leaked cloud credential, so that responders are executing a rehearsed plan under pressure rather than improvising one from scratch. Draft a simple playbook for a single realistic scenario, covering detection, containment, eradication, recovery, and a post-incident review step.

Containment for a compromised VM or container typically means moving it into an isolated network segment with no outbound connectivity, disabling its associated credentials, and preserving a snapshot before touching it further, rather than immediately terminating it and destroying evidence. Practice this exact sequence against a deliberately compromised test VM in a sandbox account.

Once a credential is suspected of compromise, treat it as burned permanently and rotate it immediately rather than waiting for full confirmation, since the cost of unnecessary rotation is far lower than the cost of an attacker retaining access during a slow investigation. Practice a full rotation workflow for at least one credential type, such as a service principal secret or an access key, including updating every place that credential was referenced.

Before terminating, patching, or otherwise cleaning up a compromised resource, take a disk snapshot and capture relevant logs so that a later investigation can still determine what happened, since remediation actions often destroy the exact evidence needed to understand root cause. Practice snapshotting a test VM's disk in a lab environment and confirm you can later mount that snapshot read-only for analysis without touching the original.

Threat hunting means proactively searching logs for signs of compromise before an alert fires, based on a hypothesis, such as looking for API calls from an unusual geographic region or a sequence of reconnaissance-style read-only calls followed by a permission change. Practice writing one hunting query against a sample log dataset based on a specific hypothesis you form yourself, rather than only reacting to pre-built alerts.

An attacker with sufficient access will often try to delete or alter logs to cover their tracks, so logs should be shipped to a destination the compromised account or resource itself cannot modify or delete, ideally with write-once retention enabled. Confirm that the identity generating a resource's logs is not also able to delete the destination those logs are shipped to.

A runbook automates a specific, well-understood response step, such as automatically disabling an access key the moment it is flagged as exposed in a public repository, removing the delay of a human needing to notice the alert and act on it manually. Automate one such response in a lab environment and understand where human judgment should still be required as a checkpoint versus where full automation is appropriate.

A tabletop exercise walks a team through a simulated incident scenario verbally, without touching real systems, to test whether the playbook, communication plan, and role assignments actually hold up under a realistic sequence of events. Run through one simple scenario, such as a leaked cloud credential discovered on a public code-sharing site, and identify at least one gap the exercise reveals in your draft playbook.

Chain of custody means documenting who accessed a piece of evidence, such as a forensic disk snapshot, when, and what they did with it, which matters if an incident could ever result in legal or regulatory action. Even outside a strict legal context, maintaining this discipline habitually makes post-incident review far more trustworthy and reduces disputes over what actually happened during a response.

The Center for Internet Security publishes detailed, community-vetted configuration benchmarks for AWS, Azure, GCP, and Kubernetes, each listing specific, testable settings such as whether MFA is enforced for privileged accounts. Treat a CIS Benchmark as a concrete, checkable translation of abstract security best practice into pass-or-fail configuration checks you can actually automate against.

The NIST CSF organizes cybersecurity activities into functions such as identify, protect, detect, respond, and recover, giving organizations a common vocabulary and structure for describing their security program rather than prescribing specific technical controls. Understand it as a framework for organizing and communicating a security program's maturity, which is a different and complementary purpose from a technically prescriptive benchmark like CIS.

ISO 27001 is an international standard for building and operating an information security management system, and organizations can be formally certified against it by an accredited external auditor. Know it as a management-system standard focused on ongoing risk management process, distinct from a technical checklist, even though implementing it in practice draws on many of the same technical controls covered throughout this roadmap.

SOC 2 is an attestation report, common among B2B SaaS companies, produced by an independent auditor evaluating a company's controls against trust service criteria such as security, availability, and confidentiality. Understand that a SOC 2 report is a point-in-time or period-based attestation delivered to a company's own customers as evidence of its controls, rather than a certification the company itself holds indefinitely.

PCI-DSS is a mandatory standard for any organization that stores, processes, or transmits payment card data, with detailed technical requirements covering network segmentation, encryption, and access control specifically for the systems that touch card data. Recognize when PCI-DSS applies to a cloud environment, namely whenever cardholder data enters it, and understand that scoping which systems fall inside that boundary is usually the first and most consequential step in a PCI compliance effort.

Pick a single control you have already learned, such as enforcing MFA for privileged accounts or enabling encryption at rest, and trace how it satisfies specific requirements across CIS, NIST CSF, and one other framework at once. This exercise is what compliance work actually looks like in practice, since a well-designed control program implements a technical control once and maps it to many frameworks rather than building separate control sets per framework.

Cloud Security Posture Management tools continuously evaluate a cloud environment's configuration against a library of rules derived from frameworks like CIS, surfacing misconfigurations as findings with a severity and remediation guidance attached. Think of CSPM as the automated, continuous version of the manual configuration review you have been practicing by hand throughout this roadmap.

Prowler is an open-source CSPM tool covering AWS, Azure, GCP, and Kubernetes, mapping its checks directly to frameworks such as CIS Benchmarks. Run it against a deliberately under-secured sandbox account and read through the generated findings report end to end, treating it as a practical capstone exercise across everything learned in this roadmap.

ScoutSuite is another open-source multi-cloud auditing tool, producing an interactive HTML report that groups findings by service, which makes it a useful complement to Prowler's more compliance-framework-oriented output. Run it against the same sandbox account used earlier and compare what each tool catches that the other does not.

Steampipe exposes live cloud resource configuration as SQL tables, letting you write ordinary SQL queries to answer questions like which storage buckets currently allow public access across an entire account. Practice writing one or two exploratory queries against a sandbox account to get comfortable treating cloud configuration as queryable data rather than something only visible through a console.

CloudSploit is another open-source scanner focused on detecting cloud misconfigurations, and comparing its output against Prowler and ScoutSuite on the same account reinforces that no single CSPM tool catches everything, since each maintains its own independently curated rule set. Treat exposure to multiple tools as building judgment about tool coverage, not as redundant repetition of the same exercise.

Having already practiced writing OPA and Rego policies in the IaC and Kubernetes stages, recognize policy-as-code as a governance tool as much as a technical one: it lets an organization encode its compliance requirements once and enforce them automatically and consistently, rather than depending on every engineer remembering every rule.

A landing zone is a pre-configured, secure-by-default environment baseline, typically including account or subscription structure, network topology, identity federation, and a starter set of policies, that new workloads and teams are provisioned into rather than starting from a blank environment each time. Landing zones exist precisely to make good governance the default path of least resistance instead of something bolted on after the fact.

A preventive guardrail, such as a policy that blocks creation of a public storage bucket outright, stops a misconfiguration before it ever exists, while a detective gate, such as a CSPM finding, only surfaces it after the fact for someone to remediate. Favor preventive guardrails wherever practical, and treat detective controls as the necessary safety net for everything a guardrail could not anticipate or block.

Unowned, forgotten, or unexpectedly expensive resources are frequently also the least monitored and least securely configured ones, since nobody is actively watching them, which means cost governance practices like tagging enforcement and budget alerts double as an indirect security control. Revisit the tagging and budget alert habits built earlier in this roadmap and connect them explicitly to this governance lens.

An accurate, continuously updated inventory of what resources exist, who owns them, and what data they hold is a prerequisite for almost every other governance and compliance activity, since you cannot secure, classify, or audit a resource nobody knows exists. Enforce required tags such as owner and environment through policy-as-code, and periodically reconcile the tagged inventory against what a CSPM tool actually discovers running in the account.

This certification validates deep, hands-on AWS security knowledge across identity, data protection, incident response, and logging, and is widely recognized by employers hiring specifically for AWS-focused security roles. It assumes real working experience with AWS, so treat the hands-on exercises from the AWS stages earlier in this roadmap as your actual preparation, not just reading the exam guide.

This certification validates the ability to design and implement secure infrastructure on Google Cloud, covering identity, network security, data protection, and compliance. It pairs naturally with the GCP stages completed earlier in part one of this roadmap.

This certification focuses specifically on implementing security controls in Azure, including identity and access management, platform protection, and security operations, closely mirroring the Azure fundamentals and Azure security stages you just completed. It is a natural next checkpoint immediately after finishing this roadmap's Azure content while the material is still fresh.

The Certificate of Cloud Security Knowledge is vendor-neutral, covering cloud security concepts, governance, and risk across providers rather than tying itself to a single one, which makes it a strong complement to the provider-specific certifications above, especially for anyone whose career leans toward multi-cloud environments or security leadership. It is also a reasonable starting point if you would rather validate broad conceptual knowledge before committing to a provider-specific exam.

Reading about a control and configuring it yourself in a real, if small, environment are entirely different levels of understanding, and the free tiers offered by AWS, GCP, and Azure are generous enough to practice almost everything in this roadmap without meaningful cost. Keep a running personal lab where you periodically try to break, then fix, a fresh misconfiguration, since this kind of deliberate practice is what turns roadmap knowledge into real operational skill.

Cloud platforms change constantly, with new services, new default settings, and new security features shipping on an ongoing basis, so treat this roadmap as a strong foundation rather than a permanently complete picture. Set aside a small amount of regular time to skim official security blog and release-note updates from the providers you work with most.

Communities built around cloud security, whether general-purpose security forums, provider-specific user groups, or open-source project communities like CNCF's, are a valuable source of real-world war stories, tool recommendations, and job leads that no roadmap can fully substitute for. Look for active, well-moderated communities relevant to the specific area of cloud security you want to specialize in, and participate rather than only lurking.

Contributing even a small documentation fix or a new detection rule to a tool like Prowler, Checkov, or Trivy forces you to read real production code that implements the exact concepts covered in this roadmap, which is a genuinely different and often deeper kind of learning than using the tool alone. Start with something small, such as adding a check for a misconfiguration pattern you learned about in this roadmap that the tool does not yet cover.

Public postmortems and incident writeups from real organizations describe, in concrete detail, exactly how a specific combination of small misconfigurations chained together into a serious breach, which is often more memorable and instructive than an abstract checklist item ever could be. Read a handful of these with a specific question in mind each time: which control from this roadmap, if it had been in place, would have broken this particular attack chain.

A portfolio that shows, for example, a hardened multi-account AWS landing zone, a Terraform module with security scanning wired into its own pipeline, or a small custom CSPM check you wrote yourself, demonstrates real applied skill in a way a certification alone cannot. Document each project with what problem it solved and what tradeoffs you made, since being able to explain your reasoning is often what actually differentiates candidates in an interview.

Rather than designing a system around the hope that no component will ever be breached, design it assuming some component eventually will be, and ask what blast radius that failure would have given the controls currently in place. This mindset is what connects nearly every control in this roadmap, from least-privilege IAM to network segmentation to immutable backups, into a single coherent defense-in-depth philosophy rather than a disconnected list of best practices.

Permissions accumulate over time as people change roles, projects wind down, and temporary access grants are never revoked, which means an environment that was well-scoped on day one drifts toward over-permissioning without anyone deciding that outcome deliberately. Make a recurring habit, personally or as a team practice, of reviewing who has access to what and removing anything no longer justified.

By the end of this roadmap, granting the narrowest permission that gets a task done should feel like the natural first instinct, with broader access being the deliberate, justified exception rather than the convenient default. This single habit, applied consistently across identity, network, and data access, prevents a larger share of real-world cloud incidents than almost any individual tool covered in this roadmap.

Some cloud security careers go deep on a single provider or a single domain such as detection engineering, application security, or compliance, while others stay broad across providers and domains as a generalist cloud security engineer or architect. Neither path is objectively better; consider which kind of work you found most engaging while working through this roadmap, and let that genuinely guide where you invest your next round of deeper learning.