AWS IAM Security Architecture – SCPs, Permission Boundaries & ABAC

AWS IAM Security Architecture — Overview

IAM is the largest exam domain on SCS-C03 (20%) and appears heavily on SAP-C02. This post covers the layered access control model: SCPs (organization guardrails) → Permission Boundaries (delegation limits) → Identity Policies (actual permissions) → Resource Policies (resource-level control). Understanding policy evaluation order and interaction is critical.

Service Control Policies (SCPs)

Common SCP Patterns (Exam Favorites)

• Prevent leaving Organization: Deny organizations:LeaveOrganization
• Prevent disabling CloudTrail: Deny cloudtrail:StopLogging, cloudtrail:DeleteTrail
• Prevent deleting GuardDuty: Deny guardduty:DeleteDetector, guardduty:DisassociateFromMasterAccount
• Restrict regions: Deny all actions unless aws:RequestedRegion is in allowed list (with exceptions for global services)
• Require encryption: Deny s3:PutObject unless s3:x-amz-server-side-encryption is present
• Prevent root user access: Deny all actions when aws:PrincipalArn matches root (doesn’t affect management account)

Permission Boundaries

• Purpose: Allow administrators to delegate user/role creation safely. The boundary sets maximum permissions that any identity policy can grant.
• Intersection model: Effective permissions = Identity Policy ∩ Permission Boundary. If boundary doesn’t allow s3:*, even AdministratorAccess policy can’t grant S3.
• Use case: DevOps team can create roles for their applications, but boundary ensures they can’t create roles with more permissions than they have themselves (privilege escalation prevention).
• Exam trap: Permission boundaries ONLY affect identity-based policies. Resource policies (like S3 bucket policy) bypass the boundary check.

ABAC (Attribute-Based Access Control)

• ABAC advantage: One policy works for all projects/teams. Tag a user with Project=Alpha, resources with Project=Alpha → access granted automatically.
• ABAC + SCPs: Use SCP to require tags on resource creation (aws:RequestTag must include Project)
• Session tags: SAML federation can pass tags (department, team) from IdP → IAM role → ABAC policy evaluation

IAM Policy Evaluation Logic

For same-account requests:

1. Explicit Deny? → DENIED (anywhere in any policy = final denial)
2. SCP allows? → If SCP doesn’t allow, DENIED
3. Resource policy allows? → If resource policy grants access (same-account), ALLOWED (skip remaining checks)
4. Permission boundary allows? → If boundary set and doesn’t include action, DENIED
5. Session policy allows? → If session policy set and doesn’t include action, DENIED
6. Identity policy allows? → If identity policy grants, ALLOWED. Otherwise, implicit DENIED.

For cross-account requests:

• BOTH sides must allow: Account A’s identity policy (or resource policy) must allow AND Account B’s resource policy must allow
• Exception: If Account B’s resource policy specifies Account A’s role ARN directly, Account A’s identity policy is not needed
• SCPs apply to the requesting principal’s account

Session Policies & Roles Anywhere

• Session policies: Passed when assuming role (AssumeRole API). Further restricts the role’s permissions for that session only. Effective = Role Policy ∩ Session Policy.
• IAM Roles Anywhere: Workloads OUTSIDE AWS (on-premises servers) can get temporary credentials by presenting a certificate from a registered CA trust anchor. Eliminates long-term access keys for hybrid workloads.
• Amazon Verified Permissions: Fine-grained authorization for applications using Cedar policy language. Externalize authorization logic from application code.

Exam Tips

AWS Certification Exam Practice Questions

Question 1:

A company wants to allow their development team to create IAM roles for Lambda functions, but prevent them from creating roles with more permissions than their own (privilege escalation). The solution must not require security team approval for each role creation. Which approach achieves this?

1. Create an SCP denying iam:CreateRole for the development OU
2. Require developers to attach a specific permission boundary to any role they create, enforced by a condition in their IAM policy
3. Create a Lambda execution role and require all functions use only this role
4. Use AWS Service Catalog to manage approved role configurations

Question 2:

An organization wants to ensure NO AWS account (except the management account) can disable CloudTrail or leave the organization, regardless of what IAM permissions exist in those accounts. How should this be implemented?

1. Remove iam:* from all accounts to prevent admin access
2. Apply an SCP at the organization root denying cloudtrail:StopLogging, cloudtrail:DeleteTrail, and organizations:LeaveOrganization
3. Create AWS Config rules to detect and auto-remediate these actions
4. Create EventBridge rules in each account to block these API calls

Question 3:

A company uses SAML federation from their on-premises Active Directory. They need engineers tagged with “Department=Engineering” in AD to only access EC2 instances tagged with “Department=Engineering” — without creating separate policies per department. Which approach provides this?

1. Create separate IAM roles per department, each with hardcoded resource ARNs
2. Use SAML session tags to pass Department attribute, then use ABAC policy with aws:PrincipalTag/Department condition matching aws:ResourceTag/Department
3. Use permission boundaries per department limiting resource access
4. Create resource policies on each EC2 instance allowing specific department groups

Question 4:

Account B has an S3 bucket with a bucket policy allowing Account A’s role to PutObject. However, when Account A’s role tries to upload, it gets AccessDenied. The role has s3:* in its identity policy. Account A has an SCP that allows all S3 actions. What is the most likely cause?

1. The bucket policy needs to specify the role ARN, not the account
2. Account B’s SCP is blocking the PutObject action
3. Account A’s permission boundary on the role doesn’t include s3:PutObject
4. S3 requires the request to include server-side encryption headers

Question 5:

A company has on-premises servers that need to call AWS APIs (S3, DynamoDB) without storing long-term access keys on the servers. The servers have certificates issued by the company’s private CA. Which solution eliminates long-term credentials?

1. Create an IAM user with access keys, rotate keys every 90 days
2. Set up a Site-to-Site VPN and use the VPC’s IAM capabilities
3. Configure IAM Roles Anywhere with the company’s private CA as trust anchor, servers present certificates to get temporary credentials
4. Use AWS SSO (IAM Identity Center) with SAML for machine-to-machine auth

Related Posts

• Multi-Account Architecture (Organizations & Control Tower)
• Zero Trust Architecture
• Data Encryption Architecture (KMS & CloudHSM)
• Centralized Logging Architecture
• DDoS & Edge Protection Architecture

References

• Permission Boundaries — AWS Docs
• Service Control Policies — AWS Docs
• ABAC for AWS — AWS Docs
• Least Privilege with StackSets — AWS Security Blog

Frequently Asked Questions

What is the difference between SCPs and Permission Boundaries?

SCPs apply to an entire AWS account (all principals within it). They set the maximum permissions for the account. Permission Boundaries apply to a specific IAM user or role. They limit what that specific principal can do. SCPs are set by the Organization admin; boundaries are set by the account admin. Both use the intersection model — effective permissions must be allowed by both.

Does the management account get restricted by SCPs?

No. The management account is always exempt from SCPs. This is by design — you can’t accidentally lock yourself out of the Organization. Because of this, best practice is to NOT run workloads in the management account. Use it only for Organization management, billing, and account creation.

How does ABAC scale better than RBAC?

With RBAC, you need N policies for N projects/teams (one policy per team specifying resource ARNs). With ABAC, you need ONE policy that uses tag conditions. When a new project starts, just tag the resources and users — no policy changes. The policy Condition: aws:ResourceTag/Project == ${aws:PrincipalTag/Project} automatically works for all current and future projects.