IAM — Identity & Access Management
By Pritesh Yadav 24 min read —
IAM (Identity and Access Management) is how you control who can do what in your AWS account. It is free, global (not tied to a Region), and built from four building blocks: users (a person or app), groups (a bucket of users), roles (temporary identity you "assume"), and policies (JSON documents that grant or deny permissions). The exam loves to confuse these blocks, to test what only the root user can do, and to test the rule that an explicit deny always wins.
Most confused here: users vs groups vs roles vs policies; role (temporary, no stored keys) vs IAM user with access keys; identity-based vs resource-based policies; explicit deny overrides any allow; IAM is global, free, and the root user is different from an admin user.
Q1 An EC2 application needs to read files from an S3 bucket. A developer wants to avoid storing long-term credentials on the server. What is the AWS-recommended way to grant this access?
- Create an IAM user, generate access keys, and save them in a file on the EC2 instance
- Embed the root user's access keys in the application's environment variables
- Make the S3 bucket public so the instance does not need any credentials
- Attach an IAM role to the EC2 instance so it receives temporary credentials automatically
Answer: D
Why D is correct: An IAM role attached to an EC2 instance supplies short-lived, automatically rotated credentials. The app never stores a password or access key, which is the safest pattern for AWS compute talking to AWS services.
Why the other options are wrong:
- A — Long-term access keys saved on disk can be stolen and must be rotated manually; AWS explicitly recommends roles over keys for EC2.
- B — Root keys grant unlimited account access and should never be used by an application — a leak would compromise everything.
- C — Making the bucket public exposes the data to the entire internet, which is a serious security mistake, not an access-control solution.
Common trap: Candidates assume "credentials" always means access keys. For AWS compute reaching AWS services, the right answer is almost always a role, which uses temporary credentials instead of stored keys.
Q2 A company wants to give 30 new developers the same set of permissions. They expect to add and remove developers often. What is the most efficient IAM approach?
- Attach the same policy individually to each of the 30 IAM users
- Create one shared IAM user and give all 30 developers its password
- Create an IAM group, attach the policy to the group, and place the users in it
- Create 30 separate IAM roles, one per developer
Answer: C
Why C is correct: A group is a collection of users that share a policy. You attach permissions once to the group, and every member inherits them. Adding or removing a developer is just moving them in or out of the group.
Why the other options are wrong:
- A — Attaching the policy to each user individually works but is tedious and error-prone — exactly what groups are designed to avoid.
- B — Sharing one login breaks accountability; you can no longer tell which person performed an action, which violates least-privilege and auditing.
- D — Roles are assumed temporarily and are not meant to be a permanent identity for each human developer; this adds needless complexity.
Common trap: Groups cannot be nested and cannot themselves be granted to other groups — but for "many users, same permissions," a group is the textbook answer over per-user policies or shared logins.
Q3 Which task can ONLY be performed by the AWS account root user and not by an IAM user with full administrator permissions?
- Closing the AWS account and changing the account's email address
- Creating new IAM users and groups
- Launching EC2 instances in any Region
- Attaching policies to IAM roles
Answer: A
Why A is correct: A small set of account-level tasks are reserved for the root user, including closing the account and changing the root account's email and certain support-plan and billing settings. An admin IAM user cannot do these.
Why the other options are wrong:
- B — Creating IAM users and groups is a normal IAM administrative task that any admin user can do.
- C — Launching EC2 instances is a standard service action grantable to any IAM identity through policies.
- D — Attaching policies to roles is routine IAM administration, not a root-only action.
Common trap: Candidates think "full administrator" equals root. An admin IAM user can do almost everything, but a handful of account-wide actions (close account, change root email, change support plan) stay locked to root.
Q4 An IAM user is in a group whose policy allows deleting S3 objects, but the user also has a directly attached policy that explicitly denies deleting S3 objects. What happens when the user tries to delete an object?
- The action is allowed because an allow from a group outranks a deny on the user
- The result is random and depends on which policy AWS evaluates first
- The action is denied because an explicit deny always overrides any allow
- The action is allowed because the most recently created policy wins
Answer: C
Why C is correct: In IAM policy evaluation, if any policy contains an explicit deny for an action, that deny wins no matter how many allows exist. Deny always beats allow.
Why the other options are wrong:
- A — There is no "group outranks user" rule; AWS combines all applicable policies, and a deny anywhere blocks the action.
- B — Evaluation order does not change the outcome — the result is deterministic, and deny always prevails.
- D — Recency of a policy plays no role in evaluation; IAM does not use a "newest wins" tiebreaker.
Common trap: People assume more allows can overpower a deny. The order of precedence is: explicit deny > explicit allow > default (implicit) deny. One deny is enough to block everything.
Q5 A startup uses one AWS account. Their security reviewer says the root user is being used for daily work. What is the BEST first action to secure the account?
- Delete the root user entirely so it can never be used again
- Change the account Region to one with stronger security
- Give the root user a longer access-key rotation schedule
- Enable MFA on the root user and stop using it for everyday tasks, creating IAM users instead
Answer: D
Why D is correct: AWS best practice is to lock down the root user: turn on MFA (multi-factor authentication, a second login code), and use everyday IAM users or roles for normal work, keeping root only for the rare root-only tasks.
Why the other options are wrong:
- A — The root user cannot be deleted; it is permanently tied to the account, so you secure it instead.
- B — IAM is global and not Region-bound, so changing Regions does nothing for account security.
- C — Best practice is to delete root access keys, not keep them on a rotation schedule.
Common trap: "Delete the root user" sounds secure but is impossible. Root is forever — you protect it with MFA and disuse, not deletion.
Q6 A company running many AWS accounts wants employees to sign in once with their existing corporate directory and get the right permissions in each account. Which AWS service is designed for this centralized workforce sign-on?
- Amazon Cognito
- AWS IAM Identity Center (successor to AWS SSO)
- AWS Key Management Service (KMS)
- AWS Certificate Manager
Answer: B
Why B is correct: IAM Identity Center provides one place to manage workforce users and give them single sign-on across multiple AWS accounts, and it can connect to an existing corporate directory.
Why the other options are wrong:
- A — Amazon Cognito handles sign-in for your application's customers (web/mobile app users), not employee access to AWS accounts.
- C — KMS manages encryption keys, not user sign-in.
- D — Certificate Manager handles SSL/TLS certificates, unrelated to identity.
Common trap: Cognito vs IAM Identity Center. Cognito = your app's external customers; IAM Identity Center = your company's employees signing in to AWS.
Q7 A developer claims they must create separate IAM resources in us-east-1 and eu-west-1 because their app runs in two Regions. Why is this unnecessary?
- Because IAM users and policies are global and exist across all Regions automatically
- Because IAM only works in us-east-1 and ignores other Regions
- Because IAM resources must be duplicated per Region for redundancy
- Because IAM is a billing feature and has no Regional concept at all in pricing
Answer: A
Why A is correct: IAM is a global service. A user, group, role, or policy you create exists for the whole account and works in every Region — there is no need to recreate identities per Region.
Why the other options are wrong:
- B — IAM is not limited to us-east-1; it spans the entire account globally.
- C — IAM identities are not duplicated per Region; one definition covers all Regions.
- D — While IAM is free, the reason here is that it is global, not a billing technicality.
Common trap: Many AWS services are Regional, so candidates assume IAM is too. IAM (like Route 53, CloudFront, and WAF) is global.
Q8 An application in AWS Account A needs to access a DynamoDB table in AWS Account B. What is the recommended IAM mechanism to allow this cross-account access without sharing long-term credentials?
- Create an IAM user in Account B and email its access keys to Account A
- Make the DynamoDB table public so both accounts can reach it
- Create an IAM role in Account B that Account A is trusted to assume
- Merge both AWS accounts into one so IAM is shared
Answer: C
Why C is correct: Cross-account access is done with a role. Account B creates a role with a trust policy naming Account A; Account A's identity assumes the role and receives temporary credentials. No long-term keys are shared.
Why the other options are wrong:
- A — Emailing access keys is insecure, hard to rotate, and against best practice; roles exist precisely to avoid this.
- B — Making a database public exposes it to the world and is never a valid cross-account method.
- D — Merging accounts is drastic, often impossible, and unnecessary when role assumption solves the problem cleanly.
Common trap: Whenever the question says "cross-account access," the answer is an IAM role with a trust relationship — not shared keys.
Q9 Which statement correctly describes the difference between an identity-based policy and a resource-based policy?
- Identity-based policies attach to a user, group, or role; resource-based policies attach directly to a resource such as an S3 bucket
- Both policy types can only be attached to IAM users
- Resource-based policies are written in YAML while identity-based policies use JSON
- Identity-based policies are only for billing and resource-based policies are only for networking
Answer: A
Why A is correct: Identity-based policies are attached to an identity (user, group, or role) and say what that identity can do. Resource-based policies attach to the resource itself (like an S3 bucket policy) and say who may access that resource.
Why the other options are wrong:
- B — Resource-based policies attach to resources, not users, so this is false.
- C — Both policy types are JSON documents; AWS IAM policies do not use YAML.
- D — Neither is restricted to billing or networking; both control general access permissions.
Common trap: The S3 bucket policy is the classic example of a resource-based policy. If a policy "lives on the bucket," it is resource-based, not identity-based.
Q10 A security audit recommends "least privilege." Which action best reflects this principle?
- Grant every user full administrator access so no one is ever blocked
- Give each user only the specific permissions they need to do their job, and nothing more
- Give all users read-only access to the entire account regardless of role
- Share one powerful IAM user among the whole team
Answer: B
Why B is correct: Least privilege means granting the minimum permissions required for a task. If a leak or mistake happens, the damage is limited because the identity could only do its narrow job.
Why the other options are wrong:
- A — Full admin for everyone is the opposite of least privilege and dramatically increases risk.
- C — Blanket read-only for everyone still over-grants (some need no access) and under-grants (some need write), so it is not tailored to need.
- D — Sharing one powerful user destroys accountability and over-grants — the reverse of least privilege.
Common trap: "Least privilege" is about giving the smallest set of permissions per identity — not about giving everyone the same limited level.
Q11 A new IAM user is created with no policies attached. The user tries to list S3 buckets and is denied. Why?
- Because S3 is blocked for all IAM users by default
- Because the user must first enable MFA before any action is permitted
- Because new users are locked for 24 hours after creation
- Because IAM permissions start with an implicit deny — with no allow granted, the action is denied
Answer: D
Why D is correct: IAM denies everything by default (implicit deny). A new identity has no permissions until a policy explicitly allows an action. With nothing attached, every request is denied.
Why the other options are wrong:
- A — S3 is not specially blocked; the user is denied because nothing is allowed yet, not because of an S3 rule.
- B — MFA strengthens sign-in but is not required before permissions can work; the issue is the missing allow.
- C — There is no 24-hour lockout on new IAM users; permissions take effect immediately once granted.
Common trap: Beginners think new users start with some baseline access. IAM is "default deny" — no allow means no access.
Q12 An organization wants to enforce that all IAM users choose passwords of at least 14 characters with mixed character types and rotate them every 90 days. Which IAM feature enforces this?
- An IAM role trust policy
- An account password policy
- A resource-based bucket policy
- AWS Shield Advanced
Answer: B
Why B is correct: IAM lets you set an account-wide password policy that defines minimum length, required character types, expiration period, and reuse rules for all IAM users' console passwords.
Why the other options are wrong:
- A — A trust policy controls who may assume a role, not password rules.
- C — A bucket policy governs access to an S3 bucket, not user passwords.
- D — Shield Advanced is DDoS protection, completely unrelated to passwords.
Common trap: Password complexity is a built-in IAM password policy setting — not something you write as a JSON permission policy.
Q13 A mobile game has millions of players who sign in with Google or Facebook accounts and then save game data to AWS. Which service is built to handle this customer (web/mobile) identity and federation?
- Amazon Cognito
- AWS IAM Identity Center
- AWS Organizations
- Amazon GuardDuty
Answer: A
Why A is correct: Amazon Cognito manages sign-up and sign-in for app end-users, including federation with social logins like Google and Facebook, and gives them scoped, temporary access to AWS resources.
Why the other options are wrong:
- B — IAM Identity Center is for your workforce (employees) accessing AWS accounts, not for millions of app customers.
- C — Organizations manages multiple AWS accounts, not app user sign-in.
- D — GuardDuty is a threat-detection service, not an identity provider.
Common trap: Same Cognito-vs-Identity-Center split as before, framed from the customer side: app players/customers = Cognito.
Q14 Which statement about IAM roles versus IAM users is TRUE?
- A role has a permanent password and long-term access keys like a user
- A role can only ever be used by EC2 instances and nothing else
- A user and a role are identical and the terms are interchangeable
- A role is assumed temporarily and provides short-lived credentials, with no permanent password or access keys
Answer: D
Why D is correct: A role is an identity that is assumed when needed; AWS hands out temporary credentials that expire. Roles have no standing password or long-term keys, which makes them safer for services and cross-account access.
Why the other options are wrong:
- A — Roles deliberately have no permanent password or long-term keys — that is an IAM user feature.
- B — Roles can be assumed by EC2, Lambda, other AWS accounts, federated users, and more — not only EC2.
- C — Users and roles are different: a user is a permanent identity with credentials; a role is a temporary identity that gets assumed.
Common trap: The key word is "temporary." If the scenario needs a permanent human login, that is a user; if it needs temporary, assumable access, that is a role.
Q15 A finance employee needs to log in to the AWS Console every day to view billing dashboards as a permanent member of staff. Which IAM identity should you create for this person?
- An IAM role they assume anonymously with no login
- An IAM user with console access and least-privilege billing permissions
- A shared access key embedded in a spreadsheet
- The root user credentials handed to the employee
Answer: B
Why B is correct: A specific human who logs in regularly needs an IAM user with their own console password, granted only the billing-view permissions they need (least privilege).
Why the other options are wrong:
- A — Roles are for temporary, assumed access by services or federated identities, not a permanent daily human login with a password.
- C — Access keys are for programmatic API calls, not console sign-in, and storing them in a spreadsheet is insecure.
- D — Root must never be handed out for daily work; it has unlimited power and is reserved for rare account-level tasks.
Common trap: Roles are trendy, but a permanent human who signs in daily is the classic case for an IAM user, not a role.
Q16 What does adding MFA (multi-factor authentication) to an IAM user actually protect against?
- It encrypts all data stored in S3 buckets the user can access
- It requires a second proof of identity at sign-in, so a stolen password alone is not enough to log in
- It automatically grants the user administrator permissions
- It makes the user's actions exempt from explicit deny policies
Answer: B
Why B is correct: MFA adds a second factor (such as a code from a phone app or hardware key). Even if an attacker steals the password, they still cannot sign in without that second factor.
Why the other options are wrong:
- A — MFA secures sign-in; it does not encrypt stored data — that is the job of services like KMS and S3 encryption.
- C — MFA changes nothing about a user's permissions; it only strengthens authentication.
- D — Nothing exempts an identity from an explicit deny; deny always wins regardless of MFA.
Common trap: MFA is about authentication (proving who you are), not authorization (what you can do) or encryption.
Q17 Which of the following is the correct definition of an IAM policy?
- A JSON document that defines permissions — which actions are allowed or denied on which resources
- A physical hardware token used for MFA
- A group of AWS accounts managed together
- A temporary credential that expires after one hour
Answer: A
Why A is correct: A policy is a JSON document listing permissions: it states the effect (allow or deny), the actions, and the resources. You attach policies to users, groups, roles, or resources to grant access.
Why the other options are wrong:
- B — A hardware token is an MFA device, not a policy.
- C — A group of accounts managed together describes AWS Organizations, not a policy.
- D — A temporary expiring credential is what a role assumption produces, not a policy document.
Common trap: Don't mix the building blocks: policies = permission documents; roles = assumable identities; the two work together but are not the same thing.
Q18 A company asks how much IAM costs to manage users, groups, roles, and policies. What is the correct answer?
- IAM charges per IAM user per month
- IAM charges per policy evaluated
- IAM is offered at no additional charge
- IAM is billed based on the Region it runs in
Answer: C
Why C is correct: IAM itself is free. You can create users, groups, roles, and policies at no additional charge — you only pay for the AWS resources those identities use.
Why the other options are wrong:
- A — There is no per-user fee for IAM.
- B — AWS does not bill for policy evaluations.
- D — IAM is global and free, so there is no Region-based IAM charge.
Common trap: Note IAM Identity Center is also free, but some related services (like AWS Directory Service) can cost money. Core IAM is always no-charge.
Q19 An IAM user has a policy that allows all EC2 actions, but there is no policy anywhere that mentions S3. Can the user list S3 buckets?
- Yes, because allowing EC2 implicitly allows other services
- Yes, because any IAM user can read S3 by default
- No, because with no allow for S3, the implicit deny applies
- No, because EC2 and S3 cannot be used by the same user
Answer: C
Why C is correct: Permissions are per-action. Allowing EC2 does nothing for S3. With no S3 allow present, the default implicit deny blocks listing buckets.
Why the other options are wrong:
- A — Allowing one service never spills over to another; each action must be explicitly allowed.
- B — There is no default S3 read access for IAM users; everything starts denied.
- D — One user can absolutely have permissions across many services at once; that is not the limitation here.
Common trap: Candidates assume broad access "leaks" between services. Each service and action is granted independently; silence equals deny.
Q20 A solutions team needs an AWS Lambda function to write logs to CloudWatch and read from an S3 bucket. What should grant the function these permissions?
- An IAM user with access keys hardcoded into the function code
- The root user credentials passed as an environment variable
- An execution role attached to the Lambda function
- A password policy applied to the function
Answer: C
Why C is correct: AWS compute services like Lambda use an execution role. The role grants the function temporary permissions to call other AWS services (CloudWatch, S3) without any stored keys.
Why the other options are wrong:
- A — Hardcoding access keys is insecure and unnecessary when a role provides automatic temporary credentials.
- B — Root credentials must never be embedded anywhere; a leak would be catastrophic.
- D — A password policy governs human console logins, not what a function is permitted to do.
Common trap: Like EC2, Lambda gets permissions through a role (called an execution role), not through stored user keys.
Q21 Which scenario is the textbook use case for IAM federation rather than creating individual IAM users?
- Letting employees use their existing corporate (on-premises) directory logins to access AWS without separate IAM user accounts
- Storing encryption keys for a database
- Setting a minimum password length for the account
- Hosting a static website in S3
Answer: A
Why A is correct: Federation lets users authenticate with an existing external identity source (like a corporate directory) and then assume AWS permissions, so you avoid creating and managing a separate IAM user for each person.
Why the other options are wrong:
- B — Storing encryption keys is a KMS task, unrelated to identity federation.
- C — Password length is an IAM password policy setting, not federation.
- D — Hosting a website in S3 has nothing to do with how users authenticate.
Common trap: Federation = "reuse an existing identity provider to log in to AWS." If the question mentions an existing corporate directory or identity provider, think federation/roles, not new IAM users.
Q22 A manager says "We attached AdministratorAccess to the developer group, but we want one specific developer to be blocked from deleting production databases." What is the cleanest IAM way to achieve this?
- Remove the entire group so no one has admin access
- Change the AWS Region so the database cannot be deleted
- Delete the root user to reduce permissions
- Attach a policy to that developer with an explicit deny for the database-delete action
Answer: D
Why D is correct: Because an explicit deny always overrides an allow, attaching a deny for the specific delete action to that one developer blocks it even though the group still grants admin. Everyone else keeps full access.
Why the other options are wrong:
- A — Removing the group strips access from all developers, which is far more disruptive than needed.
- B — Regions are not a permission control; switching Regions does not restrict a user's actions.
- C — The root user cannot be deleted, and it is irrelevant to a specific developer's permissions.
Common trap: The exam rewards knowing that a targeted explicit deny is the surgical tool to carve out one action from broad admin access — deny beats allow.
Q23 Which best describes the relationship between IAM users and IAM groups?
- A group can be nested inside another group to inherit permissions
- A group is a way to assign permissions to many users at once; a user can belong to multiple groups
- A group is a temporary identity that issues short-lived credentials
- Each user can belong to only one group at a time
Answer: B
Why B is correct: Groups simplify permission management by letting you attach policies once and apply them to all members. A single user can be a member of several groups and inherits the combined permissions.
Why the other options are wrong:
- A — IAM groups cannot be nested; you cannot place a group inside another group.
- C — A temporary identity issuing short-lived credentials is a role, not a group.
- D — A user can belong to multiple groups at the same time, not just one.
Common trap: Two facts get missed: groups cannot be nested, and a user can be in many groups. Both are commonly tested limits.
Q24 A company wants programmatic access for a script running on an on-premises server (not on AWS) to call AWS APIs. The server cannot assume a role easily. What does the script most likely need?
- The root user's console password typed into the script
- A CloudFront distribution pointing at the server
- An S3 bucket policy attached to the server
- An IAM user's access key ID and secret access key configured on the server
Answer: D
Why D is correct: Programmatic (API/CLI) access uses access keys — an access key ID and secret access key. For an outside server that cannot easily assume a role, an IAM user's access keys are the standard credential, kept least-privilege and rotated regularly.
Why the other options are wrong:
- A — A console password is for browser sign-in, not API calls, and root must never be used in scripts.
- B — CloudFront is a content delivery network, not a credential for calling AWS APIs.
- C — A bucket policy controls access to an S3 bucket; it is not a credential a server uses to authenticate.
Common trap: Roles are preferred on AWS compute, but for an external/on-prem system that can't assume a role, IAM user access keys (programmatic credentials) are the expected answer — console passwords are for humans in the browser.