Lesson 043 · AWS Learning Path

AWS 043: Policy structure and evaluation

Anil Jalela · Published Aug 7, 2025 · 8 min read

A policy decision engine checks request context and allows valid paths while an explicit deny blocks access

The problem

A team uses Policy structure and evaluation as a label or Console setting without proving the identity, scope, behavior, failure boundary, cost, or operational result. The configuration appears complete but the real requirement remains untested.

Final outcome

The learner will inspect, explain, test, and document Policy structure and evaluation. The submission must connect the Console and CLI view to the same AWS control, state what the evidence proves, diagnose one likely failure, and make a requirement-based architecture decision.

Learning outcomes

You will be able to:

explain a statement has core elements;
explain implicit deny is the starting state;
explain allows can form unions or intersections;
explain resource matching matters;
explain conditions must use supported keys;

distinguish successful configuration from successful workload behavior;
preserve redacted evidence and complete the stated cleanup or retention decision.

Mental model

requirement
   -> identity and permission
   -> account, Region, and resource scope
   -> configuration or request
   -> observable state
   -> workload result
   -> failure evidence
   -> cleanup or controlled retention

Never begin with a create button or a copied command. Start with the result that must be proven and the boundary that must remain protected.

Core facts

Concept	What it means in practice
A statement has core elements	Effect, Action or NotAction, Resource or NotResource, and optional Condition define permission behavior. Principal appears mainly in resource-based and role trust policies, not normal identity policies.
Implicit deny is the starting state	A request is denied unless an applicable policy allows it. An explicit Deny in any applicable policy overrides an Allow.
Allows can form unions or intersections	Identity and resource-based permissions can combine as a union in supported same-account cases. Boundaries, session policies, SCPs, and RCPs act as limiting intersections.
Resource matching matters	An allowed action on the wrong ARN is still denied. Some actions do not support resource-level permissions and require Resource "*", which should be narrowed with conditions when possible.
Conditions must use supported keys	Global and service condition keys evaluate request context. If a key is absent, operators such as IfExists and Null can change the result, especially in Deny statements.
Policy variables need context	Variables such as principal tags can make policies reusable, but missing or untrusted attributes can deny valid work or grant unintended access.

How to reason about it

Use a repeatable evaluation method: authenticate the principal, collect every applicable policy, establish the requested action and resource, evaluate conditions, find an applicable explicit deny, and then look for an applicable allow that survives every limiting policy. Never read only the identity policy shown in an error screenshot.

NotAction does not mean every action everywhere. Its meaning is the complement of actions within the statement scope. Used with Allow and Resource "*", it can grant far more than intended. Used carefully with Deny, it can create a guardrail that exempts selected actions.

Use the following decision table as a starting point, then change the answer when the scenario changes.

Requirement	Preferred direction	Why
One exact service action on one resource	Explicit Action and narrow ARN	A positive allow list is easier to reason about than a broad wildcard.
Deny access outside the organization	Resource policy condition using aws:PrincipalOrgID	The guardrail follows organization membership while explicit exceptions still need careful handling.
One template must restrict resources by team	Principal and resource tag conditions	ABAC scales when identity attributes and resource tags are governed.
Troubleshoot an unexplained denial	Policy simulator plus CloudTrail and all policy layers	The attached identity policy alone cannot reveal every boundary, organization, session, or resource restriction.

Prerequisites, permissions, Region, and cost

Run this lesson as the approved non-root course identity. Begin with aws sts get-caller-identity, confirm the private account record, and set the fixed project Region before any regional query. IAM resources are global within an account, while STS endpoints and the services reached by an identity can be regional.

Use only the read or change actions required for this lesson. An AccessDenied result is evidence to analyse, not permission to switch to root or attach AdministratorAccess. Record the action, resource, principal type, request context, and smallest justified correction.

The listed cost tier is T0 - no resource creation. Free Tier eligibility and credits are account-specific. Before a mutating lab, identify every resource that can charge, estimate its duration, start a timer, and write the reverse cleanup order. A budget reports cost after billing data arrives and is not a real-time stop control.

AWS Management Console method

Open IAM Policies, select a customer managed policy, and inspect its JSON statement elements.
Choose Edit and use policy validation without saving changes. Review errors, warnings, and suggestions.
Open the IAM Policy Simulator from the policy or AWS tools and test one action against one resource ARN.

