Articles
AWS STS Interview Questions: AssumeRole, Trust Policies, and Session Permissions
Practice AWS STS interview questions with cross-account AssumeRole, trust conditions, session permissions, credential refresh, and revocation decisions.
A service successfully calls AssumeRole, receives temporary credentials, and then gets AccessDenied while reading a customer object. The interviewer asks whether the trust policy is wrong. What evidence would make you agree?
The central answer to AWS STS interview questions is that permission to create a role session and permission to use that session are separate decisions. The trust policy controls who may assume the role under specified conditions. The resulting principal must still be authorized for the requested service action, resource, and context.
This article is for backend, platform, and security-minded engineers. AWS documentation establishes service rules; the two-stage authorization ledger and permission exercises below are original practice, not an AWS deployment or employer interview report. Begin with Design an IAM system for services and users, then add a cross-account role-session boundary.
What does AssumeRole establish, and what does it not establish?
Official: The AssumeRole API reference describes temporary access-key credentials with a session token and expiration. In a standard cross-account arrangement, the target role must trust the caller's account or principal, and the caller needs permission to assume that target role.
A successful response therefore establishes a limited claim: that this issuance request succeeded at that time with that input. It does not prove that an object exists, that a later request uses the returned credentials, or that every service operation is allowed.
For an original example, account A runs a reporting worker. Account B owns a CustomerReportReader role and a report bucket. The worker obtains a session for that role, then attempts an object read. Draw the issuance arrow from A to STS separately from the read arrow made as B's assumed-role session.
Ask the interviewer for the exact principal on the failing read. If the application's credential provider still uses A's original workload credentials, evaluating B's role permissions explains the wrong request. Check identity and expiration without logging the secret access key or session token.
Also distinguish an account principal in a trust policy from a named workload role. Trusting an account can delegate selection of eligible identities within that account; it is not equivalent to naming one tightly scoped workload. Conditions and caller-side permissions complete the intended boundary.
Avoid claiming that a caller's original service permissions automatically transfer into the new role. The application is operating as a different principal. Explain which identity is used for each API call instead of narrating the entire workflow as “the worker's permissions.”
Build a two-stage cross-account authorization ledger
Use this original ledger before editing policies. It is a diagnostic structure, not a complete IAM simulator.
| Stage | Concrete question | Evidence to record |
|---|---|---|
| Session issuance | May this caller assume this role with these conditions? | Caller identity, target role ARN, trust statement, request conditions |
| Credential selection | Did the application use the issued session? | Session principal, credential source, expiration, request time |
| Service action | May this session perform this action on this resource? | Action, resource ARN, applicable policies and explicit denies |
| Dependent action | Does the request require another service permission? | For example, a separately evaluated encryption-key operation |
Imagine the role allows s3:GetObject on reports/customer-a/*. The worker requests reports/customer-b/summary.csv. Issuance can succeed while the object request remains outside the role's grant. Changing trust would not fix that mismatch and could broaden access unnecessarily.
Now change only the requested object to customer A. If access still fails, inspect session restrictions and applicable guardrails. Do not conclude that the role's visible allow statement wins without identifying every relevant policy boundary.
Finally, keep the action name precise. Listing a bucket and reading an object are not the same request or resource shape. A successful list operation does not establish object-read permission, and a read failure does not necessarily imply a networking problem.
Your proposed repair should name the smallest intended permission delta and its owner. If the worker should never access customer B, the correct response may be correcting the application request rather than granting a broader resource pattern.
How do session policies restrict a role session?
Official: AWS's policy-evaluation documentation distinguishes identity grants, resource grants, boundaries, and organization controls. A passed session policy limits the role's identity-based permissions; it cannot expand that role grant. An applicable explicit deny overrides an allow.
Here is an original bounded set exercise. Assume authorization comes only from the role's identity policy; ignore direct resource-policy grants, policy conditions, and other service requirements for the first pass.
The role allows {read A, read B, write A}. The passed session policy allows {read A, read B}. A permissions boundary allows {read A, write A}. Organization policy permits the considered actions except for an explicit deny on write A.
Under those stated assumptions, the usable identity-granted set is {read A}. read B is outside the boundary. write A is outside the session allow and is explicitly denied. Adding delete A to the session policy cannot create permission absent from the role's grant.
Now remove the session policy entirely. That is not the same as passing a policy that allows no relevant action. The exercise must represent absence as “no additional session restriction,” not as an empty allow set that denies everything.
The point is not memorizing intersections. It is making the assumptions inspectable. Write the principal, action, resource, and grant path above the arithmetic so the interviewer can identify where the model stops applying.
Official: AWS's permissions-boundary guide describes important differences between grants to role ARNs and grants directly to assumed-role session principals within an account. Direct session-principal grants are not limited by certain implicit denies in identity, boundary, or session policies; applicable explicit denies still matter.
Consequently, do not present role ∩ session ∩ boundary ∩ SCP as a universal AWS authorization formula. It is useful for the bounded identity-grant exercise above. A real analysis must identify the resource-policy principal and the account relationship before choosing the evaluation rule.
Is an external ID a secret or a confused-deputy control?
Official: AWS's third-party access guidance explains that an external ID helps address the confused-deputy problem. AWS does not treat it as a secret. A provider serving several customers should use a distinct customer association and supply the expected value when assuming the customer's role.
The original interview scenario is a monitoring provider with legitimate access to many accounts. A malicious customer supplies another customer's role ARN and tries to make the provider act for the wrong tenant. Merely trusting the provider's AWS principal does not express which customer relationship the request belongs to.
A trust condition on sts:ExternalId can bind role assumption to the intended association. It does not replace authentication of the provider, validation of the requested customer, or least-privilege role permissions. Knowing the external ID alone is not equivalent to holding an authorized AWS principal.
For a configuration exercise, test the intended role-assumption request with the correct value, a wrong value, and no value. State the expected outcomes before running anything. A permissive alternative trust statement can make the “no value” case succeed despite the condition you were inspecting.
Explain that this is a controlled administrative test plan, not a request to probe an account you do not own. For interview preparation, the local exercise can evaluate the stated conditions without creating a role or exposing credentials.
How do duration and refresh change a long-running job?
Official: The AssumeRole reference allows duration within the role's configured limit, while role chaining through the API is limited to one hour. Requesting a longer chained session fails; the target role's larger maximum does not remove that chaining limit.
Consider an original job expected to run for 90 minutes. If it uses a one-hour session captured at startup, “the batch usually finishes” is not a credential-lifecycle design. Explain how the credential provider refreshes before expiration and how the application handles a failed refresh.
Separate obtaining fresh credentials from retrying an operation. A timed-out write may already have succeeded. Reissuing it with new credentials does not make the write idempotent. Use an operation identifier or another application-level duplicate-control contract when the service workflow requires it.
A useful failure drill changes one event at a time: the token expires, the trust condition changes, STS is unreachable, or the role no longer permits the service action. The observations and recovery differ. Unlimited retries can keep a denied or expired workflow alive without making progress.
For a background reporting worker, checkpoint the application work independently from credential state. A replacement process should obtain its own valid session and resume from a durable progress record, not retrieve a secret token from a previous process's logs.
Does changing trust revoke an already-issued session?
Do not equate preventing new issuance with invalidating every existing credential. A trust change governs role assumption; containment must also address permissions available to sessions that already exist.
Official: AWS's temporary-credential disabling guidance describes denying permissions to issued credentials. Its role-session revocation procedure uses a token-issue-time cutoff. This is not a promise that deleting a copied credential string remotely erases all copies or that a change has instantaneous global effect.
The original incident exercise is a leaked reporting-role session. Record the issue time, expiration, role, affected resources, and relevant actions without reproducing the token. Define immediate containment, future-issuance restrictions, and verification of the intended deny separately.
Ask what legitimate jobs will be interrupted by a cutoff. A broad revocation may be justified, but it has an operational cost. Explain how fresh, authorized sessions resume safely and how you distinguish containment success from a workload simply ceasing to send requests.
Official: AWS's assumed-role monitoring guidance describes source identity and its persistence through role chaining. Source identity and session naming support attribution, but their values need trusted assignment and enforceable conditions; an arbitrary caller-supplied label is not proof of a human identity.
In your answer, connect the issuance event to downstream request evidence. Keep policy-change time, credential issue time, and failed-request time distinct. That timeline is more useful than a screenshot of a policy that may have changed after the incident.
Sources and Further Reading
Official references checked October 1, 2026. Set arithmetic is a bounded local reasoning model, not an AWS authorization emulator or deployment test.