AWS IAM — Interview & Certification Prep

Identities, policies and least privilege

IAM controls authentication (who you are) and authorization (what you may do) in AWS. Principals — IAM users, roles and AWS services — are granted permissions by policies: JSON documents listing allowed or denied actions on resources, optionally constrained by conditions. The guiding principle is least privilege: grant only the permissions actually needed. By default everything is denied, an Allow opens a permission, and an explicit Deny always overrides any Allow.

• Principals + policies (Allow/Deny actions on resources, with conditions)
• Default is implicit Deny; explicit Deny beats any Allow
• Least privilege is the baseline posture

Exam tip: Learn the evaluation order cold: explicit Deny > Allow > default (implicit) Deny. Many questions show a policy that "should" allow something but is overridden by a Deny or a missing Allow.

Source: AWS docs — IAM User Guide

Users vs Groups vs Roles

A user is a long-lived identity for one person or application, with optional long-term credentials (a password and/or access keys). A group is a collection of users you attach policies to, so permissions are managed by membership rather than per user. A role is an identity with NO long-term credentials that a trusted principal assumes to obtain temporary credentials — used by AWS services (EC2, Lambda), for cross-account access, and for federated logins. Prefer roles for workloads and groups for organizing human users.

• User = long-lived identity; Group = a policy-bearing set of users
• Role = assumable identity that yields temporary credentials
• Attach policies to groups/roles, not one-by-one to users

Exam tip: Groups cannot be nested and cannot be a Principal in a policy. Services (EC2/Lambda) and cross-account access use ROLES, never users.

Source: AWS docs — IAM User Guide

ARNs — naming every resource

An ARN (Amazon Resource Name) uniquely identifies an AWS resource, e.g. arn:aws:s3:::my-bucket/report.pdf or arn:aws:iam::123456789012:role/app. The parts are arn:partition:service:region:account-id:resource. Policies reference resources by ARN in the Resource element, and many services identify a Principal by ARN. Global services like S3 and IAM omit the region field.

• Format: arn:partition:service:region:account-id:resource
• Policies target resources by ARN; wildcards (*) allowed within a segment
• Global services (S3, IAM) leave the region blank

Exam tip: Recognize the ARN shape and that the account-id segment identifies ownership — key for cross-account questions.

Source: AWS docs — IAM User Guide

MFA and root account protection

Multi-Factor Authentication adds a second factor (a device code or hardware key) on top of a password. Enable MFA on the root user and on privileged IAM users, and avoid using the root user for daily work — create IAM identities instead. You can also require MFA for sensitive actions via a policy condition (aws:MultiFactorAuthPresent). Root has a few exclusive tasks (e.g. closing the account, changing certain account settings) but should otherwise be locked away.

• Enable MFA on root and privileged users; don't use root day-to-day
• Policy condition aws:MultiFactorAuthPresent can force MFA for sensitive actions
• Root has a few exclusive tasks; secure it and step away

Exam tip: Best practices: MFA on root, remove/avoid root access keys, use IAM roles/users for everything else.

Source: AWS docs — IAM User Guide

Identity-based vs resource-based policies

Identity-based policies attach to a principal (user/group/role) and say what that principal can do. Resource-based policies attach to a resource (an S3 bucket policy, an SQS queue policy, a KMS key policy) and say who can access that resource — including principals from OTHER accounts, which is how cross-account access can work without assuming a role. When both exist within one account, the effective permission is the union of what each allows (still subject to any explicit Deny and, in an organization, SCP guardrails).

• Identity-based → on the principal; resource-based → on the resource
• Only resource-based policies have a Principal element and enable cross-account access
• Effective permission = union of allows, minus any explicit Deny

Exam tip: S3 bucket policies, SQS/SNS access policies and KMS key policies are the classic resource-based examples — the ones with a Principal.

Source: AWS docs — IAM User Guide

Policy evaluation logic & explicit deny

When a request is made, AWS collects all applicable policies — identity-based, resource-based, permission boundaries, session policies and (in an org) SCPs — and evaluates them together. The decision: if any explicit Deny matches, the request is denied; otherwise an Allow is required somewhere; otherwise the implicit default Deny applies. A permission boundary or SCP can only REDUCE permissions — being in an SCP/boundary does not grant anything by itself.

• Explicit Deny always wins, everywhere
• You need an Allow AND no Deny AND to be within any boundary/SCP
• Boundaries and SCPs cap permissions; they never grant them

Exam tip: If a scenario has an SCP or boundary plus an identity policy, the effective permission is the INTERSECTION (both must allow), minus any explicit Deny.

Source: AWS docs — IAM policy evaluation logic

Roles, STS and temporary credentials

IAM roles provide temporary, automatically-rotated credentials that a principal assumes via STS AssumeRole, avoiding long-lived access keys. EC2 instances receive a role through an instance profile; Lambda functions use an execution role; other services assume service roles to act on your behalf. A role has two policy sides: a trust policy (WHO may assume it) and a permissions policy (WHAT it can do once assumed). Preferring roles over static user keys is a core security best practice.

