Question 1

Why is iam:CreatePolicyVersion dangerous?

Accepted Answer

It lets a principal rewrite the contents of a policy they are attached to and activate the change instantly, which is equivalent to granting themselves whatever permissions the new version contains — including full admin.

Question 2

Does a permissions boundary stop it?

Accepted Answer

A permissions boundary on the attacker’s identity still caps their effective permissions, so the new admin policy is constrained by the boundary. This is the most reliable mitigation when the action cannot be removed entirely.

Question 3

How is this different from CreatePolicyVersion?

Accepted Answer

CreatePolicyVersion writes a brand-new permissive document; SetDefaultPolicyVersion only reactivates a version that already exists on the policy. The fix for the latter is to prune old versions.

Question 4

Can I limit which policies can be attached?

Accepted Answer

Yes. Use the iam:PolicyARN condition key to allow only an approved list of policy ARNs, which prevents attaching AdministratorAccess.

Question 5

Is an inline policy harder to detect than a managed one?

Accepted Answer

Inline policies do not show up in managed-policy inventories, so they are easier to overlook. Auditing requires enumerating inline policies per principal, which Shieldly and CloudTrail both surface.

Question 6

Does removing admin groups help?

Accepted Answer

Reducing the number of highly privileged groups shrinks the blast radius, but the real fix is scoping the action and enforcing a permissions boundary so membership cannot grant more than intended.

Question 7

How do I let users rotate only their own keys?

Accepted Answer

Grant iam:CreateAccessKey and iam:DeleteAccessKey with a condition restricting the resource to the caller’s own user ARN, so they cannot mint keys for others.

Question 8

Does MFA stop this attack?

Accepted Answer

Enforcing MFA on console login raises the bar significantly, since a reset password alone will not complete sign-in. It is not a substitute for scoping the action, but it is a strong second layer.

Question 9

Why is iam:PassRole so commonly abused?

Accepted Answer

It is frequently granted on Resource "*" for convenience, which lets a principal pass any role — including admin roles — to a compute service they control. Scoping it to specific roles closes the path.

Question 10

What does iam:PassedToService do?

Accepted Answer

It restricts which AWS service a role can be passed to. Limiting PassRole to lambda.amazonaws.com (or ec2.amazonaws.com, etc.) prevents the role being handed to an unexpected service.

Question 11

Does IMDSv2 fully prevent this?

Accepted Answer

IMDSv2 mitigates remote credential theft (notably via SSRF) by requiring a session token, but a principal who controls the instance can still reach IMDS locally. The primary fix is scoping PassRole and the instance role.

Question 12

How is this different from PassRole-based escalation?

Accepted Answer

PassRole hands an existing role to a service; UpdateAssumeRolePolicy changes who is allowed to assume a role directly. Both end with the attacker holding a more privileged role, but the trust-policy rewrite is detectable as a distinct CloudTrail event.

Question 13

Why does this not need iam:PassRole?

Accepted Answer

The function already has an execution role assigned. UpdateFunctionCode only changes the code that runs under that existing role, so no role is being passed — which is why it is easy to overlook.

Question 14

Is this the same idea as PassRole + EC2 or Lambda?

Accepted Answer

Yes — it is the same pattern (pass a privileged role to a compute service you control), just via Glue. The fix is identical: scope PassRole and add a PassedToService condition.

Question 15

Does this work without a service role?

Accepted Answer

Without a passed --role-arn, CloudFormation uses the caller’s own permissions, so there is no escalation. The risk comes specifically from passing a more privileged service role.

Question 16

Is this different from PassRole + EC2?

Accepted Answer

It is the same pattern — pass a privileged role to a compute service you control, then read its credentials. SageMaker notebooks just give you the interactive shell directly. The fix is identical: scope PassRole and add a PassedToService condition.

Question 17

Why is CodeBuild a good escalation target?

Accepted Answer

It runs attacker-controlled commands as a service role and is often given broad permissions for deployment. Passing a privileged role to it turns a build into arbitrary code execution as that role.

