Identity-Based versus Resource-Based Policies

Permissions in AWS come from policies attached in two places: to an identity (user, group, or role) or to a resource (like an S3 bucket or KMS key). Knowing which type applies, and how they combine, is essential for the exam because cross-account access depends entirely on this distinction.

An identity-based policy is attached to an IAM principal and defines what that principal can do. It has no Principal element because the principal is whoever it is attached to. These can be AWS-managed, customer-managed, or inline policies, and they are the most common way to grant permissions.

A resource-based policy is attached directly to a resource and includes a Principal element naming who is allowed access. Examples include S3 bucket policies, KMS key policies, SQS queue policies, and Lambda function policies. They specify both who (Principal) and what (Action) on that one resource.

This S3 bucket policy grants another account read access. The Principal names the trusted account, which only a resource-based policy can do.

Within a single account, identity-based and resource-based policies combine as a union: a request is allowed if either grants it (and nothing denies it). So an S3 object can be reached if the user's policy allows it or the bucket policy allows it. Either side opening access is enough.

For cross-account access the rule is stricter: both sides must allow it. The principal needs an identity-based policy permitting the action, and the resource-based policy in the other account must grant access to that principal. Missing either half denies the request. This is a heavily tested distinction.

Trust policies on roles are technically a kind of resource-based policy, which is why cross-account role assumption needs the trust policy plus the caller's sts:AssumeRole identity permission. Recognizing the trust policy as resource-based helps unify your mental model of how access is granted.

Not every service supports resource-based policies. Key ones that do: S3, KMS, SQS, SNS, Lambda, Secrets Manager, and ECR. When a service lacks resource policies, cross-account access must be granted through role assumption instead. The exam may test whether a chosen approach is even possible for a given service.

Use identity-based policies for general "this team can do these things" permissions. Use resource-based policies when you must grant access to a specific external principal, enable cross-account sharing on a supporting service, or set permissions that travel with the resource itself.

Because access can come from either side, auditing requires checking both. IAM Access Analyzer inspects resource-based policies to find resources shared externally or publicly. Policy simulation and last-accessed data help on the identity side. A complete review never looks at just one type.

Same-account access is a union (either policy can allow), while cross-account access requires both the identity policy and the resource policy to allow. Identity policies have no Principal; resource policies do. Match the policy type to the scenario and remember which services even support resource-based policies.

Test your policy-type reasoning.

Identity-based policies attach to principals and have no Principal element; resource-based policies attach to resources and name a Principal. Same-account access is a union of the two; cross-account access requires both to allow. Only some services (S3, KMS, SQS, SNS, Lambda, Secrets Manager, ECR) support resource policies; otherwise use role assumption.