3.1.1. IAM Roles & Policies for Application Access

First Principle: IAM roles and policies provide the fundamental mechanism for granting AWS services and applications the precise, least privilege access they need to interact with other AWS resources, enhancing security and avoiding static credentials.

Loading diagram...

For developers, understanding how to apply AWS Identity and Access Management (IAM) is crucial for building secure applications. Instead of embedding static access keys directly in your application code, applications should assume IAM roles.

• IAM Roles: (Secure IAM identities that grant temporary permissions to AWS services or applications.)
  • How they work: An application (e.g., running on an EC2 instance, as a Lambda function) assumes an IAM role to obtain temporary security credentials. AWS manages the rotation of these credentials.
  • Benefits: Avoids hardcoding credentials, improves security by using temporary credentials, and simplifies credential management.
• IAM Policies: (JSON documents that define specific permissions.)
  • Attachment: Policies are attached to IAM roles to define what actions the application is allowed to perform on which resources (e.g., s3:GetObject on a specific Amazon S3 bucket).
  • Principle of Least Privilege: Always grant only the minimum permissions necessary for the application to function.
• Instance Profiles: (A container for an IAM role that you can use to pass role information to an EC2 instance when it launches.) Used to associate an IAM role with an EC2 instance.

Policy Types That Developers Must Distinguish

The exam tests whether you know which policy type applies in each scenario:

• Identity-based policies attach to IAM users, groups, or roles — they define what the principal CAN DO. Most developer-managed policies are identity-based (e.g., a Lambda execution role's policy).
• Resource-based policies attach to the resource itself — they define WHO CAN ACCESS IT. S3 bucket policies, Lambda resource policies, SQS queue policies, and SNS topic policies are all resource-based. The critical use case: cross-account access requires a resource-based policy on the target resource.
• Permissions boundaries set the MAXIMUM permissions an identity-based policy can grant — they don't grant permissions themselves. Think of them as guardrails.

Role-Based Access Control (RBAC) is the recommended pattern: create IAM roles for each application function (e.g., OrderProcessorRole, ImageResizerRole), attach only the permissions each needs, and have your compute services assume the appropriate role. This avoids the anti-pattern of one over-permissioned role shared by everything.

⚠️ Exam Trap: A Lambda function needs to be invoked by another AWS account. You add a resource-based policy to the Lambda function (not modify the execution role). Resource-based policies control WHO CAN INVOKE; execution roles control WHAT THE FUNCTION CAN ACCESS.

Scenario: You're developing a Lambda function that needs to upload files to an Amazon S3 bucket and read items from an Amazon DynamoDB table. You want to ensure it has only the necessary permissions and avoid storing any credentials in the function's code.

⚠️ Exam Trap: IAM policy evaluation: explicit Deny ALWAYS wins over explicit Allow. If any policy says Deny, the action is denied regardless of other Allow statements. The exam frequently tests this with scenarios mixing multiple policies.