Top 25 AWS IAM & Multi-Account Security Interview Questions: Permission Boundaries, SCPs & Cross-Account Role Scenarios

Securing enterprise AWS environments requires mastering complex policy evaluation logic across multi-account AWS Organizations. In technical interviews for Senior Cloud Security Engineers, IAM Architects, and DevSecOps leads, hiring managers consistently test real-world architectural scenarios: resolving authorization denies, enforcing organization-wide Service Control Policies (SCPs), delegating admin rights safely with Permission Boundaries, and architecting cross-account STS AssumeRole handshakes. In this comprehensive interview preparation guide, we break down the top 25 AWS IAM and multi-account security interview questions with battle-tested architectural rationales, JSON policy examples, and real-world production gotchas.

1. The Core Fundamentals: AWS IAM Policy Evaluation Logic

AWS IAM Policy Evaluation Logic is the deterministic multi-stage algorithm that AWS Security Token Service (STS) and IAM execute to evaluate all applicable identity-based policies, resource-based policies, permission boundaries, SCPs, and session policies to render a final decision: explicit deny, explicit allow, or implicit deny.

2. Top 10 High-Yield Scenario Interview Questions

Q1: What is the fundamental difference between a Service Control Policy (SCP) and an IAM Permission Boundary?

Senior Answer: An SCP is an organizational guardrail applied at the AWS Organizations root, OU, or account level that defines the maximum permissions that any principal (including the member account root user) can exercise. An SCP never grants permissions; it only filters them. A Permission Boundary, by contrast, is an advanced IAM feature applied to individual IAM users or roles that sets the maximum permissions ceiling for that specific principal. Permission boundaries are commonly used to delegate developer self-service role creation without allowing privilege escalation (e.g., developers can create roles, but must attach the boundary).

Q2: A developer creates an S3 bucket with a bucket policy allowing cross-account access from Account B. However, the IAM role in Account B still receives Access Denied. Why?

Senior Answer: For cross-account access, AWS requires an explicit double handshake:

1. The resource-based policy in Account A must grant access to the principal in Account B.
2. The identity-based policy in Account B must explicitly permit the role to perform the action (e.g., s3:GetObject) on the Account A bucket ARN.

If either side of the handshake is missing, the request is implicitly denied. (Note: The exception is AWS KMS keys and IAM roles in the same account, where resource-based policies can authorize access without identity policy matches).

Q3: How does AWS evaluate multiple SCPs attached at different levels of the AWS Organizations tree?

Senior Answer: AWS evaluates the effective permission through an intersection across the tree. Every level from the Organization Root down through all nested OUs to the member account must explicitly include an Allow for that action, and zero levels can have an explicit Deny. If the default FullAWSAccess policy is detached at any intermediate OU without a replacement allow, all child accounts instantly lose access to that service.

Q4: How do you prevent Privilege Escalation when allowing developers to create IAM roles for Lambda functions?

Senior Answer: We attach an IAM Permission Boundary requirement to the developer’s policy using condition keys:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRoleCreationWithBoundary",
      "Effect": "Allow",
      "Action": ["iam:CreateRole", "iam:AttachRolePolicy"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DeveloperBoundary"
        }
      }
    }
  ]
}

If the developer attempts to create a role without attaching DeveloperBoundary, the API call fails.

Q5: How do you design secure Cross-Account Access without creating IAM users in every account?

Senior Answer: We implement centralized identity federation using AWS IAM Identity Center (formerly AWS SSO) or cross-account IAM Roles with STS AssumeRole. Users authenticate once in a centralized Identity Account (or via Okta / Microsoft Entra ID). To access a production workload account, the user assumes an IAM role via sts:AssumeRole. The trust policy in the target account enforces conditions such as sts:ExternalId (for third-party SaaS vendors) or enforces MFA via "aws:MultiFactorAuthPresent": "true".

3. Interview Preparation & Architecture Checklist

• [ ] Master the 6 evaluation stages of AWS policy processing.
• [ ] Understand the exact mechanics of sts:ExternalId to mitigate the Confused Deputy problem.
• [ ] Know how Attribute-Based Access Control (ABAC) uses aws:PrincipalTag and aws:ResourceTag to scale permissions without creating new roles.
• [ ] Practice debugging IAM policies using AWS CloudTrail event logs (errorMessage: Access Denied) and AWS IAM Policy Simulator.