Why architecture matters here
IAM without conditions is coarse. Same role, different context — dev vs prod, MFA vs no MFA — and you either over-grant or spawn ten similar roles. Conditions let one policy serve many contexts correctly.
The architecture matters because conditions interact with SCPs, resource policies, and boundaries. A permitted action at the identity policy must also survive the SCP and the resource policy. Tools like Access Analyzer and Policy Simulator help you prove what actually resolves to allow.
With the pieces mapped, IAM becomes maintainable at scale rather than a source of chronic audit findings.
The architecture: every piece explained
The top strip is the policy shape. Principal is the identity making the call. Policy statement combines Action + Resource + Condition. Context keys reference request context (aws:CurrentTime, aws:SourceIp) and service-specific keys. Tag conditions match on tags — aws:RequestTag (tags being applied) vs aws:PrincipalTag (tags on the caller) vs aws:ResourceTag (tags already on the resource).
The middle row is the evaluation surface. MFA + IP conditions restrict actions to authenticated sessions from approved networks. SCP overlay applies org-level guardrails that trump identity policies. Resource policy (bucket policies, KMS key policies) applies at the resource side; effective access is the intersection. Boundary caps what an identity can be effectively granted.
The lower rows are validation. Policy simulator lets you input a principal + action + context and see the answer. Access Analyzer reports unused permissions and external access. Ops covers policy versioning, tests, change review, and drift detection.
End-to-end flow
End-to-end: an engineer's role has a policy allowing s3:GetObject on any bucket tagged team=platform if the request has MFA. She authenticates with MFA and requests an object; policy evaluator sees the resource has team=platform tag, MFA context key is true; SCP doesn't block; resource policy allows; access granted. A second engineer without MFA hits the same API; condition fails; access denied. Access Analyzer later flags that another role has unused s3:PutObject on the same bucket; the finding is reviewed and removed. Policy simulator confirms current effective access matches intent.