IAM Policies and Permissions - AWS Developer Associate Guide
Why IAM Policies and Permissions Are Important
IAM (Identity and Access Management) policies and permissions form the foundation of AWS security. They control who can access what resources and what actions they can perform. Understanding IAM is critical for the AWS Developer Associate exam because security is integrated into every AWS service, and misconfigurations can lead to data breaches or service disruptions.
What Are IAM Policies?
IAM policies are JSON documents that define permissions. They specify:
- Effect: Allow or Deny
- Action: The specific API operations (e.g., s3:GetObject, ec2:StartInstances)
- Resource: The AWS resources the policy applies to (using ARNs)
- Condition: Optional circumstances under which the policy applies
Types of IAM Policies:
- Identity-based policies: Attached to users, groups, or roles
- Resource-based policies: Attached to resources like S3 buckets or SQS queues
- AWS Managed policies: Pre-built by AWS for common use cases
- Customer Managed policies: Created and managed by you
- Inline policies: Embedded within a single user, group, or role
How IAM Policies Work
When a principal (user, role, or service) makes a request, AWS evaluates all applicable policies using this logic:
1. By default, all requests are denied (implicit deny)
2. An explicit Allow overrides the implicit deny
3. An explicit Deny always overrides any Allow
This means: Deny always wins
Policy Evaluation Order:
AWS evaluates Organization SCPs → Resource-based policies → Identity-based policies → Permission boundaries → Session policies
Key Policy Elements Example:
{
"Version": "2012-10-17", "Statement": [{
"Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::my-bucket/*", "Condition": {
"IpAddress": {"aws:SourceIp": "192.168.1.0/24"}}}]
}
Important Concepts for the Exam:
- Principal: The entity making the request (user, role, federated user, application)
- Permission Boundaries: Set maximum permissions an identity-based policy can grant
- Resource-based policies: Allow cross-account access when attached to resources
- Policy Variables: Dynamic values like ${aws:username} for flexible policies
- NotAction and NotResource: Specify exceptions rather than explicit lists
Common Use Cases:
- Granting developers read-only access to production resources
- Allowing Lambda functions to access DynamoDB tables
- Enabling cross-account S3 bucket access
- Restricting access based on IP address or time of day
Exam Tips: Answering Questions on IAM Policies and Permissions
1. Remember the Deny Rule: If a question involves conflicting Allow and Deny statements, the answer involving Deny takes precedence.
2. Principle of Least Privilege: AWS best practice questions favor answers that grant minimal necessary permissions.
3. Cross-Account Access: Resource-based policies enable cross-account access. For S3, SQS, SNS, and Lambda, look for resource-based policy solutions.
4. Policy Conditions: When questions mention IP restrictions, MFA requirements, or time-based access, look for answers using Condition elements.
5. Managed vs Inline Policies: Prefer managed policies for reusability; inline policies are for strict one-to-one relationships.
6. Service-Linked Roles: These are predefined by AWS services and cannot be modified. Questions about service permissions often involve these.
7. Trust Policies: For role assumption questions, remember that roles need trust policies specifying who can assume them.
8. Wildcard Usage: Understand that * means all actions or resources, and questions may test your knowledge of overly permissive policies.
9. Policy Simulator: When questions ask about testing or troubleshooting permissions, the IAM Policy Simulator is the correct tool.
10. Version Field: The policy version should be "2012-10-17" - this is the current version that supports all policy features.