AWS IAM Roles interview questions

An IAM role defines a set of permissions that trusted principals — IAM users, AWS services, or other AWS accounts — can temporarily assume via AWS STS instead of using long-term credentials. This is the key distinction from IAM users, who rely on permanent access keys or passwords. Roles enable secure, temporary, delegatable access across services and accounts.

The statement is false. An IAM role does not provide long-term access keys. When an entity assumes a role, AWS STS issues temporary credentials that expire automatically, so no permanent keys are shared. Long-term access keys belong to IAM users instead.

True. An IAM role has no long-term access keys. When an eligible principal assumes the role, AWS STS issues temporary security credentials that expire after a set duration, so no permanent secrets need to be managed for the role.

An IAM role. A role is assumed by a principal, and AWS STS issues temporary credentials for it that expire automatically.

Temporary security credentials is what an IAM role is primarily designed to provide. Trusted principals such as IAM users, AWS services, or federated identities call AssumeRole to get short-lived credentials, so no long-lived access keys need to be stored or shared.

Attach an IAM role with an S3 read permission policy to the EC2 instance via an instance profile. AWS automatically provides the instance with short-lived temporary credentials through the instance metadata service, eliminating the need for long-lived access keys on the instance. This follows least-privilege best practice and avoids the security risk of embedded credentials.

ec2.amazonaws.com. In the trust policy's Principal element, you specify the EC2 service principal, which lets the EC2 service assume the role on behalf of instances launched with an instance profile that contains it.

The role in Account B has a trust policy, which is its resource-based policy, and it lists Account A or the specific user as a trusted Principal. The user in Account A must have an identity-based policy that grants sts:AssumeRole on the target role's ARN. Both permissions are required: the trust policy authorizes the cross-account principal, and the identity-based policy authorizes the user to call AssumeRole on that specific role ARN.

The trust policy controls which principals, such as IAM users, roles, or AWS services, can call AssumeRole on the role. The permissions policy controls which actions the role's temporary session can perform once assumed. Both must allow the access for it to succeed.

The statement is false: an IAM role attached to an EC2 instance through an instance profile does not store its credentials on the EBS root volume. The instance fetches short-lived credentials from the Instance Metadata Service while it runs. Those credentials expire, so they are not usable once the instance is stopped or terminated.

The Instance Metadata Service (IMDS), reachable at the link-local address 169.254.169.254, supplies temporary credentials for an EC2 instance profile role. The AWS SDK's default credential provider chain fetches them automatically, so no long-lived access keys need to be stored on the instance.

The trust policy determines which principals, such as accounts, users, or services, may assume an IAM role. The permission policies determine which actions and resources the temporary session credentials can access. Mixing up the two can over-grant or under-grant access.

Add a Condition with sts:ExternalId set to a unique secret value that Account A provides to the vendor. The sts:ExternalId condition is the AWS-standard mechanism for preventing the confused deputy problem in cross-account role assumption: each customer assigns a distinct External ID, so the trusted third party cannot assume one customer's role on behalf of another. Source IP, SourceAccount, and MFA do not distinguish between the third party's different customers.

Yes, the EC2 instance can read objects from shared-bucket. AppRole is allowed to assume SharedRole, SharedRole's trust policy trusts AppRole, and the resulting session carries SharedRole's s3:GetObject permission. Because the bucket and SharedRole are in the same account, no bucket policy is needed.

When you create an IAM role in AWS, you attach a JSON policy document that specifies which principals (accounts, services, or users) are allowed to assume the role. This document is commonly called the trust policy. For a principal to successfully assume the role, the policy must explicitly grant the sts:AssumeRole action. The set of AWS resource permissions the assumed role will hold is defined separately by one or more permissions policies attached to the role.

Give the ECS tasks a dedicated task role in Account A (not the execution role) and attach no access keys. In Account B, create role XAccountS3Reader whose trust policy names the specific Account A task role ARN as its principal, with a permissions policy allowing s3:GetObject only on the bucket's object ARN. In Account C, create role XAccountAuditWriter with a trust policy naming the same task role ARN and a permissions policy allowing dynamodb:PutItem only on the audit table ARN. The Account A task role's permissions policy allows sts:AssumeRole only on those two role ARNs. The application calls AssumeRole (or uses an SDK credential provider that does so) to obtain short-lived temporary credentials for each downstream role. To revoke access, an administrator removes the Account A principal from the downstream trust policy, so every new AssumeRole call fails immediately, with no application redeploy. Credentials already issued stay valid until they expire, so bound that window by requesting a short session duration (DurationSeconds, minimum 900 seconds) so the application re-assumes frequently. For an immediate cutoff of live sessions, attach an inline deny policy to the downstream role conditioned on aws:TokenIssueTime earlier than the revocation time.

