Security

Treat the three Security subtopics as concentric layers that every request passes through in order, not as independent topics. The outermost layer is authentication and authorization (authentication-and-authorization): is this caller who they claim, and may they perform this action on this resource? Inside that sits encryption (encryption-with-aws-services): even an authorized caller (or a leaked snapshot) should see only ciphertext unless they also hold the key, so data is encrypted at rest (KMS-backed) and in transit (TLS). The innermost layer is sensitive data management (sensitive-data-management): the credential or API key that let the caller in must never live in code, config, or source control. It is fetched at runtime from a managed store. The layers are independent controls, so the exam tests them separately, but a real fix usually touches more than one: a leaked database password is both a secrets problem (it was hard-coded) and an authorization problem (the blast radius was too wide because least privilege was not applied).

The single most repeated instinct across the domain: compute should carry an IAM role, and the role hands out temporary credentials, rather than any component holding a long-lived access key. A Lambda function, ECS task, or EC2 instance assumes a role (an execution role, task role, or instance profile) and AWS Security Token Service (STS) issues credentials that auto-rotate and expire (default one hour). The same role-plus-temporary-credential pattern reappears one layer in: a Cognito identity pool exchanges a signed-in user's token for scoped STS credentials so the browser never holds a static key either. Least privilege then means two distinct moves: grant only the actions and resources needed, and cap the maximum with a permissions boundary or session policy (which never grant, only ceiling). The exam's favourite wrong answer is an embedded access key where a role would do.

Encryption and secrets share one rule: the application should reference a managed resource, not carry the sensitive material. For encryption keys, AWS Key Management Service (KMS) holds the key and performs the cryptographic operation; the app never sees raw key material, and envelope encryption (a data key encrypts the data, a KMS key wraps the data key) is the default model for anything over KMS's 4 KB direct-encrypt limit. For credentials, Secrets Manager or Systems Manager Parameter Store holds the value and the app fetches it at runtime by IAM role, so the value can rotate without a redeploy, and it never appears in source control or a Lambda environment variable. The decision of which managed store to use turns on the same axes each time: does it need rotation, how large is it, and what does it cost, the deltas the per-subtopic pages develop.

Authorization is decided by the same logic wherever the permission is written. The effective decision is: the request is allowed only if some policy contains a matching Allow and no policy contains a matching explicit Deny. An explicit Deny always wins over any Allow. Within a single account, an Allow in either the identity-based policy (attached to the user or role) or the resource-based policy (attached to the bucket, queue, or KMS key) is sufficient. Cross-account access raises the bar: it needs an Allow on both sides, the caller's identity policy and the target's resource or trust policy must each permit it. Carrying this one model into the encryption layer explains why a KMS key policy is the root of trust there: IAM grants are inert until the key policy delegates to them, which is the same allow-from-either-side rule applied to a key.

Each control in this domain defends a specific boundary, and the exam rewards picking the one whose boundary matches the threat rather than reaching for the most powerful tool. Encryption in transit is a TLS concern (terminated by ACM-issued certificates), not a KMS concern: provisioning a KMS key for it is a classic distractor. Encryption at rest matches the storage service: SSE-S3 for zero-effort bucket encryption, SSE-KMS when you need an audit trail and key policy, client-side encryption when the data must stay opaque to AWS itself. For finding sensitive data, Amazon Macie inventories PII but only in S3. The instinct to build: name the boundary (in transit, at rest, in code, in S3) first, then choose the control whose job is exactly that boundary.