9.1 Complete AWS Policy Evaluation Logic & Decision Flow

9.1 Complete AWS Policy Evaluation Logic & Decision Flow

Every incoming API request in AWS undergoes rigorous evaluation by the AWS authorization engine. Whether an engineer invokes s3:GetObject via the AWS Management Console, an AWS Lambda function invokes dynamodb:PutItem via an SDK, or an external automated pipeline pushes container layers to Amazon Elastic Container Registry (Amazon ECR), the request is evaluated against multiple policy types concurrently.

Securing enterprise architectures requires a comprehensive understanding of the seven-stage policy evaluation flow, the operational distinction between intra-account and cross-account requests, and the specific architectural anomalies exhibited by cryptographic services such as AWS Key Management Service (AWS KMS).

---

The Complete AWS Policy Evaluation Hierarchy

When AWS receives an API request, the authorization engine evaluates the request context (the calling principal, the requested action, the target resource, and context variables like source IP, VPC endpoints, and request tags) across six discrete evaluation phases:

Loading diagram...

Stage 1: The Default State (Implicit Deny)

All AWS API requests begin in an implicit deny state. If no applicable policy explicitly grants permission for the requested action on the target resource, the authorization engine denies access by default. An implicit deny is not an active rejection statement; it is simply the absence of an explicit allow.

Stage 2: The Explicit Deny Check

The authorization engine inspects every policy that applies to the request context. This includes Service Control Policies (SCPs), Resource Control Policies (RCPs), IAM identity-based policies, resource-based policies, IAM permission boundaries, and STS session policies. If any single statement in any of these policies specifies "Effect": "Deny" matching the action, resource, and conditions, the evaluation engine terminates immediately with a final decision of DENY. An explicit deny cannot be overridden by any number of explicit allows.

Stage 3: AWS Organizations Service Control Policies (SCPs)

If the requesting principal resides in an AWS member account managed by AWS Organizations, the request must pass through the account's SCP hierarchy (evaluated from the Organization Root, through each nested Organizational Unit [OU], down to the member account). SCPs define the maximum permissions ceiling for IAM principals in member accounts. If an SCP denies the action or fails to include an allow for the service, the request is denied.

Exam Tip: SCPs do not apply to the AWS Organizations Management Account, nor do they restrict AWS Service-Linked Roles. However, SCPs apply to all member account principals, including the member account's root user.

Stage 4: AWS Organizations Resource Control Policies (RCPs)

Resource Control Policies (RCPs) enforce centralized guardrails on the resource side across accounts within an AWS Organization. While SCPs filter what principals within an organization can do, RCPs restrict the maximum permissions that can be granted on AWS resources (such as Amazon S3 buckets, AWS KMS keys, Amazon SQS queues, and AWS Secrets Manager secrets) regardless of where the requesting principal originates.

Custom RCPs contain only Deny statements; the AWS managed RCPFullAWSAccess policy, attached to every root, OU, and account when RCPs are enabled, allows everything else. A request to a resource in a member account is therefore blocked when an applicable RCP explicitly denies it. RCPs cover a defined set of services (for example Amazon S3, AWS STS, AWS KMS, Amazon SQS, and AWS Secrets Manager), don't apply to resources in the management account, and don't restrict service-linked roles.

Stage 5: Resource-Based vs. Identity-Based Policy Evaluation

Once organizational guardrails permit the action, the engine evaluates identity-based policies (attached to the IAM user, group, or role) and resource-based policies (attached to the resource, such as S3 bucket policies, KMS key policies, SQS access policies, or IAM role trust policies). The evaluation rules depend heavily on whether the request is intra-account or cross-account.

Stage 6: IAM Permission Boundaries

If the calling principal is an IAM user or IAM role that has an IAM Permission Boundary attached, the requested action must be explicitly permitted by the boundary policy. The permission boundary acts as a mathematical intersection filter: Effective Permissions = Identity-Based Policy ∩ Permission Boundary. If the boundary does not explicitly allow the action, the request is implicitly denied. Within the same account, a resource-based policy that names an IAM user ARN or a role session ARN grants access even if the boundary doesn't allow the action, but a resource-based policy that names the IAM role ARN is still limited by the boundary's implicit deny.

Stage 7: STS Session Policies

When an IAM role is assumed using the AWS Security Token Service (AWS STS) via AssumeRole, AssumeRoleWithSAML, or AssumeRoleWithWebIdentity, the caller can pass an optional inline or managed Session Policy. The session policy further scopes down the temporary credentials. The effective permissions are the intersection of the role's identity-based policies and the session policy: Effective Session Permissions = Role Policies ∩ Session Policy.

---

Policy Types & Governance Architecture

The following table compares the six core policy categories evaluated by the AWS authorization engine:

---

Intra-Account vs. Cross-Account Authorization Rules

One of the most frequently tested concepts on the AWS Certified Security – Specialty exam is the architectural difference between intra-account and cross-account evaluation logic.

Intra-Account Evaluation (OR Logic / Union)

When the requesting principal and the target resource reside in the same AWS account, the authorization engine evaluates identity-based policies and resource-based policies using OR logic:

