Question 1

What is AWS IAM?

Accepted Answer

Identity and Access Management controls authentication and authorisation for AWS. It manages identities — users, groups and roles — and policies that define what actions are allowed or denied on which resources under which conditions. It is global rather than regional and is free to use. The framing to give is that IAM answers "who can do what to which resource under what conditions", with conditions being the part candidates most often overlook. IAM being global means a user or role exists across all regions, unlike most other resources.

Question 2

What is the difference between an IAM user and an IAM role?

Accepted Answer

A user is a permanent identity with long-lived credentials — a password or access keys — usually representing a person or a legacy application. A role is an identity assumed temporarily by a trusted principal, delivering short-lived credentials through STS. Roles are the recommended mechanism for almost everything. The reason roles are preferred is credential lifetime: assumed-role credentials expire automatically, so a leak has a bounded window, whereas an access key remains valid until someone notices and revokes it. Naming that as the security argument, rather than just "best practice", is what scores.

Question 3

Explain IAM policy evaluation logic.

Accepted Answer

By default everything is denied. An explicit Deny anywhere always wins. Otherwise, access is granted if an applicable Allow exists and no boundary blocks it: for the same account, the union of identity policies and resource policies; and the result is further constrained by any permissions boundary, Service Control Policy, session policy or VPC endpoint policy — the effective permission is the intersection of all applicable ceilings. The two facts interviewers check are that explicit deny always wins and that boundaries and SCPs are ceilings rather than grants. Being able to say "SCPs never grant anything, they only limit" is the single most common gap in candidates' IAM understanding.

Question 4

What are the types of IAM policy?

Accepted Answer

Identity-based policies attach to users, groups or roles. Resource-based policies attach to resources such as S3 buckets, SQS queues, KMS keys and Lambda functions, and include a Principal element. Permissions boundaries and Service Control Policies set maximum permissions. Session policies limit an individual assumed-role session. Access control lists are the legacy cross-account mechanism. The resource-based policy is what makes cross-account access possible without the target account granting anything in its identity policies — and it is also the only place you can allow anonymous access. Knowing which services support resource policies is practical knowledge.

Question 5

How does cross-account access work?

Accepted Answer

Either the resource has a resource-based policy naming the external principal, or — more commonly — the target account creates a role with a trust policy allowing the source account's principals to assume it, and the source principal calls sts:AssumeRole to obtain temporary credentials in the target account. The both-sides requirement is what interviewers check: the trust policy in the target account must allow the assumption *and* the source identity must have permission to call sts:AssumeRole on that role ARN. Missing either half produces the confusing failures people hit.

Question 6

What is the confused deputy problem and what is ExternalId?

Accepted Answer

The confused deputy problem occurs when a third party with permission to assume roles in many customer accounts is tricked into acting against the wrong one. ExternalId is a unique value the customer supplies that must be presented on assumption, so an attacker who knows only the role ARN cannot assume it. This is why every SaaS vendor asks you to generate an external ID when granting them a role. Naming the attack and the mitigation together — rather than describing ExternalId as an extra password — is what shows you understand why it exists.

Question 7

What is AWS STS?

Accepted Answer

The Security Token Service issues temporary, limited-privilege credentials. AssumeRole is the core operation; AssumeRoleWithWebIdentity federates from an OIDC provider such as Google or GitHub Actions; AssumeRoleWithSAML federates from a SAML identity provider; and GetSessionToken adds MFA to long-term credentials. AssumeRoleWithWebIdentity is the mechanism behind both IRSA on EKS and keyless GitHub Actions deployments, which makes it the most operationally important of the four today. Session durations from 15 minutes to 12 hours, chained to one hour, is the detail worth knowing.

Question 8

What is a permissions boundary?

Accepted Answer

A permissions boundary is a managed policy attached to a user or role that sets the maximum permissions that identity can have. Effective permissions are the intersection of the identity policy and the boundary — the boundary never grants anything on its own. The use case is safe delegation: you let developers create roles for their applications, with an SCP requiring that every role they create carries a specific boundary, so their roles can never exceed a ceiling you control. Naming that delegation pattern is what makes the concept concrete.

Question 9

What is a Service Control Policy and how does it differ from IAM?

Accepted Answer

