Amazon S3 Permissions and Bucket Policies – SAP-C02 Study Guide | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

Amazon S3 authorization commonly involves multiple policy types working together. This lesson focuses on the difference between identity-based IAM policies and resource-based S3 bucket policies, how to scope permissions to bucket and object resources, and why an explicit deny overrides an allow.

These concepts are important in SAP-C02 scenarios involving delegated access, cross-account permissions, least privilege, and troubleshooting unexpected authorization results.

Key Concepts

Identity-Based IAM Policies

An identity-based policy is attached to an IAM identity, such as a user, group, or role. It defines which actions that identity is allowed or denied to perform against specified resources.

A typical S3 identity policy might allow a user to:

List buckets in the account.
Determine bucket locations.
List the contents of a particular bucket.
Upload objects to a specific bucket.
Download objects from a specific bucket.

An identity-based policy does not normally include a Principal element because the identity to which the policy is attached is already the subject of the policy.

Resource-Based S3 Bucket Policies

An S3 bucket policy is attached directly to a bucket. It specifies:

The effect: Allow or Deny.
The permitted S3 actions.
The target resource or resources.
The Principal that receives the permission.

Bucket policies are especially useful when:

Granting access to IAM identities in another AWS account.
Granting access to AWS services.
Applying permissions directly at the bucket boundary.
Restricting access based on conditions such as VPC endpoints, source accounts, or encryption requirements.

For example, a bucket policy can allow one specific IAM user to delete objects while other permissions remain controlled through an identity policy.

S3 Actions and Resource ARN Scope

S3 uses different ARN formats for bucket-level and object-level operations.

Permission type	Example actions	Required resource format
Account or service-level	`s3:ListAllMyBuckets`, `s3:GetBucketLocation`	Often `Resource: "*"`
Bucket-level	`s3:ListBucket`	`arn:aws:s3:::bucket-name`
Object-level	`s3:GetObject`, `s3:PutObject`, `s3:DeleteObject`	`arn:aws:s3:::bucket-name/*` or a narrower object prefix

The distinction is critical. The bucket ARN does not represent objects inside the bucket. Conversely, an object ARN does not grant bucket-level operations such as listing the bucket.

