Security and Compliance
What you must know
IAM users, roles, policies, permission boundaries, and identity vs resource policies; cross-account access via role assumption; AWS Organizations SCPs; KMS key policies, grants, and envelope encryption; Secrets Manager vs Parameter Store (SecureString); GuardDuty, Security Hub, Inspector, Macie; WAF and Shield; VPC security groups vs NACLs; CloudTrail log integrity; S3 Block Public Access; IAM Access Analyzer; compliance frameworks via Artifact and Audit Manager.
Traps that show up in questions
- SCPs do not grant permissions - they only set the maximum. An SCP allowing an action still requires an IAM policy to actually permit it. Effective permission = intersection of SCP and identity policy.
- Permission boundaries cap what an identity policy can grant; they don't add access.
- Security groups are stateful and allow-only; NACLs are stateless, allow and deny, and evaluated in order. A question about blocking a specific IP wants a NACL (or WAF), not a security group.
- KMS key policy is the root of trust - an IAM policy alone cannot grant key access unless the key policy delegates to IAM.
- Secrets Manager vs Parameter Store: Secrets Manager supports automatic rotation and cross-account secret sharing; Parameter Store SecureString is cheaper but rotation must be built.
- GuardDuty detects threats, Inspector scans for vulnerabilities, Macie classifies sensitive data in S3, Security Hub aggregates findings.
- S3 Block Public Access overrides bucket policies - enabling it can break a deliberately public bucket.
Worked rule of thumb
For least-privilege cross-account automation: create a role in the target account with a trust policy scoped to the source account/principal, attach a minimal identity policy, and have the source assume it via STS. Never share long-term access keys - the exam consistently rewards role assumption over static credentials.