An SCP is an Organizations policy applied to an OU or account that sets the maximum permissions available in that account, including for the root user. It grants nothing — IAM still has to allow the action. SCPs are the organisational guardrail; IAM is the grant. That an SCP constrains even the root user is the fact that distinguishes it from anything IAM can do, and it is why SCPs are the right tool for non-negotiable controls such as denying region use or preventing CloudTrail from being disabled.

Question 10

What are three SCPs you would apply to every organisation?

Accepted Answer

Deny disabling or deleting CloudTrail, Config and GuardDuty, so an attacker cannot blind you. Deny use of regions you do not operate in, reducing attack surface and preventing accidental deployment. Deny actions that would remove the permissions boundary or the organisation's roles. Also common is denying root user actions outside a defined break-glass path. The logging-protection SCP is the highest value because disabling logging is a standard early step in an intrusion. Naming specific SCPs rather than describing the concept is what makes this answer credible.

Question 11

What is IAM Identity Center and why use it over IAM users?

Accepted Answer

IAM Identity Center, formerly AWS SSO, provides workforce identity and single sign-on across multiple AWS accounts, integrating with an external identity provider or its own directory. Users get temporary credentials for permission sets in specific accounts, with no IAM users and no long-lived keys to manage. The operational win is joiner-mover-leaver: access follows group membership in the corporate directory, so offboarding one person removes their access everywhere at once. Managing IAM users per account is unmanageable beyond a handful of accounts.

Question 12

How do you avoid long-lived access keys entirely?

Accepted Answer

For humans, IAM Identity Center with SSO and temporary credentials. For workloads on AWS, instance profiles on EC2, task roles on ECS, IRSA or Pod Identity on EKS, and execution roles on Lambda. For workloads outside AWS such as CI systems, OIDC federation with AssumeRoleWithWebIdentity. The enforcement mechanism is an SCP denying iam:CreateAccessKey outside an approved path, because guidance alone does not stop key creation. Naming the OIDC option for GitHub Actions specifically is the current answer to the most common remaining key use case.

Question 13

How do you authenticate GitHub Actions to AWS without stored credentials?

Accepted Answer

Configure GitHub's OIDC provider as an identity provider in IAM, then create a role whose trust policy allows AssumeRoleWithWebIdentity from that provider, with a condition restricting the sub claim to a specific repository and branch or environment. The workflow exchanges its OIDC token for temporary credentials. The sub-claim condition is security-critical: without restricting repository and ref, other repositories — in some misconfigurations, any repository on GitHub — can assume the role. That exact mistake has caused real production compromises, which is why the condition is the substance of the answer.

Question 14

What is the difference between an AWS managed policy, a customer managed policy and an inline policy?

Accepted Answer

AWS managed policies are maintained by AWS and updated as services change. Customer managed policies are yours, versioned and reusable across identities. Inline policies are embedded in a single identity and deleted with it, which makes them hard to audit and impossible to reuse. The guidance is customer managed policies for most cases, because they are reviewable, versioned and reusable. AWS managed policies are often far broader than needed — PowerUserAccess and many service-full-access policies are effectively over-grants — and inline policies should be reserved for one-off, tightly-scoped exceptions.

Question 15

How do you implement least privilege in practice?

Accepted Answer

Start from IAM Access Analyzer policy generation, which builds a policy from CloudTrail activity over a period. Use Access Analyzer findings for unused access to remove permissions, roles and keys nobody uses. Scope resources by ARN rather than wildcard, add conditions, use permissions boundaries for delegation, and review regularly. The caveat is the observation window: a job that runs quarterly may not appear in 90 days of CloudTrail, so generated policies need review rather than blind application. Naming that risk is what separates a considered answer from a tool recommendation.

Question 16

What is IAM Access Analyzer?

Accepted Answer

Access Analyzer identifies resources shared with external entities — buckets, roles, KMS keys, Lambda functions — by mathematically analysing resource policies rather than by observing traffic. It also finds unused roles, users, permissions and access keys, validates policies against best practice, and generates least-privilege policies from CloudTrail activity. The mathematical analysis point matters: it proves whether external access is possible under any request, rather than reporting what has happened. That is a stronger guarantee than log-based detection and is why it catches exposures nobody has exploited yet.

Question 17

What is a trust policy?

Accepted Answer

