AWS IAM Policy Evaluation Interview Questions: Explicit Deny, Boundaries, and Cross-Account Access

AWS IAM policy-evaluation questions are difficult because several policy types can apply to one request and a memorized 'union then intersection' slogan loses crucial principal and account details. The reliable method is to reconstruct the request context, find every applicable policy, resolve explicit denies, and evaluate each account boundary. A permissions boundary limits identity permissions; it does not grant permission by itself.

The preparation method in this guide is deliberately practical: build a small model, change one condition at a time, predict the result, and compare the prediction with a recorded check. The six policy cases below are original, documentation-backed thought experiments. They were not executed against an AWS account, and they are not AWS interview questions.

Start with Design an IAM system for services and users after the worked scenario.

Use Current AWS Evaluation Rules

Official fact: AWS documents authentication, request-context processing, and enforcement evaluation as distinct steps. Within one account, identity and resource policies generally contribute a union of allows, while an explicit deny overrides an allow.

Official fact: AWS documents the intersection between an identity policy and a permissions boundary for identity-granted permissions. Its boundary page also distinguishes resource-policy grants made directly to a user ARN, role ARN, or role-session ARN, so treating every case as one fixed intersection is inaccurate.

Official fact: For cross-account access, AWS evaluates the trusted account and the trusting account. The principal side and resource side must each allow the request, subject to all applicable explicit denies and organization controls.

Candidate-report boundary: No candidate account is needed to establish the technical behavior in this guide. Any process description should come from the reader’s invitation.

Editorial inference: Interviewers asking IAM scenarios are likely testing whether the candidate can identify the principal, action, resource, condition context, and account boundary before announcing Allow or Deny. That is why the rest of this article emphasizes a reusable reasoning method instead of a supposedly fixed question list.

Before practicing, write down the runtime, product or service version, input contract, and allowed tools. Version details are part of the answer, not administrative trivia. If the invitation is company-specific, ask the recruiter only for format details that affect preparation: language, editor, expected deliverable, time box, and tool rules. Do not ask for the prompt.

Evaluate the Request in a Fixed Order

Request context

Write principal ARN, session type, action, resource ARN, account IDs, region, tags, source network, and time before reading policies. In an interview, make the governing condition explicit before you predict the result. Then name the observation that would disprove your answer. Check: Every condition key used by an applicable statement has a known value.

Explicit deny

Search applicable identity, resource, boundary, session, SCP, and RCP layers for a matching Deny. In an interview, make the governing condition explicit before you predict the result. Then name the observation that would disprove your answer. Check: One matching explicit Deny ends the allow analysis.

Identity grant

Find a matching Allow attached to the user or role and then apply its boundary and session constraints. In an interview, make the governing condition explicit before you predict the result. Then name the observation that would disprove your answer. Check: An Allow outside the boundary is ineffective.

Resource principal

Read exactly which ARN the resource policy names; user, role, and assumed-role session grants have different boundary implications in same-account cases. In an interview, make the governing condition explicit before you predict the result. Then name the observation that would disprove your answer. Check: The named principal matches the active request principal.

Account boundary

For cross-account requests, evaluate the principal account and resource account separately. In an interview, make the governing condition explicit before you predict the result. Then name the observation that would disprove your answer. Check: Both sides reach Allow and neither side supplies a deny.

The five ideas belong in one explanation. Begin with the request or event, identify the controlling state, follow the transition, and finish at the observable output. Avoid reciting definitions separately. A good interviewer can then change one assumption and see whether your model still holds.

Solve Six Paired IAM Cases

Assume Alice in account 1111 calls s3:GetObject on arn:aws:s3:::reports/q3.csv. Start with an identity Allow and a same-account bucket-policy Allow, then alter only one element per case: an explicit Deny, a boundary, the named principal, a condition, or the resource account.

{"Principal":"arn:aws:iam::1111:user/Alice","Action":"s3:GetObject","Resource":"arn:aws:s3:::reports/q3.csv","Context":{"aws:SourceIp":"203.0.113.10"}}

Use this trace rather than jumping straight to a fix:

1. Authenticate — Confirm the caller is Alice rather than a role session with a different ARN.
2. Build context — Record action, resource, source IP, tags, and account ownership.
3. Find denies — Check every applicable statement for a matching explicit Deny.
4. Find grants — Trace identity and resource-policy Allows and their conditions.
5. Apply limits — Evaluate boundary, session policy, SCP, and RCP where applicable.
6. Cross the account boundary — Require authorization on both the principal and resource sides for cross-account access.

The local companion check records these predictions. It passed 6 of 6 assertions. Test boundary: A local truth-table script checked six expected decisions derived from the cited IAM documentation; it did not call IAM, S3, Organizations, or the policy simulator. No credentialed vendor environment was used, so the result verifies the model and arithmetic only. It does not prove hosted behavior, quotas, latency, or account-specific configuration.

Change One Condition at a Time