• An explicit Allow in either the identity-based policy OR the resource-based policy is sufficient to grant access, provided there is no explicit Deny in any applicable policy and permission boundaries permit the action.
• Example: User Alice in Account 111122223333 needs to read from S3 bucket corp-data in Account 111122223333. If Alice has an identity-based policy allowing s3:GetObject on corp-data/*, she can read objects even if the S3 bucket policy is completely empty. Conversely, if Alice has no identity policies, but the S3 bucket policy explicitly allows arn:aws:iam::111122223333:user/Alice to perform s3:GetObject, access is granted.

Cross-Account Evaluation (AND Logic / Intersection)

When the requesting principal resides in Account 111111111111 (Source Account) and the target resource resides in Account 222222222222 (Destination Account), the authorization engine enforces AND logic:

• The principal's account must allow outbound access via an identity-based policy.
• The resource's account must allow inbound access via a resource-based policy (or through an IAM role trust policy if using sts:AssumeRole).
• Both accounts must explicitly permit the access. If either account omits the allow, or if either account contains an explicit deny, the request is denied.

Loading diagram...

The KMS Key Policy Anomaly: Intra-Account Delegation

While most AWS services follow the intra-account OR rule, AWS KMS key policies operate under fundamentally different mechanics.

A KMS Customer Managed Key (CMK) cannot be accessed by any principal—even within the same AWS account—unless the KMS key policy explicitly grants permission. Identity-based policies in the same account have zero authority over a KMS key unless the key policy explicitly delegates control to the account root.

To enable identity-based policies to grant KMS permissions within the same account, the KMS key policy must contain the following default delegation statement:

{
  "Sid": "Enable IAM User Permissions via Account Root",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:root"
  },
  "Action": "kms:*",
  "Resource": "*"
}

In this statement, specifying the account root (arn:aws:iam::111122223333:root) does not grant every user admin access; rather, it delegates authorization authority to the account's IAM engine. Once this statement is present, identity-based policies in Account 111122223333 can grant kms:Decrypt, kms:GenerateDataKey, or kms:DescribeKey.

Critical Exam Trap: If a security engineer creates a custom KMS CMK and deletes the root delegation statement, an IAM administrator with AdministratorAccess (*:*) will receive AccessDenied when attempting to manage or decrypt with that KMS key. The only way to regain access without AWS Support is if another principal explicitly named in the key policy modifies the key policy.

Cross-Account S3 + KMS Access: The Three-Policy Triad

When an IAM principal in Account 111111111111 reads an object encrypted with SSE-KMS from an S3 bucket in Account 222222222222, access requires a synchronized three-policy triad:

1. Account 111111111111 IAM Identity Policy: Must grant s3:GetObject on arn:aws:s3:::target-bucket/* AND kms:Decrypt on arn:aws:kms:region:222222222222:key/key-uuid.
2. Account 222222222222 S3 Bucket Policy: Must grant s3:GetObject with "Principal": {"AWS": "arn:aws:iam::111111111111:role/WorkerRole"}.
3. Account 222222222222 KMS Key Policy: Must grant kms:Decrypt with "Principal": {"AWS": "arn:aws:iam::111111111111:role/WorkerRole"}.

If the KMS key in Account 222222222222 uses the default AWS-managed key aws/s3, cross-account access is impossible. AWS-managed KMS key policies cannot be modified, and aws/s3 only permits access to principals within the same account.

---

Organizations Resource Control Policies (RCPs) vs. Service Control Policies (SCPs)

AWS Organizations provides two distinct guardrail types that operate at opposite ends of an API transaction:

Loading diagram...

Architectural Distinctions

1. Principal Perimeter (SCPs): SCPs attach to the caller's organizational hierarchy. They prevent an internal employee or compromised compute instance from making unauthorized API calls (e.g., preventing any member account principal from executing ec2:StopLogging or leaving the organization).
2. Resource Perimeter (RCPs): RCPs attach to the resource's organizational hierarchy. They prevent organization-owned resources from being accessed by unauthorized external principals or unapproved networks, regardless of how permissive a resource-based policy might be configured.
3. Defense Against Misconfigured Bucket Policies: If a junior engineer accidentally applies an S3 bucket policy allowing "Principal": "*" without IP or condition restrictions, an active RCP that restricts S3 access strictly to corporate AWS Organizations principals prevents public data exposure.

---

Specialty Exam Pitfalls & Architectural Traps

1. The Management Account SCP Exemption: SCPs never apply to principals in the AWS Organizations management account. If an exam question describes an SCP denying s3:DeleteBucket, but an administrator in the management account is able to delete a bucket, this is expected behavior. To restrict the management account, use IAM identity-based policies or permission boundaries.
2. Permission Boundaries vs. Resource-Based Policies: The answer depends on which principal the resource policy names. If an S3 bucket policy in the same account names the role ARN (arn:aws:iam::111122223333:role/AppRole), the role's boundary still applies, so a boundary that omits Amazon S3 blocks access. If the policy names the role session ARN (arn:aws:sts::111122223333:assumed-role/AppRole/session-name) or an IAM user ARN, the grant is not limited by the boundary's implicit deny.
3. NotPrincipal with Effect: Deny: Using NotPrincipal with "Effect": "Deny" in a resource policy denies all principals in the world except the ones listed. However, this pattern can accidentally deny AWS service-linked roles, replication agents, and AWS internal callers unless paired with condition keys like aws:PrincipalArn or aws:PrincipalAccount.
4. STS Session Policy Limitations: A session policy can never grant permissions beyond what the underlying assumed role possesses. It can only maintain or reduce permissions. If the underlying role lacks dynamodb:Query, passing a session policy that allows dynamodb:Query results in an implicit deny.