A trust policy is the resource-based policy on an IAM role specifying which principals may assume it — an AWS account, a specific role or user, an AWS service such as ec2.amazonaws.com or lambda.amazonaws.com, or a federated identity provider — along with conditions. The distinction to make is that the trust policy controls *who can become* the role, while the permissions policy controls *what the role can do*. Confusing the two is a common source of failed role assumptions, and being precise about it is a good signal.

Question 18

What are IAM policy condition keys and give useful examples?

Accepted Answer

Conditions constrain when a statement applies. Common ones are aws:SourceIp for network restriction, aws:PrincipalOrgID to limit access to your organisation, aws:SecureTransport to require TLS, aws:MultiFactorAuthPresent to require MFA, aws:RequestedRegion to limit regions, and service-specific keys such as s3:prefix. aws:PrincipalOrgID is the underused one: it lets a resource policy allow any principal in your organisation without listing account IDs, and it automatically covers new accounts. Requiring MFA for sensitive actions through a condition is the other high-value pattern.

Question 19

How do you enforce MFA for sensitive operations?

Accepted Answer

Attach a policy that denies the sensitive actions when aws:MultiFactorAuthPresent is false, so the permission exists only in an MFA-authenticated session. For assumed roles, require MFA in the trust policy condition so the role cannot be assumed at all without it. The subtlety is that a role session inherits MFA status from the assumption, so requiring it in the trust policy is stronger than checking it in the permissions policy. Also worth noting that the condition key is absent, not false, for non-MFA sessions, which is why BoolIfExists is often used.

Question 20

What is the difference between authentication and authorisation failures in AWS, and how do you tell them apart?

Accepted Answer

An authentication failure means the credential is invalid, expired or malformed and typically returns an auth error. An authorisation failure means the identity is known but the action is not permitted, returning AccessDenied. The AccessDenied message usually names the principal, action and resource, which is where you start. Reading the AccessDenied message carefully is the practical skill — it distinguishes an implicit deny from an explicit one, and the explicit case points at an SCP, boundary or resource policy rather than a missing grant. That distinction saves a great deal of time.

Question 21

A role has the right policy but still gets AccessDenied. What are the possibilities?

Accepted Answer

An SCP on the account or OU denies the action; a permissions boundary on the role excludes it; a resource-based policy on the target does not allow this principal; a VPC endpoint policy restricts it; a session policy narrowed the session; the resource is encrypted with a KMS key the role cannot use; or the policy scopes a resource ARN that does not match. The KMS case is the one that catches strong candidates out — S3 or EBS permissions are not enough when a customer-managed key is involved; the principal also needs kms:Decrypt on the key. Naming the IAM policy simulator and CloudTrail as the tools to decide between these is the right close.

Question 22

What is the IAM policy simulator and when do you use it?

Accepted Answer

The simulator evaluates whether a given principal would be allowed to perform specific actions on specific resources, taking identity policies, resource policies, boundaries and SCPs into account, without actually making the calls. It is used to validate a policy change before applying it. The limitation to acknowledge is that it does not perfectly model every condition key or every service's resource policy nuance, so it is a strong first check rather than absolute proof. Testing in a non-production account remains the definitive validation.

Question 23

What is role chaining and what are its limits?

Accepted Answer

Role chaining is assuming a role from credentials that were themselves obtained by assuming a role. It works, but the maximum session duration for a chained assumption is one hour regardless of the role's configured maximum, which frequently surprises people running long jobs. That one-hour cap is the specific fact interviewers test, because a long-running pipeline that chains roles fails partway through with expired credentials. Refreshing credentials rather than assuming a long session is the fix.

Question 24

What is an IAM group and what can it not do?

Accepted Answer

A group is a collection of IAM users to which policies are attached, simplifying permission management for people. Groups cannot be nested, cannot be principals in a resource policy or trust policy, and cannot contain roles — only users. Those limitations are why IAM Identity Center permission sets have largely replaced groups for workforce access: they map external directory groups to account-scoped access without creating IAM users at all. Knowing groups cannot be a principal is the specific trap.

Question 25

How do you rotate IAM access keys safely?

Accepted Answer