No. For a cross-account sts:AssumeRole call to succeed, two conditions must both be met: (1) the target role's trust policy must allow the calling account's principal, which is satisfied because the trust policy permits arn:aws:iam::222222222222:root. (2) The calling IAM entity must have an identity-based policy granting sts:AssumeRole on the target role ARN. Alice has no identity-based policies at all, so there is no Allow statement for sts:AssumeRole. In AWS IAM the default decision for any action is an implicit Deny, so without an explicit Allow the call is denied. The trust policy is necessary but not sufficient: it establishes whom the role trusts, but the caller still needs its own permission to make the API call. Therefore alice cannot assume CrossAccountRole.

The session's effective permissions are the intersection of the role's identity-based policies and the inline session policy. The session policy can only narrow (restrict) the permissions granted by the role; it cannot expand them. If a permission is allowed by the role but denied or not allowed by the session policy, it is not granted to the session.

The resulting session has no effective S3 permissions. AWS computes effective session permissions as the intersection of the role's identity-based policy, its permissions boundary, and any session policy passed during AssumeRole. Here the boundary allows only s3:GetObject/s3:PutObject on bucketA/* while the session policy allows only s3:GetObject on bucketB/*; the two resource sets do not overlap, so the intersection is empty. Session policies and permissions boundaries are both purely restrictive — neither can expand what the other grants.

Its primary purpose is to prevent the confused deputy problem. Because the vendor's IAM user holds a blanket sts:AssumeRole grant on Account A's role, nothing in the identity policy stops it from assuming the role while acting for the wrong customer. Without ExternalId, a request made on behalf of Customer X could reach Account A's resources under another customer's context, whether by mistake or by a malicious request. The condition requires each AssumeRole call to present the ExternalId that Account A issued to that specific customer. Account A's trust policy checks that value, so the assumption succeeds only when the vendor is acting for the customer who holds that token. The ExternalId does not enforce MFA, does not reduce the permissions granted by the role's permission policy, and does not stop the vendor's IAM identity from being granted sts:AssumeRole in the first place.

The two condition keys commonly used in a trust policy for the confused deputy problem are sts:ExternalId (for third-party / cross-account role assumption) and aws:SourceAccount combined with aws:SourceArn (for restricting which AWS account or resource ARN can trigger a service to assume the role). sts:ExternalId requires the caller to pass a pre-agreed value the trust policy must match. aws:SourceAccount and aws:SourceArn bind the role assumption to a specific source account or resource, preventing another AWS account from invoking the service in a way that causes it to assume the role for an unintended principal.

The analyst must pass ExternalId=partner-xyz as a parameter in the sts:AssumeRole call. The trust policy's StringEquals condition on sts:ExternalId requires this exact value to match, so without it AWS denies the request even though the analyst has sts:AssumeRole permission via their inline policy in Account B. Both sides are required: the Account B identity policy authorizes the call on the role ARN, and the Account A trust policy condition must also evaluate to true. The resulting session carries only the permission policy of AuditRole, which here grants s3:GetObject on arn:aws:s3:::logs-bucket/*, so the single S3 permission is reading objects in that bucket. The session cannot list the bucket or delete objects because those actions are not granted.

IAM Role Security Architecture for a 60-Account Organization

1. Cross-Account Trust Policy Hardening

Every cross-account role's trust policy is authored as a CloudFormation StackSet deployed from the security-audit account so that member-account administrators cannot silently widen trust. Each trust policy follows this pattern:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::HUB-ACCOUNT:role/AuditHubRole" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "<unique-per-spoke-id>",
        "aws:SourceAccount": "HUB-ACCOUNT"
      },
      "ArnLike": {
        "aws:SourceArn": "arn:aws:iam::HUB-ACCOUNT:role/AuditHubRole"
      }
    }
  }]
}

The Principal is pinned to the exact hub role ARN — never root or *. The sts:ExternalId condition prevents the confused-deputy attack: even if an attacker in the hub account can influence which role is assumed, they cannot construct a valid AssumeRole call without the spoke-specific external ID, which is stored only in Secrets Manager in the audit account. aws:SourceArn adds defense-in-depth by verifying the caller's actual ARN. An SCP at the Organization root denies iam:UpdateAssumeRolePolicy on cross-account roles for all principals except a break-glass role in the audit account, ensuring trust policies are centrally governed.

2. Permission Boundaries as Blast-Radius Ceilings

Every self-service developer role carries BOTH an identity-based policy (granting fine-grained, resource-scoped permissions) AND a permission boundary (a managed policy capping the maximum allowed actions). The evaluation logic is:

Effective permission = (identity-based policy ALLOW) ∩ (permission boundary ALLOW), minus any explicit DENY anywhere in the evaluation chain (SCP → identity policy → permission boundary → session policy → resource-based policy).

Concrete pattern: the boundary policy denies a set of dangerous services (e.g., iam:*, organizations:*, kms:CreateKey) and caps all S3 actions to buckets tagged Environment=dev. A developer may attach AdministratorAccess as an identity-based policy, but the effective permissions remain bounded by the boundary — they cannot perform any action the boundary does not also allow, and any explicit Deny in the boundary overrides the broad identity-based Allow. This means the blast radius is architecturally capped regardless of what identity-based policies accumulate on the role.

