Identity Policies vs Resource Policies

Concepts Covered

• Identity-based policies
• Resource-based policies
• Principals
• Resources
• Same-account access
• Cross-account access
• Explicit deny
• Role trust policies
• S3 bucket policies
• Policy evaluation traps

1. Plain-English Definition

An identity-based policy is attached to an IAM identity: a user, group, or role. It answers the question, "What can this identity do?"

A resource-based policy is attached to a resource. It answers the question, "Who can access this resource?"

The short mental model is:

identity policy: this principal can do these actions
resource policy: these principals can access this resource

Both are permissions policies. AWS can evaluate them together. An explicit deny wins over an allow. If no policy allows the request, the request is denied by default.

This matters because AWS access is not always controlled from the caller's side. Some resources, such as S3 buckets, KMS keys, SQS queues, SNS topics, Lambda functions, VPC endpoints, and IAM role trust policies, can carry their own resource-based policies.

2. Why This Matters In AWS

Many AWS permission problems are not solved by adding one more action to an IAM role.

Suppose an application role has s3:GetObject, but the bucket policy denies access unless traffic comes through a specific VPC endpoint. The identity policy alone is not enough.

Suppose Account A wants to read an S3 bucket in Account B. Account A can allow its role to call s3:GetObject, but Account B still owns the bucket. The bucket policy must also allow the external principal, unless access is delegated through a cross-account role pattern.

Suppose a Lambda function should be invoked by S3. Lambda permissions can include a resource-based policy that allows the S3 service principal to invoke the function.

For SAA-C03, this distinction is essential. The exam often hides the answer in the access direction. Is the workload assuming a role? Is a bucket granting direct access? Is the principal in another account? Is there an explicit deny? Is the service one that supports resource policies?

3. The Beginner Mental Model

Imagine a secure building.

An identity policy is like a badge rule attached to a person:

This person can enter floors 2 and 3.

A resource policy is like a door rule attached to a room:

This room allows Alice and the audit team.

The final access decision may need both. Alice's badge might allow her to enter the floor, but the room may still deny her. Or the room may allow the audit team, but Alice's organization may not allow her to access that building.

In AWS terms:

principal -> identity policy -> request
resource -> resource policy -> request
AWS evaluation -> allow or deny

The most important correction is that "resource policy" is not the same thing as "resource-level permission." An identity policy can name a specific resource ARN. That is still an identity-based policy. A resource-based policy is a policy document attached directly to the resource.

4. What That Mental Model Misses

Policy evaluation has layers.

Same-account access is different from cross-account access. In the same account, an allow in an identity-based policy or a resource-based policy can allow the request, as long as there is no explicit deny and no other boundary blocks it.

Across accounts, both sides usually matter. The principal's account must allow the principal to make the request. The resource's account must allow that external principal to access the resource. Without both sides, cross-account access often fails.

Not every service supports resource-based policies. S3 bucket policies are common. KMS key policies are critical. SQS and SNS support resource policies. Lambda supports resource-based permissions for invocation. RDS database access is not generally granted by attaching a resource policy to the DB instance.

IAM roles are special because the trust policy is a resource-based policy attached to the role. The role also has identity-based permission policies for what it can do after assumption.

5. AWS Mechanics

Identity-based policies can be AWS managed, customer managed, or inline. They attach to IAM users, groups, or roles. They specify actions, resources, and optional conditions.

Resource-based policies are inline policies attached to resources. They include a Principal element because the resource needs to say who is allowed. Identity-based policies do not include a Principal because the principal is the identity the policy is attached to.

AWS starts with an implicit deny. It checks for explicit denies across applicable policies. If an explicit deny matches, the request is denied. Then AWS checks for an allow. If a relevant allow exists and no boundary or organization guardrail blocks it, the request can proceed.

Other policy types can constrain the result: permission boundaries, service control policies, session policies, access control lists, and newer organization-level controls depending on service and context.

For cross-account access, draw both accounts:

Account A principal -> identity policy allows action
Account B resource -> resource policy allows Account A principal

Both sides must line up.

6. Architecture Examples

A private S3 bucket stores application reports. An EC2 role in the same account needs read access. You can grant that with an identity policy on the role scoped to the bucket ARN. You may not need a bucket policy unless you want additional resource-side controls.

A central logging bucket in a security account receives logs from workload accounts. The bucket policy must allow the logging service or source accounts to write to the correct prefixes. Identity policies in the source accounts may also be required depending on the service and delivery pattern.

A KMS key encrypts objects. The caller may have S3 access, but if the KMS key policy or grants do not allow decrypt, reading the object can still fail.

A Lambda function should be invoked by an S3 event. The function resource policy must allow the S3 service to invoke it from the expected bucket.

7. SAA-C03 Exam Signals

"Bucket in Account B must be accessed by a role in Account A" points to cross-account evaluation, often identity policy plus bucket policy or a role assumption design.

"Allow a service to invoke Lambda" points to Lambda resource-based permissions.

"Grant public or cross-account access to S3 objects" points to bucket policy, access points, or pre-signed URLs depending on wording.

"Explicitly deny access even if other policies allow it" points to an explicit deny in identity policy, resource policy, SCP, or another boundary.

"Principal" in the policy document usually indicates a resource-based policy.

"Trust policy" means who can assume a role, not what the role can do afterward.

8. Common Traps

Do not confuse a policy that names a resource ARN with a resource-based policy. The attachment point determines the policy type.

Do not forget the resource owner in cross-account access.

Do not add permissions to a role when the resource policy is the actual blocker.

Do not ignore explicit deny. It overrides allow.

Do not assume every service has bucket-policy-like behavior. Resource policies are service-specific.

Do not forget KMS key policies. Many encrypted-data access failures are KMS permission failures wearing a storage-service costume.

9. What To Learn Next

Next, study Amazon S3 because S3 is the most common place where identity policies, bucket policies, public access controls, and cross-account access meet.

Then study Security Groups vs NACLs, which gives the same style of decision discipline for network controls.

Official AWS references:

• Identity-based policies and resource-based policies
• Policies and permissions in IAM
• Cross-account resource access in IAM