Create a second access key, deploy it to all consumers, verify the new key is in use through CloudTrail or the key's last-used timestamp, deactivate the old key without deleting it, confirm nothing breaks, then delete it. The two-key limit per user is what makes this rotation pattern possible. The deactivate-before-delete step is what makes rotation reversible: if something breaks, you reactivate rather than scrambling to reissue. The better answer is to eliminate access keys entirely with roles and federation so rotation is unnecessary.

Question 26

What is the AWS root user and what should it be used for?

Accepted Answer

The root user has unrestricted access to the account and cannot be limited by IAM, though it can be limited by an SCP. It should have MFA enabled, no access keys, a strong stored password, and be used only for the specific tasks that require it — closing the account, changing the support plan, certain billing settings and restoring an incorrectly-modified account policy. Naming the specific root-only tasks demonstrates real familiarity. A CloudTrail alarm on any root usage is the detective control that should accompany it, since legitimate root use is rare enough that every occurrence deserves attention.

Question 27

What is IRSA on EKS?

Accepted Answer

IAM Roles for Service Accounts maps a Kubernetes service account to an IAM role using an OIDC provider registered for the cluster, so pods obtain temporary AWS credentials scoped to that role. It replaces giving the node role broad permissions that every pod on the node would inherit. The problem it solves is exactly that node-role inheritance: without IRSA, the least-privileged pod on a node has the same AWS permissions as the most privileged. EKS Pod Identity is the newer, simpler alternative worth naming as the current direction.

Question 28

What is the difference between a service-linked role and a service role?

Accepted Answer

A service role is one you create and grant to a service to act on your behalf, and you control its policies. A service-linked role is predefined and managed by the service itself, with permissions it requires, and it cannot be deleted while the service still needs it. The practical relevance is that service-linked roles appear in your account without you creating them and cannot be arbitrarily modified, which sometimes confuses people auditing roles. Knowing they exist and why prevents someone deleting one and breaking a service.

Question 29

How would you audit who has access to what across an AWS organisation?

Accepted Answer

Use IAM Access Analyzer for external access findings and unused access; query CloudTrail through Athena for actual usage; use the credential report for user-level key and MFA status; and for organisation-wide inventory, aggregate Config data. IAM Identity Center reporting covers workforce access if you use it. The reason a manual approach fails is scale and layering — effective access is the intersection of identity policies, resource policies, boundaries and SCPs across many accounts. Naming Athena over CloudTrail for usage analysis is the answer of someone who has produced an audit report.

Question 30

What is a resource-based policy and which services support them?

Accepted Answer

A resource-based policy attaches to the resource and includes a Principal element saying who may access it. S3 buckets, SQS queues, SNS topics, KMS keys, Lambda functions, Secrets Manager secrets, ECR repositories, EventBridge buses, API Gateway and others support them. Resource policies are the only way to grant anonymous access and the simplest route to cross-account access without role assumption. The evaluation nuance is that within the same account, an allow in either the identity or resource policy suffices, while across accounts both are required.

Question 31

What is the difference between an explicit deny and an implicit deny?

Accepted Answer

An implicit deny is the default — no matching Allow exists — and can be overridden by adding an Allow. An explicit Deny statement always wins and can never be overridden by any Allow, in any policy type. That is what makes explicit denies the right tool for guardrails. Diagnostically it matters: if adding a permission does not fix an AccessDenied, an explicit deny is in play somewhere — an SCP, a boundary or a resource policy. Recognising that pattern quickly is a real time-saver.

Question 32

How do you delegate role creation to developers safely?

Accepted Answer

Grant iam:CreateRole and iam:PutRolePolicy with a condition requiring that the created role carries a specific permissions boundary, and deny iam:DeleteRolePermissionsBoundary. Developers can then create roles for their workloads, but those roles can never exceed the boundary you defined. This is the canonical delegation pattern and it is a favourite senior question, because the naive alternative — either blocking role creation entirely or granting IAM write access — is either a bottleneck or a privilege-escalation path.

Question 33

What IAM permissions constitute a privilege escalation risk?

Accepted Answer

iam:PassRole combined with a service that runs code, such as launching EC2 or creating a Lambda function, lets a user execute with a more privileged role. iam:CreatePolicyVersion, iam:AttachUserPolicy, iam:PutUserPolicy and iam:UpdateAssumeRolePolicy all allow granting oneself more permission. sts:AssumeRole on a privileged role is the direct route. iam:PassRole is the one candidates most often miss and it is the most common real-world escalation path. Any policy granting PassRole should constrain which roles may be passed with a condition, and auditing for unconstrained PassRole is a standard review item.