• Roles = temporary credentials from STS, assumed by services/users
• Two policies: trust policy (who can assume) + permissions policy (what it can do)
• Avoid long-lived user access keys for workloads

Exam tip: EC2 uses an INSTANCE PROFILE to receive a role; STS AssumeRole issues the temporary credentials. "Attach a role, never store keys" is the expected answer.

Source: AWS docs — AWS STS

IAM roles for AWS services

AWS services assume roles to act on your behalf: EC2 (instance profile) to call APIs from an app, Lambda (execution role) to write logs and reach other services, ECS tasks (task role), and many managed services. The service is named as the trusted principal in the role's trust policy (e.g. lambda.amazonaws.com). This keeps credentials out of your code and lets you scope exactly what each workload can touch.

• Service roles name the service (e.g. lambda.amazonaws.com) in the trust policy
• EC2 → instance profile; Lambda → execution role; ECS → task role
• Scope each workload's role to least privilege

Exam tip: A Lambda that writes to CloudWatch Logs and reads a DynamoDB table needs exactly those permissions in its execution role — nothing more.

Source: AWS docs — IAM User Guide

Comparison: IAM user vs role, identity vs resource policy

IAM user vs role: a user has long-term credentials for a persistent identity (a person or legacy app); a role has NO long-term credentials and issues temporary ones on assumption (services, cross-account, federation). Identity-based vs resource-based policy: identity policies live on the principal and say what it can do; resource policies live on the resource, name a Principal, and enable cross-account access. Permission boundary vs SCP: a boundary caps one IAM identity; an SCP caps whole accounts/OUs — both only restrict.

• User = long-term creds; Role = temporary creds (prefer roles for workloads/cross-account)
• Identity policy = on principal; Resource policy = on resource (has Principal, enables cross-account)
• Boundary = per-identity cap; SCP = per-account/OU cap; both only restrict

Source: AWS docs — IAM User Guide

Cross-account access patterns

There are two ways to grant access across accounts. (1) Assume-role: account A creates a role whose trust policy allows a principal in account B to AssumeRole; B assumes it and gets temporary credentials scoped by the role's permissions — the recommended, auditable pattern. (2) Resource-based policy: the resource in A (e.g. an S3 bucket, KMS key or SQS queue) directly names B's principal, so B uses its own credentials. Assume-role centralizes control and works for services that lack resource policies; resource policies avoid an extra hop for the few services that support them.

• Assume-role: A's role trusts B; B gets temporary scoped credentials (recommended)
• Resource policy: the resource in A names B's principal directly
• Choose assume-role for auditability and services without resource policies

Exam tip: A role's trust policy defines WHICH accounts/principals can assume it; the permissions policy defines what they can then do. Both are required.

Source: AWS docs — AWS STS

Permission boundaries & SCPs

A permission boundary is a managed policy attached to an IAM user/role that sets the MAXIMUM permissions that identity can have — the effective permission is the intersection of the boundary and the identity's policies. It's used to safely let teams create their own roles without exceeding a cap. Service Control Policies (SCPs) are an AWS Organizations feature that caps permissions for entire ACCOUNTS/OUs. Neither grants anything — both only restrict.

• Permission boundary = max permissions for one identity (intersection with its policies)
• SCP = max permissions for whole accounts/OUs in an Organization
• Both only CAP; they never grant permissions

Exam tip: Permission boundary vs SCP: boundary applies to a single IAM identity; SCP applies to accounts/OUs. Both are ceilings, not grants.

Source: AWS docs — IAM User Guide

IAM Access Analyzer & least-privilege tooling

IAM Access Analyzer helps find resources (buckets, roles, keys, queues) that are shared with external principals or the public, so you can catch unintended access. It can also generate least-privilege policies from CloudTrail activity and validate policies against best practices. It turns "are we accidentally exposing something?" from a manual review into an automated finding.

• Finds resources shared externally/publicly (unintended access)
• Can generate least-privilege policies from observed activity
• Validates policies against best-practice checks

Exam tip: If a question asks how to DETECT resources shared outside the account/org, the answer is IAM Access Analyzer.

Source: AWS docs — IAM User Guide

Common permission failures

When a request is denied, work the evaluation logic: is there an explicit Deny (in any policy, boundary or SCP)? Is there an Allow at all? Is the Resource ARN correct (including the object path for S3)? For cross-account, is the trust policy present AND the permissions policy scoped? For KMS-encrypted resources, does the caller also have kms:Decrypt on the key? Missing KMS permissions is a classic hidden cause of "I can read the bucket policy but still get denied on the object".

• Check for explicit Deny, then for a matching Allow, then the Resource ARN
• Cross-account needs BOTH a trust policy and scoped permissions
• Encrypted data also needs KMS key permissions (kms:Decrypt)

Source: AWS docs — IAM policy evaluation logic