The fastest way to expose shallow understanding is to change several variables at once. Instead, use paired cases. Keep the request and surrounding state fixed, then alter only the version, identifier, policy, timeout, watermark, or failure point. Say what changed in the governing rule before giving the new output.

Changed condition	Prediction	Evidence to inspect	Best response
Add matching explicit Deny	Deny	Deny statement matches all context	Stop and identify the denying layer
Boundary omits GetObject	Deny for identity grant	Compare action to boundary	Add permission only if governance allows
Bucket condition IP changes	Implicit deny if no other allow	Evaluate SourceIp	Capture actual request context
Policy names role session	Evaluate session principal rules	Compare exact ARN	Do not substitute role ARN
Bucket moves to account 2222	Both accounts must allow	Trace principal and resource sides	Repair the missing side

For every row, separate an observed fact from an assumption. Logs, documented fields, an execution history, and a reproducible test are evidence. A plausible architecture guess is still a guess. If a required field is missing, ask for that field and explain how each possible value would alter the diagnosis.

Common Interview Traps

• Boundary grants access: A boundary sets a maximum; it supplies no Allow. A stronger answer states what would happen, why, and how to verify it.
• Ignoring principal form: A user ARN, role ARN, and role-session ARN are not interchangeable. A stronger answer states what would happen, why, and how to verify it.
• Stopping at one Allow: Another applicable layer may deny or limit the request. A stronger answer states what would happen, why, and how to verify it.
• Treating implicit deny as explicit deny: The remediation and evidence differ. A stronger answer states what would happen, why, and how to verify it.
• Trusting simulator as production proof: AWS documents simulator limitations; real service behavior remains authoritative. A stronger answer states what would happen, why, and how to verify it.

Another trap is proposing a large redesign before proving the failure. Prefer the smallest safe correction that restores the contract, then describe a follow-up improvement if the design still creates operational risk. This shows scope control and leaves room for the interviewer to add a requirement.

Explain the Result as an Engineering Decision

Use a four-part answer: decision, rule, evidence, consequence. For example: “I predict this path will fail. The controlling rule is X. The event history shows Y. Therefore I would change Z and add this regression check.” The exact nouns vary by topic; the structure stays useful.

When there is a trade-off, name both sides concretely. A broad resource policy can simplify access but expands the trust surface; narrow identity grants are easier to govern but require coordinated changes across accounts. Choose a default for the stated workload, and say what measurement or requirement would make you choose differently. “It depends” becomes useful only after you name the dependency.

For troubleshooting questions, end with a safe next action. Preserve evidence before changing state. Prefer a reversible mitigation, define the success signal, and state what would trigger rollback or escalation. For implementation questions, end with a boundary test and an invariant. For design questions, end with capacity and failure assumptions.

Practice Questions and Follow-Ups

Work through these prompts aloud:

1. Explain the normal path without using framework vocabulary. What enters, what state changes, and what leaves?
2. Which single field or timestamp would you inspect first after the reported failure, and why?
3. What happens if the same operation is retried after the external side effect succeeds?
4. Which answer changes across the versions or modes named in the title?
5. What is the smallest regression test that prevents this failure from returning?
6. How would you explain the same incident to an engineer and to a non-specialist stakeholder?

A complete answer should survive one follow-up. After your first response, add a constraint such as a lower resource limit, a late event, a cross-account boundary, a process crash, or a changing requirement. Update only the affected part of your model and keep prior invariants visible.

Verified question	Focus	Practice output
Design an IAM system for services and users	Policy model and least privilege	Write a prediction, evidence path, and decision
Explain AWS access control and frontend typing	Access-control reasoning	Write a prediction, evidence path, and decision
Hierarchical Access Control for an Advertising Platform	Inheritance and denial	Write a prediction, evidence path, and decision
Implement hierarchical folder access check	Authorization algorithm	Write a prediction, evidence path, and decision
Design Hierarchical Permission Checks	Effective-permission evaluation	Write a prediction, evidence path, and decision

A Focused Preparation Routine

On the first pass, spend 25 minutes reconstructing the governing rules from official documentation and write three paired predictions. On the second, spend 35 minutes on the original scenario, including one failure and one recovery. On the third, explain the result aloud in ten minutes, then answer two changing-requirement follow-ups.

Review the recording or notes for four signals: did you state the version; did you distinguish fact from inference; did you prove the failure with the smallest useful trace; and did your recommended change preserve the original contract? Count evidence-backed decisions, not the number of terms you mentioned.

Finish by preparing two questions for the interviewer about the real team’s constraints. Ask about workload shape, failure ownership, testing environments, or observability. Those questions connect the exercise to engineering work without pretending that public documentation reveals a private interview rubric.

In the interview, draw the two-account boundary and say Deny until you can prove every required Allow. That habit prevents the most common IAM reasoning errors.

Sources and Further Reading

• AWS IAM policy evaluation logic — official evaluation order and policy relationships
• AWS permissions boundaries — official principal-specific boundary behavior
• AWS cross-account evaluation — official two-sided authorization model
• IAM policy simulator — official capabilities and limitations