Cloud Security
The Cloud Security domain tests how you reach the same outcomes - least privilege, segmentation, visibility, encryption - inside a control plane you do not own. Questions cluster around identity, configuration drift, and where the shared responsibility line actually falls.
Core rules
- Shared responsibility: the provider secures the cloud; you secure what you put in it. The line shifts between IaaS, PaaS, and SaaS, but identity, data, and configuration are yours at every layer.
- Identity is the perimeter. Prefer roles and short-lived credentials over long-lived keys, and avoid wildcard actions on wildcard resources - that pair turns one leaked credential into full account compromise.
- Most cloud incidents are misconfiguration: public storage, security groups open to 0.0.0.0/0 on administrative ports, unencrypted volumes, exposed instance metadata.
- Security groups are stateful and allow-only, so return traffic needs no rule. Network ACLs are stateless and evaluated in order, so they need explicit rules in both directions.
- A posture-management tool finds drift; it does not prevent it. Pair it with infrastructure-as-code scanning so the bad configuration is blocked before deployment.
- Control-plane audit logs and flow logs are your primary evidence. Ship them to an account or project the compromised principal cannot reach.
Worked example
A web application fetches user-supplied URLs to generate link previews. An attacker submits a request for the instance metadata address and receives temporary credentials for the instance role. Reasoning: this is server-side request forgery aimed at the metadata service. Patching the URL parser helps only briefly; the durable fixes are requiring the token-based metadata service, scoping the instance role to the minimum the application needs, and blocking the metadata address at the egress layer.
Traps that cost marks
Assuming the provider patches your guest operating system. Treating a private subnet as inherently safe. Forgetting that an account-level public-access block and a resource policy can disagree about intent. Deleting a role or key to "clean up" without checking what silently depends on it.