For every step record the service page, selected account and Region, exact object, visible state, and why that state matters. A Console label or green status is not enough unless it is tied to the final workload outcome.

AWS CLI or API evidence

Simulate one identity-policy action against a specific resource, then compare the result with the live request context.

aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::<account-id>:role/ExampleRole --action-names s3:GetObject --resource-arns arn:aws:s3:::example-bucket/report.csv

The simulator explains matched statements for supported policy types, but the live request can include resource policies, SCPs, endpoint policies, session context, or service behavior that also must be checked.

Before running the command, replace every placeholder, explain each option, and decide whether the operation is read-only or mutating. Capture the exit code immediately. Redact account IDs, ARNs, public addresses, request identifiers, and personal data before sharing.

The CLI and Console are clients of AWS APIs. Matching state across them increases confidence, but neither substitutes for data-plane or application verification.

Practical work

Create policy-structure-and-evaluation-evidence.md. Record the problem, account and Region preflight, observed Console state, matching CLI result, every decision in the table, one intentional misconception, one failure diagnosis, and the retained-state or cleanup result.

The evidence package must include:

non-root principal type, account verified privately, and Region;
exact intended and observed state;
one Console observation and the matching CLI or API result;
one successful result and one denied, failed, or counterexample result;
what each result does not prove;
cost state and elapsed lab time;
cleanup evidence or a named retained-state owner and next lesson.

Verification standard

Use three levels of proof:

Control plane: the object or policy exists with the intended configuration.
Data plane or behavior: the request, packet, session, storage path, or application does what the requirement states.
Operations: monitoring, failure diagnosis, cost, ownership, and cleanup are known.

A control-plane response can precede final readiness. Use waiters or state polling where supported, then test the actual behavior. If a request times out, do not assume it failed. Inspect state and use documented idempotency before retrying a mutation.

Troubleshooting method

Symptom	Evidence first	Smallest safe response
command cannot authenticate	credential source, expiry, caller preflight	restore approved temporary login
access is denied	action, resource, principal, all policy layers	correct only the missing or conflicting control
object appears missing	account, Region, filters, pagination, permission	align scope before creating anything
configured state exists but behavior fails	route, identity, dependency, logs, service state	test the next boundary in the path
cleanup is blocked	dependency inventory and owning service	remove dependants in reviewed reverse order

Keep the original symptom and timestamp. State one hypothesis, make one reversible change, repeat the original test, and record rollback. Never open a management port to the world, expose credentials, disable TLS verification, format an unknown disk, or add broad permissions as a generic fix.

Architecture and certification decisions

Professional-level questions provide competing valid features. Identify the requirement that decides between them: human or workload identity, same-account or cross-account access, regional or zonal scope, stateful or stateless filtering, durable or ephemeral data, latency, RTO/RPO, cost, or operational ownership.

Explain why the selected option fits and why each plausible alternative fails one stated requirement. Do not rely on feature memorization or reproduce protected certification questions.

Knowledge check

A policy contains Allow s3:* and another contains Deny s3:DeleteObject. Can the principal delete?

Expected direction: No. The applicable explicit deny wins.

No statement mentions an action. What is the result?

Expected direction: Implicit deny.

A boundary allows an action but the identity policy does not. Is it granted?

Expected direction: No. A boundary sets the maximum; it does not grant permission by itself.

Why can StringNotEquals in a Deny require special care?

Expected direction: A missing key can produce a broader denial than expected. Confirm key availability and use the correct set, Null, or IfExists logic.

Cost, cleanup, and retained state

No workload resource should remain unless this lesson explicitly creates and retains one for the next numbered lab.

Cleanup evidence includes the final state query, not only a successful delete response. Search related resources, other Regions used by the lab, retained storage, public IPv4 addresses, logging destinations, and service-managed dependencies. Schedule a later billing review because cost data can lag.

Completion gate

Pass when the practical artifact explains the real problem, matches Console and CLI evidence, answers every knowledge check, diagnoses one failure without broadening access, records cost, and proves cleanup or approved retention. The learner must defend one decision orally and name the requirement that would change it.

Official sources

View complete AWS learning path