3. Role Chaining and Session Duration

The audit tool works as follows: a Lambda in the audit account assumes AuditHubRole in the hub account (Session 1), then from the hub assumes SpokeAuditRole in each spoke account (Session 2 — this is a chained session).

Key constraint: a chained STS session's DurationSeconds cannot exceed the remaining lifetime of the parent session, and AWS enforces a hard maximum of 1 hour for chained AssumeRole calls regardless of the role's MaxSessionDuration setting. Even though SpokeAuditRole may have MaxSessionDuration set to 4 hours, the audit tool will only receive a token valid for at most 1 hour (or less, if the parent session has less than 1 hour remaining).

The audit tool mitigates this by:

• Requesting the maximum feasible duration at each hop and caching tokens per spoke account with their expiry timestamps.
• Re-chaining through the hub (obtaining a fresh parent session) before the cached spoke token expires, amortizing the re-assumption cost across the fan-out.
• Using a token-vending Lambda in the audit account that refreshes all spoke tokens in parallel via Step Functions when any token crosses the 15-minute-remaining threshold.

4. Session Policies for Dynamic Scoping

Session policies are passed inline during the AssumeRole (or AssumeRoleWithWebIdentity, GetFederationToken) call as the Policy parameter. They act as an additional AND-filter: the final effective permissions are the intersection of (identity-based policy ∩ permission boundary ∩ session policy), still subject to any explicit Deny.

A session policy can ONLY narrow permissions — it can never grant an action that the role's attached policies and boundary do not already allow.

Concrete use case attached policies cannot serve: a single DataProcessingRole is assumed by hundreds of ECS tasks, each processing a different tenant's data. At assume time, the task passes a session policy that restricts S3 access to arn:aws:s3:::data-bucket/tenant-<tenant-id>/*, where <tenant-id> is injected by the task orchestrator. Without session policies, you would need a separate role per tenant (hitting role limits and creating operational overhead) or a single broad role that every task shares (violating least privilege). The session policy provides per-invocation, dynamic scoping with zero role proliferation.

Use a layered model for cross-account delegation. (1) Confused deputy: each customer's role trust policy requires an sts:ExternalId condition matching a unique, high-entropy, per-customer value that the platform stores in AWS Secrets Manager and passes on every AssumeRole call. Without the correct ExternalId, STS rejects the call even though the platform's account is trusted, so one tenant cannot make the platform assume another tenant's role. (2) Least-privilege guardrail: each customer role has a permissions boundary that caps the maximum actions and resources (for example, s3:GetObject on specific prefixes, kms:Decrypt on specific key ARNs). Effective permissions are the intersection of the identity-based policies and the permissions boundary; an explicit deny in either, or an implicit deny (no allow in both), blocks the action. An accidental over-permission in the identity policy therefore cannot exceed the boundary, and customers can further restrict the identity policy without loosening the boundary. (3) Session scoping: each AssumeRole call passes an inline session policy or managed session policy ARN that narrows the session to the resources needed for that operation. Session policies can only reduce permissions, so read-only inventory sessions and remediation sessions can use the same role with different scopes. Effective permissions for a session are identity policy AND permissions boundary AND session policy, with any deny winning. (4) Duration and chaining: set MaxSessionDuration to the shortest operationally viable value (1 hour is typical) and keep credentials short-lived. When a role is assumed using credentials from another assumed role (role chaining), the session is capped at 1 hour and cannot be extended, so a chain cannot create long-lived credentials. The control plane's own credentials are rotated automatically, and sts:SourceIdentity can be set on the assumption so the originating caller identity is carried through the session and recorded in CloudTrail. (5) Detective controls: log all STS and CloudTrail events, including userIdentity.sessionContext, sourceIdentity, source account and IP, and whether a session policy was used. Stream CloudTrail to S3 and CloudWatch Logs, and alert on repeated failed AssumeRole calls (ExternalId guessing), assumptions from unexpected accounts or IPs, and unusual session volume. At scale, deploy the role, trust policy, and boundary to every account with a CloudFormation StackSet across the organization, and run an orchestrator that retrieves each account's ExternalId and performs the AssumeRole calls. Trade-offs: boundaries and session policies add policy complexity and must be tested, short sessions require the orchestrator to re-assume roles often, and per-customer ExternalIds add secret-management overhead in exchange for strong tenant isolation.

No, the call is denied. Cross-account role assumption needs two independent grants: the role's trust policy in Account A must name the caller's principal (here, Account B), and the caller's own identity-based policy in Account B must allow sts:AssumeRole on the role's ARN. The trust policy names Account B, but the instance profile role has no identity-based sts:AssumeRole allow, so the request is denied because the caller's side is missing. Adding that allow in Account B's policies would make the call succeed. If it succeeded, the session would carry only the role's attached permission policy, which is s3:GetObject on arn:aws:s3:::shared-bucket/*; it would not inherit the instance profile role's Account B permissions, and the session's permissions are not a union of the caller's and the role's policies.