Memory hook: A grant, a ceiling, a trust relationship and a network path are four separate checks.
Must remember
- Identify the actual principal ARN/session, requested action, resource and condition keys. Identity policies and resource policies can grant access under different rules; boundaries, session policies and SCPs constrain applicable permissions. An explicit deny dominates. Role-session and same-account resource-policy exceptions mean simplistic intersection slogans can mislead.
- Cross-account role access needs a trusting target role and permission for the caller to assume it, plus no applicable deny. External IDs help prevent a third-party confused-deputy problem; they are not passwords. Use source-account/source-ARN conditions where supported for AWS service access.
- IAM Identity Center permission sets support workforce account access. Federation trust, session duration, MFA and emergency access need deliberate design. Permission boundaries delegate role creation while limiting potential rights; control who may change or remove the boundary.
- KMS has its own key-policy/grant and identity-permission evaluation. Cross-account encrypted-data access needs both data-resource access and the relevant key permissions. Rotating a key does not re-encrypt every existing object automatically. Multi-Region related keys do not make all policy and resource configuration global.
- SCPs, resource control policies where supported, organisation conditions and account boundaries serve different purposes. Apply controls through OUs and delegated administration, test exceptions and keep an audited emergency path. A deny aimed at one Region must account for global service behaviour.
- Use infrastructure pipelines, Config rules, security standards and automated remediation to maintain baselines. Classify controls as preventive, detective or responsive. Record evidence and exceptions; compliance frameworks guide controls but do not replace risk analysis.
- For containers and serverless, separate runtime role, execution/image-pull role and infrastructure role. Scan images/dependencies, restrict network paths and secrets, and audit tool/service access. For AI, treat prompts/retrieved content as untrusted and authorise tool actions outside the model.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Delegate role creation without unlimited escalation | Permission boundaries plus control of boundary removal and PassRole. |
| Allow a vendor to assume a customer role safely | Scoped trust and appropriate external-ID conditions. |
| S3 permits access but decryption fails | Inspect KMS key policy, identity permissions and grants. |
Traps
- An external ID is not a secret authentication credential.
- Allowing access in an SCP does not grant it.
- Network reachability does not imply authorisation.
Active recall
1. What must be identified before editing an AccessDenied policy?
The real caller/session, action, resource, request context and applicable policy layers.
2. Why does a resource policy need principal scope?
Otherwise it may authorise unintended identities even when local user policies look restrictive.
3. Can a central security control be safely deployed without testing exceptions?
No. Test global-service, service-role and emergency-access implications.
4. Why separate container task and execution roles?
Application permissions differ from platform operations such as image pulls and log setup.
5. Does key rotation make an exposed plaintext secret safe?
No. Revoke/rotate the secret itself and investigate its use.