IAM Foundations

Concepts Covered

• IAM principals
• Users, groups, and roles
• Identity-based policies
• Resource-based policies
• Trust policies
• Temporary credentials
• Permission boundaries
• Service control policies
• Least privilege
• Cross-account access

1. Plain-English Definition

AWS Identity and Access Management, usually called IAM, is the AWS system for deciding who or what can do something.

The "who or what" is a principal. A principal can be a human user, an application, an AWS service, a federated identity, or another account. The "do something" is an AWS action, such as s3:GetObject, ec2:RunInstances, or dynamodb:PutItem. The "something" is usually a resource, such as a bucket, instance, table, key, role, or queue.

The core IAM question is:

Can this principal perform this action on this resource under these conditions?

IAM answers that question by evaluating policies. Policies are JSON documents that allow or deny actions. Some policies attach to identities. Some attach to resources. Some define who can assume a role. Some set the maximum permissions available.

For AWS architecture, IAM is not a side topic. It is the access layer for almost every service.

2. Why This Matters In AWS

AWS is API-driven. Creating an EC2 instance, reading an S3 object, invoking a Lambda function, describing a VPC, decrypting with KMS, or changing an RDS setting is an API action. IAM controls those actions.

This means IAM mistakes can be severe. A role with AdministratorAccess can do almost anything in an account. A public S3 bucket policy can expose data. A broad trust policy can allow the wrong principal to assume a role. Long-lived access keys can leak. A missing explicit deny can allow a user to bypass an intended rule through another permission path.

For SAA-C03, IAM appears in many forms: EC2 instance roles, S3 bucket policies, cross-account access, service-to-service permissions, least privilege, temporary credentials, federation, and organization guardrails.

For real AWS work, IAM is how architecture becomes enforceable. Diagrams show boundaries. IAM decides whether those boundaries hold.

3. The Beginner Mental Model

Think of IAM as a permission engine.

The engine receives a request:

principal -> action -> resource -> context

Then it checks policies. If there is no allow, the request is denied by default. If there is an allow and no applicable explicit deny, the request can proceed. If there is any applicable explicit deny, the request is denied.

Three identity types matter early:

• IAM user: a long-term identity in an account, historically used for people or applications
• IAM group: a collection of users for policy attachment
• IAM role: an identity with permissions that can be assumed by trusted principals

Roles are especially important. EC2 instances, Lambda functions, ECS tasks, and other services should usually use roles instead of hardcoded credentials. Humans should usually access AWS through federation or IAM Identity Center rather than permanent IAM users.

4. What That Mental Model Misses

IAM is not just identity-based policies.

Resource-based policies also matter. S3 bucket policies, KMS key policies, SQS queue policies, SNS topic policies, and Lambda resource policies can grant access to resources, including cross-account access.

Trust policies matter for roles. A role has permissions that define what it can do after it is assumed, but its trust policy defines who can assume it. Both sides must be correct.

Permission boundaries can limit the maximum permissions an IAM entity can receive. Service control policies from AWS Organizations can limit what accounts are allowed to do. Session policies can further restrict temporary sessions. This means an "allow" in one place may still be blocked by a guardrail somewhere else.

IAM is also not a network firewall. A private subnet can hide an EC2 instance from the internet, but IAM still controls whether that instance role can read secrets, write S3 objects, or call DynamoDB.

5. AWS Mechanics

IAM policy evaluation starts with a default deny. AWS then checks identity-based policies, resource-based policies, permission boundaries, session policies, and organization-level controls depending on the request. Any explicit deny wins.

An identity-based policy attaches to a user, group, or role. It says what that identity can do.

A resource-based policy attaches to a resource. It says who can access that resource. S3 bucket policies are the common beginner example.

An IAM role has two key parts:

• a trust policy that says who can assume the role
• permission policies that say what the role can do

Temporary credentials are issued when a role is assumed. This is why roles are preferred for workloads. An EC2 instance profile lets EC2 applications receive temporary credentials from the instance metadata service without storing access keys.

Conditions add context. A policy can allow access only from a certain VPC endpoint, only with MFA, only for specific tags, only from a source account, or only when encryption is requested.

6. Architecture Examples

An EC2 web server that needs to read application assets from S3 should use an instance role. The role might allow s3:GetObject only for a specific bucket prefix. The application receives temporary credentials automatically from the instance metadata service.

A Lambda function that writes to DynamoDB should use an execution role with only the table actions it needs. It should not use a human user's access key.

A central logging account might allow application accounts to write CloudTrail logs into a shared S3 bucket. That requires a bucket policy and careful conditions so only expected accounts and services can write to the right location.

A third-party vendor may need to inspect resources in your account. The safer pattern is to create a cross-account role with an external ID condition and limited read-only permissions, not to create a permanent IAM user and send access keys.

7. SAA-C03 Exam Signals

"Application running on EC2 needs access to S3" points to an IAM role attached to the EC2 instance profile.

"Avoid long-term credentials" points to roles, federation, or temporary credentials.

"Grant another AWS account access to a bucket" points to a bucket policy, IAM role, or both, depending on the direction of access.

"Centrally restrict what member accounts can do" points to AWS Organizations service control policies, not a normal IAM policy in one account.

"Require MFA for sensitive API calls" points to IAM policy conditions.

"Least privilege" means granting only the required actions on the required resources, not attaching broad managed policies for convenience.

8. Common Traps

Do not store access keys on EC2 instances when an instance role can be used.

Do not confuse a role trust policy with a permission policy. Trust controls who can assume the role. Permissions control what the role can do after assumption.

Do not assume an allow always works. Explicit denies, SCPs, permission boundaries, resource policies, and session policies can still block the request.

Do not use root user credentials for normal work.

Do not give humans and applications the same credential pattern. Humans usually need federation, MFA, and auditable sessions. Applications usually need roles and temporary credentials.

Do not rely on naming conventions as security. IAM evaluates policies, principals, resources, and conditions.

9. What To Learn Next

Next, study the VPC Networking Model. IAM controls API access, while VPC design controls network placement and traffic paths.

Then study Amazon S3, because S3 is one of the best services for learning how identity policies and resource policies work together.

Official AWS references:

• IAM User Guide
• Policy evaluation logic
• IAM roles