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.

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.
• AWS managed vs. customer managed policies: AWS managed policies (e.g., AmazonS3ReadOnlyAccess) are written and kept up to date by AWS as services add new actions, but you cannot edit them. Customer managed policies are yours to edit and scope tightly. Inline policies are embedded in a single identity.

Anatomy of a Policy Statement

For cross-account access without a role, both sides must agree: the resource-based policy in Account B names the caller as Principal, AND the caller's identity-based policy in Account A allows the action.

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. For people, the same job-function idea uses IAM groups: attach a DeveloperPolicy to a Developers group and add each developer's user to it, so permissions are managed per job function rather than per user.

Temporary Credentials: STS, Role Assumption, and Federation

• AWS STS issues temporary, limited-privilege credentials. A successful sts:AssumeRole call returns an access key ID, a secret access key and a session token, with an expiry. It never returns long-term keys.
• Assuming a role takes two policies: the role's trust policy names who may assume it, and the caller's permission policy allows sts:AssumeRole on that role. For cross-account access, Account B's role trusts Account A, and the application in Account A calls sts:AssumeRole.
• Third parties: require an ExternalId condition in the role's trust policy, so another customer of the same vendor cannot trick the vendor into using your role (the "confused deputy" problem).
• Federation: an identity provider (IdP), such as a corporate SAML 2.0 directory or an OIDC provider, authenticates users and AWS trusts its assertion. The user assumes an IAM role (AssumeRoleWithSAML / AssumeRoleWithWebIdentity) and receives temporary STS credentials, so no IAM user is created per employee. For app users who sign in with Google or Facebook, Cognito Identity Pools (3.1.2) handle this for you.
• Where code finds credentials: SDKs and the CLI look for credentials through a default credential provider chain (see 1.5.1 and 1.5.2). On EC2, the role's temporary credentials come from the instance metadata service (http://169.254.169.254/) and are refreshed automatically; the SDK reads them for you, with no AssumeRole call. Scripts running outside AWS use an IAM user's access key ID and secret access key.

⚠️ 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.