IAM (Identity and Access Management) policies and permissions form the foundation of access control in AWS, enabling organizations to manage who can access resources and what actions they can perform. IAM policies are JSON documents that define permissions through statements containing Effect (Allo…IAM (Identity and Access Management) policies and permissions form the foundation of access control in AWS, enabling organizations to manage who can access resources and what actions they can perform. IAM policies are JSON documents that define permissions through statements containing Effect (Allow or Deny), Action (specific API operations), Resource (ARN of affected resources), and optional Conditions. There are several policy types: Identity-based policies attach to users, groups, or roles; Resource-based policies attach to resources like S3 buckets; Permission boundaries set maximum permissions for IAM entities; Organizations SCPs define maximum permissions for member accounts; and Session policies limit temporary credential permissions. Policy evaluation follows a specific logic: explicit Deny always wins, then explicit Allow, with implicit Deny as the default. For cross-account access, both the identity policy in the source account and the resource policy in the destination account must grant permission. Best practices include implementing least privilege principle, using IAM groups for permission management, leveraging managed policies for common use cases, and regularly reviewing permissions using IAM Access Analyzer. For complex organizations, consider using AWS Organizations with SCPs to establish guardrails across accounts, implementing attribute-based access control (ABAC) using tags for scalable permission management, and creating custom managed policies for specific job functions. Permission boundaries are particularly useful for delegating IAM administration while preventing privilege escalation. When designing solutions, understand that effective permission strategies combine multiple policy types working together. Use policy conditions to add granular controls based on IP addresses, time, MFA status, or resource tags. Regular audits using IAM credential reports and Access Advisor help maintain security posture and identify unused permissions that should be removed.
IAM Policies and Permissions - Complete Guide for AWS Solutions Architect Professional
Why IAM Policies and Permissions Matter
IAM policies and permissions form the foundation of security in AWS. As a Solutions Architect Professional, you must understand how to design secure, scalable, and compliant access control mechanisms for complex organizational structures. Misconfigurations can lead to security breaches, compliance violations, or operational disruptions.
What Are IAM Policies?
IAM policies are JSON documents that define permissions. They specify who can do what on which resources under what conditions. There are several policy types:
• Identity-based policies: Attached to users, groups, or roles • Resource-based policies: Attached to resources like S3 buckets or SQS queues • Permission boundaries: Set maximum permissions an identity can have • Organizations SCPs: Define maximum permissions for accounts in an organization • Session policies: Limit permissions for temporary sessions • Access control lists (ACLs): Legacy mechanism for cross-account access
How IAM Policy Evaluation Works
AWS evaluates policies using a specific logic flow:
1. Explicit Deny: Any explicit deny in any policy results in denial 2. Organizations SCPs: Must allow the action for member accounts 3. Resource-based policies: Can grant access for cross-account scenarios 4. Permission boundaries: Must allow the action if set 5. Identity-based policies: Must explicitly allow the action 6. Session policies: Must allow if using temporary credentials
Default behavior is implicit deny - if no policy explicitly allows, access is denied.
Key Policy Elements
• Version: Always use 2012-10-17 • Statement: Container for permissions • Effect: Allow or Deny • Principal: Who the policy applies to (resource-based only) • Action: What operations are allowed or denied • Resource: Which AWS resources the policy applies to • Condition: When the policy is in effect
Cross-Account Access Strategies
For organizational complexity, understand these patterns:
• Resource-based policies: Grant access to principals in other accounts • IAM roles with trust policies: Allow cross-account role assumption • AWS Organizations: Use SCPs for centralized governance • AWS Resource Access Manager: Share resources across accounts
Permission Boundaries
Permission boundaries are advanced features that set the maximum permissions. The effective permissions are the intersection of identity-based policies and permission boundaries. This is crucial for delegated administration scenarios.
Service Control Policies (SCPs)
SCPs in AWS Organizations provide guardrails across accounts: • They do not grant permissions, only restrict them • They affect all users and roles in member accounts, including the root user • They do not affect the management account • They work as a filter on what permissions are available
Exam Tips: Answering Questions on IAM Policies and Permissions
1. Remember the deny hierarchy: Explicit deny always wins. If a question shows conflicting policies, look for explicit denies first.
2. Cross-account access requires both sides: The resource account must allow access AND the requesting account must grant the principal permission to access the external resource.
3. SCPs vs IAM policies: SCPs limit what CAN be done; IAM policies grant what IS allowed. Effective permissions are the intersection.
4. Permission boundaries for delegation: When the scenario involves delegating admin rights while limiting scope, permission boundaries are typically the answer.
5. Principle of least privilege: Exam answers favoring minimal required permissions are usually correct.
6. Conditions are powerful: Look for condition keys like aws:SourceIP, aws:PrincipalOrgID, or aws:RequestedRegion for complex scenarios.
7. Resource-based vs role assumption: Resource-based policies allow the principal to retain their original permissions; role assumption means the principal gets only the role permissions.
8. Read carefully for account context: Determine if the scenario is single-account or multi-account, as this changes the solution approach.
9. NotAction and NotResource: These are not denies - they mean everything except the specified items. Common exam trap.
10. Policy size limits matter: Managed policies have a 6,144 character limit. For complex scenarios, consider multiple policies or policy variables.