Question 18

Is Data Pipeline still common?

Accepted Answer

It is a legacy service, so many accounts never use it — but if the permissions are present in a broad policy, the escalation path is real. Removing unused datapipeline actions closes it entirely.

Question 19

Does MFA stop this escalation?

Accepted Answer

It blocks the final step. The attacker can still reset the password, but cannot complete console sign-in without the second factor — which is why MFA on every human user is the key control.

Question 20

Is iam:AttachRolePolicy alone enough to escalate?

Accepted Answer

Only if the attacker can also use the role — by assuming it or triggering a service that runs as it. Pair the permission audit with a review of which roles are assumable; Shieldly flags both.

Question 21

Why is attaching to a group as dangerous as attaching to a user?

Accepted Answer

Group membership propagates permissions to every member. If the attacker belongs to the group, attaching admin to the group escalates their own user immediately.

Question 22

How is this different from iam:AttachRolePolicy?

Accepted Answer

AttachRolePolicy reuses an existing managed policy; PutRolePolicy lets the attacker author an arbitrary inline document, so it does not depend on an admin policy already existing in the account.

Question 23

Are inline group policies commonly overlooked?

Accepted Answer

Yes. Inventories of managed policies miss them entirely, so an inline grant on a group can persist unnoticed. Auditing requires enumerating inline policies per group.

Question 24

Why does the container get the role credentials automatically?

Accepted Answer

ECS exposes task-role credentials at a metadata endpoint inside the container. Any process in the task can read them, so the task role is effectively the attacker once the task runs.

Question 25

How is this different from PassRole + RunInstances?

Accepted Answer

RunInstances launches a new instance with a chosen role; this method swaps a privileged profile onto an existing instance the attacker already controls, which can be quieter.

Question 26

Does this need iam:PassRole?

Accepted Answer

No. The instance already holds its role via the instance profile. SendCommand simply runs code on the box, which can then read and exfiltrate those existing credentials.

Question 27

Why use an event source mapping instead of just invoking?

Accepted Answer

It avoids needing lambda:InvokeFunction. Any write to the mapped stream triggers the function, so the attacker escalates with only create permissions and stream-write access.

Question 28

Why is this different from PassRole + RunInstances?

Accepted Answer

RunInstances requires iam:PassRole and launches a brand-new instance. This method needs no IAM permission at all — it targets an existing instance that is already attached to a privileged profile, only rewriting its user data.

Question 29

Why can't the attacker just modify user data on a running instance?

Accepted Answer

AWS only accepts ModifyInstanceAttribute for userData while the instance is stopped, and by default cloud-init only executes user data once, on first boot — the stop/start cycle plus the #cloud-boothook directive are both necessary to force re-execution.

Question 30

What is IAM Trust Policy?

Accepted Answer

A trust policy is the resource-based policy attached to an IAM role that defines which principals are allowed to assume it.

Question 31

What is IAM Permissions Boundary?

Accepted Answer

A permissions boundary is an advanced policy that sets the maximum permissions an IAM user or role can ever have, regardless of its attached policies.

Question 32

What is Service Control Policy (SCP)?

Accepted Answer

A Service Control Policy is an AWS Organizations policy that sets the maximum available permissions for the accounts it is applied to.

Question 33

What is Resource-Based Policy?

Accepted Answer

A resource-based policy is a policy attached directly to a resource (such as an S3 bucket or KMS key) that specifies who can access it and how.

Question 34

What is Resource Control Policy (RCP)?

Accepted Answer

A Resource Control Policy is an AWS Organizations policy that sets the maximum available permissions for resource-based policies across accounts in the organization — the resource-side counterpart to a Service Control Policy.

Question 35

What is IAM Condition Keys?

Accepted Answer

Condition keys let you add requirements to a policy statement so it only applies when specific context values match — source IP, MFA, account, encryption, and more.

Question 36

What is sts:AssumeRole?

Accepted Answer