Question 34

What is iam:PassRole and why does it need constraining?

Accepted Answer

PassRole is the permission to hand an IAM role to a service so the service can assume it — attaching an instance profile, setting a Lambda execution role, giving ECS a task role. Without it, users could not configure services at all; with it unconstrained, they can pass a highly privileged role to code they control. The fix is a condition limiting iam:PassedToService and the role ARNs that may be passed, typically by naming convention or path. Being able to write that constraint, rather than just knowing the risk, is what makes the answer complete.

Question 35

How do you handle IAM for a multi-account organisation?

Accepted Answer

Federate workforce identity through IAM Identity Center mapped to directory groups, with permission sets defining access per account. Workloads use roles with no keys. A central security account holds read-only audit roles assumable across the organisation. SCPs enforce guardrails at the OU level, and all IAM resources are managed as code with a review process. Managing IAM as code is the element that makes the model auditable and reversible, and it is what most organisations retrofit painfully. Naming the cross-account read-only audit role is the practical mechanism for security teams to inspect without standing write access.

Question 36

How long do temporary credentials last and can they be revoked?

Accepted Answer

Assumed-role sessions last from 15 minutes up to the role's maximum session duration, which can be 12 hours, with chained assumptions capped at one hour. They cannot be individually revoked, but you can attach an inline deny policy conditioned on aws:TokenIssueTime being before a cutoff, which invalidates all existing sessions for that role. The revocation technique is a genuinely useful incident-response tool and few candidates know it. Naming the AWSRevokeOlderSessions pattern is a strong differentiator in a security-focused interview.

Question 37

What is the credential report and what do you look for?

Accepted Answer

The credential report is a CSV listing every IAM user with password and access key status, last-used timestamps, MFA status and key age. You look for users with no MFA, access keys older than your rotation policy, keys never used, and users who have not signed in for a long period. Unused keys are the highest-value finding because they are pure risk with no benefit — a credential nobody needs that can still be leaked. Automating the report into a monthly review, rather than running it after an incident, is the operational practice.

Question 38

What is ABAC and how does it differ from RBAC?

Accepted Answer

Role-based access control grants permissions through defined roles. Attribute-based access control grants based on tags — a policy allows access to resources whose tag matches a tag on the principal, so one policy covers many teams. It scales better because adding a team means adding a tag rather than a policy. The condition keys are aws:PrincipalTag and aws:ResourceTag, and the prerequisite is enforced tagging — an SCP requiring tags on creation, otherwise untagged resources fall outside the model. Naming that prerequisite is what makes ABAC workable rather than theoretical.

Question 39

How do you detect and respond to a compromised IAM credential?

Accepted Answer

Detect through GuardDuty findings for anomalous API activity, CloudTrail alarms on unusual actions, and Access Analyzer unused-access changes. Respond by deactivating the key or attaching a deny-all policy to the identity, preserving CloudTrail evidence, reviewing what the credential did and what it could reach, rotating anything it could access, then remediating the leak source. Deactivating rather than deleting preserves the identity for investigation, and the token-issue-time revocation technique is needed for any active role sessions the attacker holds. Sequencing as contain, preserve, investigate, remediate is what interviewers assess.

Question 40

Design the IAM model for a company with 300 engineers across 40 AWS accounts.

Accepted Answer

Organizations with OUs by environment and business unit; SCP guardrails denying region use outside the approved set, denying disabling of logging and security services, and requiring permissions boundaries on developer-created roles. IAM Identity Center federated with the corporate IdP, permission sets mapped to directory groups, no IAM users anywhere. Workloads use roles — instance profiles, task roles, IRSA, Lambda execution roles — with no access keys, enforced by SCP. CI authenticates via OIDC with repository-scoped trust conditions. A central security account with cross-account read-only audit roles, Access Analyzer and GuardDuty organisation-wide, and all IAM defined as code with review. The closing scenario. The senior markers are eliminating IAM users entirely, using permissions boundaries to delegate rather than centralise role creation, and enforcing the key-free model with an SCP rather than a policy document — because guidance alone does not stop key creation.

AWS IAM Interview Questions and Answers

How to use this set