Lesson 047 · AWS Learning Path

AWS 047: Identity policies and resource policies

· Published · 8 min read

An access request is evaluated by a policy on the caller and a policy attached to the target resource

The problem

A team uses Identity policies and resource policies 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 Identity policies and resource policies. 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:

  1. explain identity policies answer what this identity can do;
  2. explain resource policies answer who can access this resource;
  3. explain not every service supports resource policies;
  4. explain same-account grants have nuances;
  5. explain cross-account needs both sides;
  1. distinguish successful configuration from successful workload behavior;
  2. 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

ConceptWhat it means in practice
Identity policies answer what this identity can doThey attach to an IAM user, group, or role and do not contain a Principal element. Their account owns and manages the policy.
Resource policies answer who can access this resourceThey attach to supported resources such as S3 buckets, KMS keys, SQS queues, SNS topics, Lambda functions, and role trust policies. They normally name a Principal.
Not every service supports resource policiesWhen a service lacks a resource policy, cross-account access usually requires assuming a role in the resource account or using a service-specific mechanism.
Same-account grants have nuancesIdentity and resource-based allows can combine, but grants to an IAM role ARN and grants to an assumed-role session ARN interact differently with boundaries and session policies.
Cross-account needs both sidesThe trusted account principal needs identity permission and the resource-owning account needs a resource policy or assumable role trust. An explicit deny on either path still wins.
KMS key policies are essentialA KMS key policy is a primary control for a customer managed KMS key. IAM permissions alone do not automatically provide access unless the key policy enables the appropriate account and IAM delegation.

How to reason about it

Choose the policy location that owns the relationship. A bucket policy is often clearer when the bucket owner must see every allowed external account. An identity policy is efficient when one internal workload needs a predictable set of resources. Many designs use both, especially across accounts.

Avoid naming an individual role-session principal ARN in a resource policy unless the session-specific behavior is intentional. A role ARN is transformed to an internal principal identifier when saved in a Principal element, so deleting and recreating the role can break that trust until the policy is updated.

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

RequirementPreferred directionWhy
Bucket owner controls all external consumersS3 bucket policy with scoped principals and conditionsThe access relationship is visible with the resource.
One role accesses many resources it ownsIdentity policy on the roleThe workload permission set stays with the workload identity.
Service has no suitable resource policyCross-account role in the resource accountThe external caller assumes local permissions instead of receiving a direct resource grant.
Encrypt cross-account data with a customer KMS keyKey policy plus caller permission and grant where neededThe encryption key has an independent authorization boundary.

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

  1. Open IAM Roles and inspect an identity policy attached to a workload role.
  2. Open S3, select a learning bucket, then Permissions and Bucket policy to inspect a resource-based policy.
  3. Compare the identity ARN, resource ARN, Principal, Action, and Condition used by both sides of the access path.

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

Inspect the resource policy and public-access status of an S3 bucket separately.

aws s3api get-bucket-policy --bucket example-bucket --query Policy --output text
aws s3api get-public-access-block --bucket example-bucket

A bucket policy is only one control. Also inspect ACLs where relevant, access points, organization controls, VPC endpoint policies, KMS permissions, and S3 Block Public Access.

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 identity-policies-and-resource-policies-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:

  1. Control plane: the object or policy exists with the intended configuration.
  2. Data plane or behavior: the request, packet, session, storage path, or application does what the requirement states.
  3. 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

SymptomEvidence firstSmallest safe response
command cannot authenticatecredential source, expiry, caller preflightrestore approved temporary login
access is deniedaction, resource, principal, all policy layerscorrect only the missing or conflicting control
object appears missingaccount, Region, filters, pagination, permissionalign scope before creating anything
configured state exists but behavior failsroute, identity, dependency, logs, service statetest the next boundary in the path
cleanup is blockeddependency inventory and owning serviceremove 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

  1. Can an identity policy name a Principal?

Expected direction: No. The identity receiving the policy is already the principal.

  1. Does a bucket policy allow every service action in the account?

Expected direction: No. It controls supported actions on the bucket and objects named by its Resource elements.

  1. Why can cross-account KMS access fail while S3 access succeeds?

Expected direction: The KMS key policy and caller permissions form a separate authorization path.

  1. Does one side of a cross-account allow normally suffice?

Expected direction: No. The caller side and resource side must establish the path, unless a service-specific design changes that pattern.

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

Advertisement