A policy granting object access usually needs the trailing /*:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject"
  ],
  "Resource": "arn:aws:s3:::example-bucket/*"
}

A policy granting s3:ListBucket should target the bucket ARN without /*:

{
  "Effect": "Allow",
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::example-bucket"
}

How Allows Combine

When an IAM identity policy and an S3 bucket policy both apply to the same request, an applicable allow from either policy can contribute to authorization, provided no explicit deny applies.

For example:

An identity policy allows s3:GetObject and s3:PutObject.
A bucket policy allows s3:DeleteObject for a particular IAM principal.
The principal can perform all three actions on the permitted object resources.

This does not mean that every permission in either policy is automatically available. The action, resource, principal, conditions, account context, and other policy controls must all match the request.

Explicit Deny Overrides an Allow

An explicit Deny takes precedence over any applicable Allow, including an allow in a bucket policy.

If an identity policy allows s3:DeleteObject and a bucket policy also allows it, an explicit deny in the identity policy still prevents deletion. The same principle applies to denies in other policy mechanisms, such as service control policies, permissions boundaries, and session policies.

Conceptually:

Explicit deny present  -> Access denied
No allow present       -> Access denied
Allow present, no deny -> Access permitted, subject to other controls

Console Access Requires More Than Data Access

The S3 console performs several API calls to display the account, buckets, properties, and objects. A user may have permission to upload or download objects but still receive console errors or be unable to view certain pages because the console requires additional permissions.

Common console-related permissions include:

s3:ListAllMyBuckets
s3:GetBucketLocation
s3:ListBucket
Permissions for viewing bucket properties or configuration, depending on the console operation

A policy designed only for application data access may work through the AWS CLI or SDK while providing an incomplete console experience.

Exam-Relevant Takeaways

Identity-based policies are attached to IAM users, groups, or roles.
S3 bucket policies are resource-based policies attached to buckets.
Bucket policies include a Principal; identity policies generally do not.
s3:ListBucket targets the bucket ARN without a trailing /*.
s3:GetObject, s3:PutObject, and s3:DeleteObject target object ARNs, commonly using bucket-name/*.
Listing all buckets and getting bucket locations are separate from listing objects in a particular bucket.
A resource-based policy can grant permissions to a specific IAM principal, including a principal from another account when the trust and account requirements are satisfied.
An explicit deny overrides an explicit allow.
A permission that works for the CLI or SDK may not provide enough permissions for the S3 console.
Least-privilege policies should restrict actions, resources, principals, and conditions wherever practical.

Architecture Decision Guide

Requirement	Recommended control	Design consideration
Give an IAM role access to application objects	Identity-based policy on the role	Prefer roles for workloads and federated access rather than long-lived IAM users
Grant another AWS account access to a bucket	S3 bucket policy plus appropriate permissions in the trusted account	Specify the intended principal and avoid broad account-wide access unless required
Restrict access to objects under a prefix	Object ARN with a prefix, such as `arn:aws:s3:::bucket/reports/*`	Include only the prefixes the principal needs
Allow object uploads but not downloads	Allow `s3:PutObject` without allowing `s3:GetObject`	Consider encryption and object ownership requirements as well
Allow downloads but prevent deletion	Allow `s3:GetObject` and add an explicit `s3:DeleteObject` deny where appropriate	A deny overrides any delete allow elsewhere
Let a principal list a bucket	Allow `s3:ListBucket` on the bucket ARN	Add a condition such as `s3:prefix` to limit visible prefixes when needed
Enforce a bucket-wide security rule	S3 bucket policy with an explicit deny	Common examples include denying non-TLS requests or unencrypted uploads
Provide full S3 console navigation	Add the required discovery and configuration read permissions	Data-plane permissions alone may not be sufficient

Common Exam Traps

Using the Wrong ARN for the Action

arn:aws:s3:::bucket-name identifies the bucket, not the objects within it. Using it for GetObject or PutObject commonly causes AccessDenied.

Likewise, arn:aws:s3:::bucket-name/* does not represent the bucket itself for ListBucket.

Forgetting the Principal in a Bucket Policy

A bucket policy is resource-based and must identify who receives the permission through Principal, unless the policy statement is a deny that intentionally applies broadly.

Assuming an Allow Is Sufficient

Authorization can still fail because of an explicit deny in an identity policy, permissions boundary, session policy, SCP, or another applicable control. Always search for denies when an apparently valid allow does not work.

Confusing Bucket Listing with Object Listing

The ability to see bucket names does not imply permission to list objects inside those buckets. These are distinct actions and may require different resource scopes.

Granting More Console Permissions Than Needed

Adding broad read or administrative permissions merely to make the console work violates least privilege. Identify the specific console API calls required, or use the CLI/SDK for narrowly scoped operational access.

Treating a Bucket Policy as a Replacement for All IAM Controls

A bucket policy can grant or deny S3 access, but other controls may still apply. For example, an SCP can impose an organization-wide restriction, and a permissions boundary can limit the maximum permissions an IAM principal can receive.

Real-World Engineer Notes

Prefer IAM roles with temporary credentials for human federation and workloads. IAM users with console passwords are generally less desirable for production access.
Test policies with the IAM policy simulator, AWS CLI, or SDK in addition to the console. The console can generate failures caused by missing UI-discovery permissions rather than missing data-plane permissions.
Scope object access to prefixes where possible instead of granting access to every object in a bucket.
Use conditions to enforce security requirements such as aws:SecureTransport, required encryption headers, source VPC endpoints, or approved principals.
Keep bucket-level and object-level permissions conceptually separate during troubleshooting. First identify the API action, then determine whether its resource is the bucket or an object.
For cross-account access, both the resource policy and the caller’s account-side permissions must be considered. Ownership and S3 Object Ownership settings can also affect who can manage uploaded objects.
When deleting versioned objects, s3:DeleteObject and version-specific deletion behavior may require additional consideration, including permissions involving object versions.

Quick Reference Summary

Identity policy       -> Attached to user, group, or role
Bucket policy         -> Attached to an S3 bucket; includes Principal
ListBucket            -> Bucket ARN without /*
Get/Put/DeleteObject  -> Object ARN, commonly bucket ARN plus /*
Explicit Deny         -> Overrides every applicable Allow
Console visibility    -> May require bucket discovery and read permissions

A reliable troubleshooting sequence is:

Identify the exact API action being attempted.
Check whether the resource is a bucket or an object.
Verify the principal and applicable identity/resource policies.
Search for explicit denies in all applicable policy layers.
Check conditions, account boundaries, encryption requirements, and object ownership.

Flashcards

1. What is an identity-based policy?

A policy attached to an IAM user, group, or role that defines allowed or denied actions against resources.

2. What is an S3 bucket policy?

A resource-based policy attached to an S3 bucket that controls access to the bucket and its objects.

3. Which policy type normally contains a `Principal` element?

A resource-based policy, such as an S3 bucket policy.

4. What resource ARN does `s3:ListBucket` use?

The bucket ARN without /*, such as arn:aws:s3:::example-bucket.

5. What resource ARN is commonly used for `s3:GetObject`?

An object ARN, such as arn:aws:s3:::example-bucket/*.

6. Does permission to list all buckets grant permission to list their objects?

No. Account-level bucket discovery and object listing are separate permissions.

7. What happens when an identity policy allows deletion but another applicable policy explicitly denies it?

The request is denied because explicit deny overrides allow.

8. Why might the S3 console fail even when an object upload works through the CLI?

The console may require additional permissions for bucket discovery, location, properties, or other UI operations.

9. Can a bucket policy grant access to a principal in another AWS account?

Yes, when the bucket policy identifies the trusted principal and the cross-account authorization requirements are satisfied.

10. What is a common least-privilege improvement for object access?

Restrict the object resource to a required prefix instead of the entire bucket.

Practice Questions

Question 1

An IAM role has an identity policy allowing s3:GetObject on arn:aws:s3:::finance-data. Calls to download objects from the bucket return AccessDenied. What is the most likely correction?

A. Add s3:ListAllMyBuckets to the role
B. Change the resource to arn:aws:s3:::finance-data/*
C. Add s3:ListBucket on arn:aws:s3:::finance-data/*
D. Add a Principal element to the identity policy

Correct answer: B

Explanation: GetObject is an object-level action and requires object resources. The bucket ARN without /* identifies the bucket, not the objects within it.

Question 2

A bucket policy allows an IAM user to perform s3:DeleteObject. The user’s identity policy allows uploads and downloads but does not allow deletion. Can the user delete objects?

A. No, because both policies must contain an allow
B. Yes, because the resource-based bucket policy can grant the permission
C. No, because only IAM roles can receive bucket policy permissions
D. Yes, but only through the S3 console

Correct answer: B

Explanation: An applicable resource-based allow can grant the action to the specified principal, provided no explicit deny or other authorization constraint applies.

Question 3

An identity policy allows s3:DeleteObject, and a bucket policy explicitly denies s3:DeleteObject for the same principal and object resources. What is the result?

A. Deletion succeeds because the identity policy is attached directly to the user
B. Deletion succeeds only from the AWS CLI
C. Deletion is denied
D. The bucket policy is ignored because it is resource-based

Correct answer: C

Explanation: An explicit deny overrides all applicable allows, regardless of whether the allow comes from an identity policy or a bucket policy.

Question 4

A user can see an S3 bucket in the console but cannot view its objects. Which permission is most directly associated with listing the objects in that bucket?

A. s3:ListBucket on the bucket ARN
B. s3:ListAllMyBuckets on every object ARN
C. s3:GetObject on the bucket ARN
D. s3:GetBucketLocation on every object ARN

Correct answer: A

Explanation: s3:ListBucket controls listing objects in a bucket and uses the bucket ARN without /*. s3:ListAllMyBuckets controls account-level bucket discovery, not the contents of a bucket.

Question 5

A security team wants to ensure that no principal can access a bucket over an unencrypted transport connection, even if another policy grants access. Which approach is most appropriate?

A. Add an explicit deny in the bucket policy using a condition on aws:SecureTransport
B. Grant s3:ListAllMyBuckets only to administrators
C. Add s3:GetObject to the bucket policy
D. Remove all identity policies from the account