Bucket policies for access control in AWS - Step-by-Step Execution

Process Flow - Bucket policies for access control

Create Bucket

↓

Write Bucket Policy

↓

Attach Policy to Bucket

↓

Request Access

↓

Evaluate Policy

↓

Access Granted

This flow shows creating a bucket, attaching a policy, then requests are checked against the policy to allow or deny access.

Execution Sample

AWS

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::example-bucket/*"
  }]
}

This bucket policy allows anyone to read objects from the example-bucket.

Process Table

Step	Action	Policy Evaluated	Result	Access Outcome
1	Request to read object	Check if s3:GetObject allowed for Principal *	Effect: Allow	Access Granted
2	Request to write object	Check if s3:PutObject allowed for Principal *	No matching Allow found	Access Denied
3	Request to delete object	Check if s3:DeleteObject allowed for Principal *	No matching Allow found	Access Denied
4	Request to read object with Deny policy added	Explicit Deny overrides Allow	Effect: Deny	Access Denied

💡 Requests stop after policy evaluation grants or denies access.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4
Access Outcome	None	Granted	Denied	Denied	Denied
Policy Effect	None	Allow	No Allow	No Allow	Deny

Key Moments - 2 Insights

Why does a read request succeed but a write request fail?

Because the policy explicitly allows s3:GetObject (read) but does not allow s3:PutObject (write), so write requests are denied as shown in execution_table rows 1 and 2.

What happens if there is both an Allow and a Deny for the same action?

The Deny always wins and blocks access, as shown in execution_table row 4 where Deny overrides Allow.

Visual Quiz - 3 Questions

Look at the execution table, what is the Access Outcome at Step 2 when a write request is made?

A Access Denied

B Access Pending

C Access Granted

D Access Unknown

💡 Hint

Check the 'Access Outcome' column for Step 2 in the execution_table.

At which step does an explicit Deny override an Allow?

A Step 1

B Step 4

C Step 3

D Step 2

💡 Hint

Look at the 'Policy Effect' and 'Access Outcome' columns in execution_table row for Step 4.

If the policy added s3:PutObject Allow, how would Step 2's Access Outcome change?

A It would cause an error

B It would remain Access Denied

C It would change to Access Granted

D It would be Access Pending

💡 Hint

Refer to variable_tracker showing how Access Outcome depends on Policy Effect.

Concept Snapshot

Bucket policies control who can do what with your bucket.
They use JSON statements with Effect (Allow or Deny), Principal, Action, and Resource.
Requests are checked against policies; Deny overrides Allow.
Use policies to grant or restrict access to bucket objects.
Always test policies to confirm expected access.

Full Transcript

Bucket policies are JSON documents attached to S3 buckets to control access. The flow starts with creating a bucket, writing a policy, and attaching it. When a request comes in, AWS checks the policy statements to decide if the request is allowed or denied. If the policy allows the action for the requester, access is granted. If no allow matches or there is an explicit deny, access is denied. Deny always overrides allow. For example, a policy allowing s3:GetObject lets anyone read objects, but write or delete requests are denied if not allowed. Adding an explicit deny blocks access even if allow exists. This visual trace shows step-by-step how requests are evaluated and access outcomes decided.

Practice

1. What is the main purpose of a bucket policy in AWS S3?

easy

A. To monitor the bucket usage statistics

B. To store files inside the bucket

C. To control who can access and perform actions on the bucket

D. To backup the bucket data automatically

Solution

1. Step 1: Understand bucket policy role

   A bucket policy defines permissions for users or services to access the bucket.

2. Step 2: Differentiate from other functions

   Storing files, monitoring, and backup are separate features, not controlled by bucket policies.

3. Final Answer:

   To control who can access and perform actions on the bucket -> Option C

4. Quick Check:

   Bucket policy = Access control [OK]

Hint: Bucket policies manage access permissions only [OK]

Common Mistakes:

• Confusing bucket policy with storage function
• Thinking bucket policy handles backups
• Assuming bucket policy monitors usage

2. Which of the following is the correct JSON key to specify who is allowed or denied access in a bucket policy?

easy

A. "Action"

B. "Principal"

C. "Resource"

D. "Effect"

Solution

1. Step 1: Identify the key for user or service

   The "Principal" key specifies the user, account, service, or entity the policy applies to.

2. Step 2: Differentiate from other keys

   "Action" defines allowed actions, "Resource" defines the bucket or objects, "Effect" states Allow or Deny.

3. Final Answer:

   "Principal" -> Option B

4. Quick Check:

   Who = Principal [OK]

Hint: Principal means who gets access [OK]

Common Mistakes:

• Confusing "Action" with "Principal"
• Using "Effect" to specify user
• Mixing up "Resource" with user identity

3. Given this bucket policy snippet, what does it allow?

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

medium

A. Allows anyone to upload files to the bucket

B. Allows only the bucket owner to delete objects

C. Denies all access to the bucket

D. Allows anyone to read objects from the bucket

Solution

1. Step 1: Analyze the Effect and Principal

   Effect is "Allow" and Principal is "*" meaning everyone is allowed.

2. Step 2: Check the Action and Resource

   Action is "s3:GetObject" which means read access to objects in the bucket "example-bucket".

3. Final Answer:

   Allows anyone to read objects from the bucket -> Option D

4. Quick Check:

   Allow + * + GetObject = public read [OK]

Hint: Effect Allow + Principal * + GetObject = public read [OK]

Common Mistakes:

• Thinking GetObject allows uploads
• Confusing Allow with Deny
• Ignoring the wildcard * in Principal

4. You wrote this bucket policy but users still cannot upload files:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::example-bucket"
}

What is the problem?

medium

A. The Resource ARN is missing the /* to specify objects

B. The Action s3:PutObject is invalid

C. The Principal cannot be * for uploads

D. Effect should be Deny to allow uploads

Solution

1. Step 1: Check the Resource ARN format

   To allow object uploads, Resource must include "/*" to specify objects inside the bucket.

2. Step 2: Validate Action and Principal

   s3:PutObject is valid, Principal "*" is allowed, and Effect "Allow" is correct.

3. Final Answer:

   The Resource ARN is missing the /* to specify objects -> Option A

4. Quick Check:

   PutObject needs resource with /* [OK]

Hint: Resource must end with /* for object actions [OK]

Common Mistakes:

• Using bucket ARN without /* for object actions
• Thinking Principal * is disallowed
• Confusing Allow and Deny effects

5. You want to create a bucket policy that denies all users except a specific AWS account (ID: 123456789012) from deleting objects in your bucket named "secure-bucket". Which policy snippet correctly enforces this?

hard

A. {
"Effect": "Deny",
"Principal": "*",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::secure-bucket/*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalAccount": "123456789012"
}
}
}

B. {
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::123456789012:root"},
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::secure-bucket/*"
}

C. {
"Effect": "Deny",
"Principal": {"AWS": "arn:aws:iam::123456789012:root"},
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::secure-bucket/*"
}

D. {
"Effect": "Allow",
"Principal": "*",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::secure-bucket/*"
}

Solution

1. Step 1: Understand the requirement

   We want to deny delete actions to everyone except the specified account.

2. Step 2: Analyze each option

   { "Effect": "Deny", "Principal": "*", "Action": "s3:DeleteObject", "Resource": "arn:aws:s3:::secure-bucket/*", "Condition": { "StringNotEquals": { "aws:PrincipalAccount": "123456789012" } } } denies delete to all principals except where the principal account equals 123456789012 using Condition StringNotEquals. This matches the requirement.
   { "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::123456789012:root"}, "Action": "s3:DeleteObject", "Resource": "arn:aws:s3:::secure-bucket/*" } allows only the specified account but does not deny others explicitly.
   { "Effect": "Deny", "Principal": {"AWS": "arn:aws:iam::123456789012:root"}, "Action": "s3:DeleteObject", "Resource": "arn:aws:s3:::secure-bucket/*" } denies only the specified account, opposite of requirement.
   { "Effect": "Allow", "Principal": "*", "Action": "s3:DeleteObject", "Resource": "arn:aws:s3:::secure-bucket/*" } allows everyone, which is incorrect.

3. Final Answer:

   Option A correctly denies delete to all except the specified account -> Option A

4. Quick Check:

   Deny with Condition StringNotEquals excludes one account [OK]

Hint: Use Deny with Condition StringNotEquals for exceptions [OK]

Common Mistakes:

• Using Allow without Deny for blocking others
• Denying the allowed account by mistake
• Not specifying Condition for exceptions