Memory hook: Follow the principal, the policy ceiling, the resource and the key.
Must remember
An assume-role design has two stages: the source must be allowed to request the role and the target trust policy must trust the appropriate principal/conditions; the resulting session then acts with the target role’s effective permissions. A resource-based grant can authorize supported direct cross-account access, but policy evaluation differs from assuming a role. Resource policies do not exist for every service.
Identity policies grant actions; permission boundaries and SCPs constrain applicable permissions. SCPs do not grant permissions, do not govern the management account in the same way as member accounts, and have documented exclusions such as service-linked roles. Explicit deny prevails where applicable. An allow-list SCP strategy requires appropriate allowance through the hierarchy, so a lower-level allow cannot repair an upper-level omission. Test policy changes in a limited OU with service dependencies and emergency access in view.
For third-party role access, an external ID helps address confused-deputy risk; it is not a secret password or a replacement for a precise trust principal. Service integrations may need source-account/source-ARN conditions. Organization conditions reduce repeated account lists but must match the actual supported request context; an absent condition key can change policy behavior.
Encrypted cross-account data needs both data-service authorization and the required KMS authorization. Sharing an encrypted snapshot or object while omitting key permissions is incomplete. AWS managed keys have sharing limitations that can require a copy encrypted under a customer managed key. Separate key administration from data use, and plan key retention for backups. A seven-day deletion window is still a future point of irreversible loss if the key is needed by retained data.
Central evidence should survive a workload-account compromise: organization trails where appropriate, narrowly scoped data events, protected log destinations, controlled key access and separate administration. CloudTrail records API activity; Config evaluates/configuration-records supported resources; CloudWatch observes metrics/logs. Delegated administration permits service-specific centralized operations without routine use of the management account. Preserve the ability to identify which workload principal performed the original action.
Scenario drill: an organization-wide deployment fails only when writing encrypted logs. Check the executing identity, service trust, SCP/boundary, destination policy and KMS path before granting administrator permissions. Diagnose the failed authorization edge rather than widening every boundary.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| External vendor administers a limited account function | Narrow cross-account role, precise trust and external ID as appropriate. |
| Object readable by policy but KMS denies decryption | Repair the key authorization path, not just the bucket policy. |
| Compromised workload must not erase its own evidence | Separately administered protected logging destinations. |
Traps
- External ID is not authentication by itself.
- An SCP allow does not grant an IAM action.
- Access to encrypted data can fail at either the resource or key boundary.
Active recall
1. What are the two stages of assuming a role?
Authorization/trust for assumption, then authorization of actions under the resulting session.
2. Can a permission boundary grant an action?
No; it limits what other grants can make effective.
3. Why can encrypted snapshot sharing fail?
The receiver may lack required key access or the key type may not support the sharing model.
4. Why separate log administration?
To reduce the chance that a compromised workload identity can erase evidence.
5. Why avoid routine management-account workloads?
Its special governance scope increases concentration and blast-radius risk.