Memory hook: First identify the caller, then find its grants, its permission ceilings and every applicable explicit deny.
Must remember
Follow the permission decision
- Identity policies grant actions to users, groups and roles. Permissions boundaries limit the permissions that identity policies can grant. Service control policies (SCPs) set organization-level permission ceilings for affected member accounts. Neither a boundary nor an SCP grants access merely by allowing an action.
- SCP scope: member-account principals, including the member account's root user, are affected; management-account principals and service-linked roles are not. An account's SCP also does not constrain an external account's principal merely because it accesses that account's resource. Resource-access policies and controls must address that separate boundary.
- Explicit deny wins. For ordinary identity-policy access, a grant must survive the applicable boundary, session policy and organization restrictions. Do not turn that mnemonic into a universal set-intersection algorithm: resource-policy grants to users, role principals and role-session principals have different evaluation details.
- Role trust answers who may assume the role; the role's permission policies answer what the resulting session can do. Cross-account assumption normally needs suitable caller authorization and target trust. STS provides temporary credentials rather than a new long-lived access key.
- A resource-based policy can authorize a supported resource directly; assuming a role changes the effective identity used for subsequent operations. Choose according to the service and access pattern. Cross-account access also requires the applicable permissions on both sides.
- IAM simulation is useful evidence for supported policy evaluation, but it does not fully test every trust, organization, resource-policy or runtime context. A successful simulation of an action is not proof that MFA-conditioned role assumption will succeed.
Conditions carry request context
- aws:SourceIp constrains supported source-IP contexts. Calls through services or private endpoints can have different context; a public source-IP restriction is not a universal VPC restriction.
- aws:RequestedRegion tests the Region of the requested endpoint. Account for global services and cross-Region side effects; it is not automatically a guarantee that all resulting data stays in that Region.
- aws:PrincipalOrgID constrains supported access by organization membership. It can reduce the need to enumerate account IDs in suitable resource policies, but does not grant every principal the intended action.
- MFA conditions depend on how credentials and sessions were obtained. Do not assume a federated sign-in with MFA always supplies aws:MultiFactorAuthPresent in subsequent requests. A missing condition key matters to the selected policy operator.
- Least privilege includes actions, resources and conditions. Keep the operator identity separate from the role being tested so an exercise cannot silently weaken your own account access.
Multi-account and workforce choices
- Organizations groups accounts; OUs organize accounts for governance; SCPs constrain permissions. Separate production, development and shared services where isolation and governance require it. Organization policies do not replace each account's grants or data policies.
- IAM Identity Center provides workforce access through permission sets and account assignments, commonly backed by an external identity provider and temporary credentials. Consumer signup belongs to a different pattern, such as Cognito; see application identity.
- Directory Service: Managed Microsoft AD provides managed AD capabilities and supported trusts; AD Connector proxies authentication to an existing directory; Simple AD supplies a smaller compatible feature set where available. “Already have AD” is a clue to compare integration requirements rather than create another independent user database.
- AWS Resource Access Manager (RAM) shares supported resources across accounts, organizations/OUs or supported principals. A centrally owned subnet or Transit Gateway can be shared instead of duplicated. Resource sharing does not give participants universal ownership or bypass their IAM restrictions; supported resource types and sharing rules differ.
- Control Tower establishes governed multi-account landing zones with controls and integrated services. It is broader than one role or SCP. This pack treats Organizations and Control Tower as design concepts and leaves account-wide governance unchanged.
Choose under exam pressure
| Clue in the requirement | Choose or investigate |
|---|---|
| Employees need consistent temporary access across accounts | Identity Center permission sets and assignments |
| Developers create roles but must stay inside a maximum scope | Permissions boundaries plus controlled delegation |
| Restrict allowed services across an OU | SCPs, alongside actual identity grants |
| Share an existing supported network resource across accounts | RAM |
| Define who can assume an application role | Role trust policy |
| Existing directory must authenticate supported AWS workloads | Compare AD Connector and Managed Microsoft AD capabilities |
| Build a governed multi-account landing zone | Control Tower concept |
Traps
- Adding another Allow cannot override an explicit Deny or a limiting permissions boundary.
- A role ARN in a trust document is not the same thing as a resource permission granting that role every operation.
- Organization membership, network origin and MFA are different request properties; one condition does not establish the other two.
Active recall
1. An identity policy grants EC2 describing, but its boundary permits only S3. Will another EC2 Allow fix the request?
No. For this identity-policy request, the boundary still limits the grant. Amend the legitimate boundary design if appropriate; adding duplicate identity Allows does not change the ceiling.
2. A team can simulate an allowed S3 action for a role but cannot assume it. Where should it investigate?
Examine target trust, caller authorization and request conditions such as MFA. Simulating the role's permissions answers a different question from obtaining that role's credentials.
3. A central networking account owns a supported shared subnet. Must each application account create a duplicate subnet?
No. Evaluate RAM sharing with the required organization/resource prerequisites. The networking owner retains its resource responsibilities while participants operate within supported sharing permissions.
4. Thousands of employees need access to several AWS accounts. Why prefer workforce federation over individual permanent access keys?
Centralized identity and Identity Center permission sets simplify assignment and revocation while issuing temporary sessions. Permanent keys create a separate lifecycle and exposure problem for every employee.
5. An SCP allows S3 in a member account, but the user has no applicable grant. Is the request authorized?
No. The SCP permits the possibility of the action; it does not supply the missing identity or supported resource-policy grant. Permission ceilings and permissions are separate.
Terraform anchor: Decode policies to inspect them, but use the actual IAM evaluation model rather than treating a toy action-set calculation as an authorization engine.
Sources
- IAM policy evaluation explains grants, boundaries and explicit denies.
- Global condition keys documents request-context semantics.
- SCP behavior describes organization-level permission limits.
- RAM overview explains supported cross-account resource sharing.
- Directory Service choices distinguishes managed and connected directory approaches.