Least privilege principle in AWS - Time & Space Complexity

Time Complexity: Least privilege principle

O(n)

Understanding Time Complexity

We want to understand how the effort to manage permissions grows as we add more users or resources.

How does the number of permission checks or policy updates change when the system grows?

Scenario Under Consideration

Analyze the time complexity of applying least privilege policies to multiple users.

// Example: Assigning least privilege policies
for each user in users:
  create policy with minimal permissions
  attach policy to user
  verify access only to allowed resources

This sequence creates and attaches a minimal permission policy for each user, ensuring they only access what they need.

Identify Repeating Operations

Look at what repeats as users increase.

• Primary operation: Creating and attaching a policy per user.
• How many times: Once for each user.

How Execution Grows With Input

Each new user requires a new policy and attachment.

Input Size (n)	Approx. API Calls/Operations
10	About 10 policy creations and attachments
100	About 100 policy creations and attachments
1000	About 1000 policy creations and attachments

Pattern observation: The work grows directly with the number of users.

Final Time Complexity

Time Complexity: O(n)

This means the effort grows in a straight line as you add more users.

Common Mistake

[X] Wrong: "One policy can cover all users without extra work as users grow."

[OK] Correct: Using one policy for all users often gives too many permissions, breaking least privilege and risking security.

Interview Connect

Understanding how permission management scales helps you design secure and manageable systems, a key skill in cloud roles.

Self-Check

"What if we grouped users by role and assigned one policy per role instead of per user? How would the time complexity change?"

Practice

1. What does the least privilege principle mean in AWS security?

easy

A. Users get only the permissions they need to do their job

B. Users get full access to all AWS services

C. Users share passwords to access resources

D. Users can access resources without authentication

Solution

1. Step 1: Understand the principle meaning

   The least privilege principle means giving users only the minimum permissions they need.

2. Step 2: Compare options to principle

   Only Users get only the permissions they need to do their job matches this by limiting permissions to what is needed.

3. Final Answer:

   Users get only the permissions they need to do their job -> Option A

4. Quick Check:

   Least privilege = minimal needed access [OK]

Hint: Least privilege means minimum permissions needed [OK]

Common Mistakes:

• Thinking least privilege means full access
• Confusing least privilege with no access
• Assuming password sharing is secure

2. Which IAM policy snippet follows the least privilege principle for allowing S3 read-only access to a specific bucket my-bucket?

easy

A. {\"Effect\": \"Allow\", \"Action\": [\"s3:DeleteObject\"], \"Resource\": \"arn:aws:s3:::my-bucket/*\"}

B. {\"Effect\": \"Allow\", \"Action\": \"s3:*\", \"Resource\": \"*\"}

C. {\"Effect\": \"Allow\", \"Action\": [\"s3:GetObject\"], \"Resource\": \"arn:aws:s3:::my-bucket/*\"}

D. {\"Effect\": \"Allow\", \"Action\": [\"ec2:StartInstances\"], \"Resource\": \"*\"}

Solution

1. Step 1: Identify required permissions for read-only S3 access

   Read-only means allowing only s3:GetObject on the specific bucket's objects.

2. Step 2: Match policy actions and resources

   {\"Effect\": \"Allow\", \"Action\": [\"s3:GetObject\"], \"Resource\": \"arn:aws:s3:::my-bucket/*\"} allows only s3:GetObject on my-bucket objects, following least privilege.

3. Final Answer:

   Policy allowing only s3:GetObject on my-bucket objects -> Option C

4. Quick Check:

   Least privilege = specific action + resource [OK]

Hint: Allow only needed actions on specific resources [OK]

Common Mistakes:

• Using wildcard * for all actions or resources
• Allowing delete or write actions unnecessarily
• Granting permissions for unrelated services

3. Given this IAM policy snippet, what is the effective permission granted?

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

medium

A. Denies all access to example-bucket

B. Allows uploading and downloading objects only in example-bucket

C. Allows full access to all S3 buckets

D. Allows deleting objects in example-bucket

Solution

1. Step 1: Analyze actions in the policy

   The policy allows s3:PutObject (upload) and s3:GetObject (download) actions.

2. Step 2: Check resource scope

   The resource is limited to objects inside example-bucket, so permissions apply only there.

3. Final Answer:

   Allows uploading and downloading objects only in example-bucket -> Option B

4. Quick Check:

   Actions + resource = upload/download in example-bucket [OK]

Hint: Check actions and resource ARN carefully [OK]

Common Mistakes:

• Assuming delete permission is included
• Thinking permissions apply to all buckets
• Confusing allow with deny

4. You created an IAM policy to allow only starting EC2 instances but users report they can also stop instances. What is the likely mistake?

medium

A. The users have an additional policy granting stop permissions

B. The policy includes both ec2:StartInstances and ec2:StopInstances actions

C. The policy is attached to the wrong user

D. The policy uses wildcard * for all EC2 actions

Solution

1. Step 1: Understand the reported behavior

   Users can stop instances, which is not intended by the new policy.

2. Step 2: Identify possible causes

   If the policy only allows starting, but users can stop, they likely have another policy granting stop permissions.

3. Final Answer:

   Users have an additional policy granting stop permissions -> Option A

4. Quick Check:

   Multiple policies combine permissions [OK]

Hint: Check all policies attached to users [OK]

Common Mistakes:

• Assuming one policy overrides others
• Not checking group or role policies
• Ignoring policy wildcards

5. You want to apply the least privilege principle for a developer who needs to manage Lambda functions but only in the dev-environment. Which approach is best?

hard

A. Give the developer admin access to manage Lambda

B. Create an IAM policy allowing all Lambda actions on all functions

C. Attach the AWS managed policy AWSLambdaFullAccess to the developer

D. Create an IAM policy allowing only Lambda actions on functions with resource ARN containing dev-environment

Solution

1. Step 1: Identify the scope of access needed

   The developer needs to manage Lambda functions only in the dev-environment.

2. Step 2: Apply least privilege by limiting actions and resources

   Create an IAM policy allowing only Lambda actions on functions with resource ARN containing dev-environment restricts Lambda actions to only functions in dev-environment, minimizing risk.

3. Step 3: Evaluate other options

   Options B, C, and D grant broader access than needed, violating least privilege.

4. Final Answer:

   Create an IAM policy allowing only Lambda actions on functions with resource ARN containing dev-environment -> Option D

5. Quick Check:

   Least privilege = limit actions + resource scope [OK]

Hint: Limit permissions by resource tags or names [OK]

Common Mistakes:

• Using broad AWS managed policies
• Granting admin or full access unnecessarily
• Ignoring resource-level restrictions