LEARN. PRACTICE. GROW.Trace the hierarchy before changing access
Start by recording account, principal, action, resource, context, and time. This exercise considers only the SCP boundary for a member account; assume other policies permit the action. At each level of the root, OU, and account chain, look for at least one applicable Allow. Permissions allowed by policies at the same level combine, then remain limited by other levels. An applicable Deny anywhere on the chain blocks the action. This method avoids reading one policy in isolation. In the lab worksheet, write one row per level and identify the first missing condition. Do not remove the entire policy as an experiment. Prepare a narrow change proposal, a positive test, and a negative test confirming that the intended restriction remains.
Guided exercise: entering a production OU
A fictional reconciliation account moves from Sandbox into Funds. In the destination, the root allows everything, the Funds OU allows only s3:GetObject, and the account allows everything. An IAM-authorized role attempts s3:PutObject. The Funds OU lacks the Allow, so that boundary blocks the request. Adding an Allow only at account level does not fix it. If that same OU also has FullAWSAccess, its narrower Allow no longer limits the set on its own. Discuss these two variants separately. Before moving, collect operations used by closing jobs, approve the access matrix, and rehearse in a representative account. During the window, confirm the actual principal and compare the result with the prediction. A test using different administrative credentials does not demonstrate that the production role works.
Delegation and identity ownership
Distinguish access administration, identity-source configuration, and access to the management account. The IAM Identity Center delegated administrator cannot change a permission set provisioned in the management account. In the fictional situation, NightSupport was reused there and in member accounts; the team should separate management access and route the change through the authorized administrator. If the external IdP owns group membership, local edits may be overwritten by synchronization. Identify who approves membership and who may issue SCIM tokens. In handover, explain this chain to the APS shift with contacts and escalation criteria. Avoid resolving an incident by creating a second informal identity source that nobody maintains.
Control behavior and acceptance evidence
Record each control’s mechanism, scope, and expected result. A detective control reports deviations; that does not establish that it prevented creation. A proactive control uses CloudFormation hooks and applies to resources provisioned through that path. A direct API change needs its own coverage analysis. The inspected guide also states that, from landing zone 4.0, mandatory controls are no longer applied by default. Confirm version and effective state instead of treating the mandatory label as proof of activation. For the change committee, prepare four columns: requirement, mechanism, observed test, and deviation owner. This matrix supports a temporary exception with an expiry without presenting the landing zone as automatic compliance evidence.
SCP worksheet (fictional; not deployable policy)
ROOT Allow:*
OU/FUNDS Allow:s3:GetObject
ACCOUNT Allow:*
REQUEST s3:PutObject
OTHER AUTHORIZATION: assumed sufficient
EXPECTED SCP RESULT: blocked at OU/FUNDSAccept the OU move only after testing the batch role, the restriction that must remain active, and the night-shift escalation path.
Common pitfalls
Reading only one SCP; confusing policies at one level with successive levels; assuming delegation permits management-access changes; treating an alert as prevention.
Related topics: Rollouts and operational evidence
Demonstrate control scope and composition on the operation’s actual path.
Reference: SCP evaluation · SAP-C02