Bucket policies for access control in AWS - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
When managing bucket policies, it's important to know how the time to apply or check policies changes as the number of policies grows.
We want to understand how the system handles more policies and how that affects access control speed.
Analyze the time complexity of applying multiple bucket policies.
aws s3api put-bucket-policy --bucket example-bucket --policy file://policy1.json
aws s3api put-bucket-policy --bucket example-bucket --policy file://policy2.json
aws s3api put-bucket-policy --bucket example-bucket --policy file://policy3.json
# ... repeated for n policies
This sequence applies multiple policies one after another to the same bucket to control access.
Each policy application is a separate API call.
- Primary operation: PutBucketPolicy API call
- How many times: Once per policy, repeated n times
Each new policy requires a new API call, so the total calls grow directly with the number of policies.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | 10 |
| 100 | 100 |
| 1000 | 1000 |
Pattern observation: The number of API calls increases linearly as the number of policies increases.
Time Complexity: O(n)
This means the time to apply policies grows directly in proportion to how many policies you have.
[X] Wrong: "Applying multiple policies happens all at once, so time stays the same no matter how many policies there are."
[OK] Correct: Each policy requires its own API call and processing, so more policies mean more time.
Understanding how operations scale with input size helps you design efficient access control and explain your reasoning clearly in interviews.
"What if we combined all policies into one document instead of multiple calls? How would the time complexity change?"
Practice
Solution
Step 1: Understand bucket policy role
A bucket policy defines permissions for users or services to access the bucket.Step 2: Differentiate from other functions
Storing files, monitoring, and backup are separate features, not controlled by bucket policies.Final Answer:
To control who can access and perform actions on the bucket -> Option CQuick Check:
Bucket policy = Access control [OK]
- Confusing bucket policy with storage function
- Thinking bucket policy handles backups
- Assuming bucket policy monitors usage
Solution
Step 1: Identify the key for user or service
The "Principal" key specifies the user, account, service, or entity the policy applies to.Step 2: Differentiate from other keys
"Action" defines allowed actions, "Resource" defines the bucket or objects, "Effect" states Allow or Deny.Final Answer:
"Principal" -> Option BQuick Check:
Who = Principal [OK]
- Confusing "Action" with "Principal"
- Using "Effect" to specify user
- Mixing up "Resource" with user identity
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*"
}Solution
Step 1: Analyze the Effect and Principal
Effect is "Allow" and Principal is "*" meaning everyone is allowed.Step 2: Check the Action and Resource
Action is "s3:GetObject" which means read access to objects in the bucket "example-bucket".Final Answer:
Allows anyone to read objects from the bucket -> Option DQuick Check:
Allow + * + GetObject = public read [OK]
- Thinking GetObject allows uploads
- Confusing Allow with Deny
- Ignoring the wildcard * in Principal
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::example-bucket"
}What is the problem?
Solution
Step 1: Check the Resource ARN format
To allow object uploads, Resource must include "/*" to specify objects inside the bucket.Step 2: Validate Action and Principal
s3:PutObject is valid, Principal "*" is allowed, and Effect "Allow" is correct.Final Answer:
The Resource ARN is missing the /* to specify objects -> Option AQuick Check:
PutObject needs resource with /* [OK]
- Using bucket ARN without /* for object actions
- Thinking Principal * is disallowed
- Confusing Allow and Deny effects
Solution
Step 1: Understand the requirement
We want to deny delete actions to everyone except the specified account.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.Final Answer:
Option A correctly denies delete to all except the specified account -> Option AQuick Check:
Deny with Condition StringNotEquals excludes one account [OK]
- Using Allow without Deny for blocking others
- Denying the allowed account by mistake
- Not specifying Condition for exceptions