sts:AssumeRole is the STS action that returns temporary security credentials for an IAM role, letting a principal operate with that role’s permissions.

Question 37

What is Least Privilege?

Accepted Answer

Least privilege is the principle of granting an identity only the permissions it needs to do its job — nothing more.

Question 38

What is IAM Policy Evaluation Logic?

Accepted Answer

IAM policy evaluation is the order in which AWS decides whether a request is allowed: an explicit deny always wins, then an explicit allow, otherwise the default is deny.

Question 39

What is IAM Managed Policy?

Accepted Answer

A managed policy is a standalone IAM policy that can be attached to multiple users, groups, or roles, and exists independently of any single identity.

Question 40

What is IAM Inline Policy?

Accepted Answer

An inline policy is a policy embedded directly in a single user, group, or role, with a strict one-to-one relationship to that identity.

Question 41

What is IAM Session Policy?

Accepted Answer

A session policy is an inline permissions policy passed at the moment a role is assumed, further limiting the permissions of that temporary session.

Question 42

What is EC2 Instance Profile?

Accepted Answer

An instance profile is a container for an IAM role that lets an EC2 instance receive temporary credentials for that role automatically.

Question 43

What is IAM Service-Linked Role?

Accepted Answer

A service-linked role is a special IAM role that is predefined and owned by an AWS service so the service can perform actions on your behalf.

Question 44

What is IAM ExternalId?

Accepted Answer

ExternalId is a shared secret placed in a cross-account role trust policy condition to prevent the confused-deputy problem when a third party assumes your role.

Question 45

What is IAM Principal?

Accepted Answer

A principal is an entity that can make a request to AWS — an IAM user, an IAM role session, a federated user, or an AWS service acting on your behalf.

Question 46

What is Attribute-Based Access Control (ABAC)?

Accepted Answer

ABAC is an authorization model where access is granted based on tags (attributes) on principals and resources rather than on static lists of resource ARNs.

Question 47

What is IAM Access Advisor (Last Accessed)?

Accepted Answer

Access Advisor reports the services a principal is allowed to use and when each was last accessed, making it the primary signal for removing unused permissions.

Question 48

What is NotAction Element?

Accepted Answer

NotAction matches every action except the ones listed, so it is an inverted action set that is easy to misread as a denial.

Question 49

What is Wildcard Action?

Accepted Answer

A wildcard action uses an asterisk to match many or all actions, with Action set to "*" granting every action in AWS.

Question 50

What is IAM Access Key?

Accepted Answer

An access key is a long-lived credential pair (access key ID and secret access key) used to authenticate programmatic requests to AWS as an IAM user.

Question 51

What is IAM Multi-Factor Authentication (MFA)?

Accepted Answer

MFA adds a second authentication factor on top of a password or access pattern, so a stolen credential alone is not enough to act.

Question 52

What is AWS Account Root User?

Accepted Answer

The root user is the identity created with the AWS account that has unrestricted access to every resource and cannot be limited by IAM policies.

Question 53

What is IAM Credential Report?

Accepted Answer

The credential report is an account-level CSV listing every IAM user and the status of their passwords, access keys, and MFA devices.

Question 54

What is IAM Policy Simulator?

Accepted Answer

The IAM policy simulator evaluates whether a given principal would be allowed or denied a specific action, without making a real request.

Question 55

What is iam:PassRole?

Accepted Answer

iam:PassRole is the IAM permission that lets a principal hand an existing IAM role to an AWS service, so the service can act as that role.

Question 56

What is Confused Deputy Problem?

Accepted Answer

The confused deputy problem is when a more-privileged service can be tricked into using its own permissions to act on a resource the caller should not have access to.

Question 57

What is IMDSv2 (Instance Metadata Service v2)?

Accepted Answer

IMDSv2 is the session-oriented, token-required version of the EC2 instance metadata service, designed to make remote theft of an instance role's credentials much harder.

AWS IAM Security Interview Questions and Answers

Privilege escalation questions

Core concept questions

Scan your IAM policies free