Bird
Raised Fist0
AWScloud~5 mins

IAM policies (JSON structure) in AWS - Time & Space Complexity

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Time Complexity: IAM policies (JSON structure)
O(n)
Understanding Time Complexity

When working with IAM policies in AWS, it's important to understand how the time to process these policies grows as they get bigger or more complex.

We want to know how the number of policy statements affects the time AWS takes to evaluate permissions.

Scenario Under Consideration

Analyze the time complexity of evaluating an IAM policy with multiple statements.


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

This policy has multiple statements that AWS evaluates to decide if a request is allowed.

Identify Repeating Operations

When AWS checks permissions, it looks at each statement in the policy one by one.

  • Primary operation: Evaluating each policy statement against the request.
  • How many times: Once per statement in the policy.
How Execution Grows With Input

As the number of statements grows, AWS must check more statements to find a match.

Input Size (n)Approx. API Calls/Operations
1010 checks
100100 checks
10001000 checks

Pattern observation: The number of checks grows directly with the number of statements.

Final Time Complexity

Time Complexity: O(n)

This means the time to evaluate the policy grows in a straight line as you add more statements.

Common Mistake

[X] Wrong: "Adding more statements won't affect evaluation time much because AWS is very fast."

[OK] Correct: Even though AWS is fast, each statement adds work. More statements mean more checks, so evaluation time grows with policy size.

Interview Connect

Understanding how policy size affects evaluation helps you design efficient permissions and shows you can think about system performance clearly.

Self-Check

"What if the policy had nested conditions inside statements? How would that affect the time complexity?"

Practice

(1/5)
1. What is the main purpose of an IAM policy in AWS?
easy
A. To create virtual machines
B. To define permissions for users and resources
C. To monitor network traffic
D. To store data in the cloud

Solution

  1. Step 1: Understand IAM policy role

    An IAM policy is a JSON document that specifies permissions for AWS users, groups, or roles.
  2. Step 2: Identify main function

    Its main function is to control what actions are allowed or denied on AWS resources.
  3. Final Answer:

    To define permissions for users and resources -> Option B
  4. Quick Check:

    IAM policy = permissions definition [OK]
Hint: IAM policies control access permissions in AWS [OK]
Common Mistakes:
  • Confusing IAM policies with data storage
  • Thinking IAM policies monitor network traffic
  • Assuming IAM policies create virtual machines
2. Which of the following is the correct JSON key to specify the effect of a statement in an IAM policy?
easy
A. "Permission"
B. "Action"
C. "Resource"
D. "Effect"

Solution

  1. Step 1: Recall IAM policy statement keys

    IAM policy statements include keys like Effect, Action, Resource, and optionally Condition.
  2. Step 2: Identify key for permission type

    The key that specifies whether to allow or deny is "Effect".
  3. Final Answer:

    "Effect" -> Option D
  4. Quick Check:

    Effect key = permission type [OK]
Hint: Effect key sets allow or deny in IAM policy [OK]
Common Mistakes:
  • Using "Permission" instead of "Effect"
  • Confusing "Action" with permission type
  • Mistaking "Resource" for effect
3. Given this IAM policy statement snippet:
{
  "Effect": "Allow",
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::example-bucket"
}

What permission does this statement grant?
medium
A. Allows listing the bucket itself
B. Allows listing objects inside the bucket
C. Allows deleting the bucket
D. Allows uploading objects to the bucket

Solution

  1. Step 1: Understand the Action "s3:ListBucket"

    This action allows listing the bucket itself and its metadata, not the objects inside.
  2. Step 2: Match Resource and Action

    The resource is the bucket ARN, so permission is to list the bucket (its properties), not the objects inside the bucket.
  3. Final Answer:

    Allows listing the bucket itself -> Option A
  4. Quick Check:

    s3:ListBucket = list bucket (not objects) [OK]
Hint: s3:ListBucket lists the bucket, not objects inside [OK]
Common Mistakes:
  • Confusing ListBucket with listing objects inside the bucket
  • Assuming permission to delete or upload
  • Ignoring the resource ARN level
4. Identify the error in this IAM policy statement:
{
  "Effect": "Allow",
  "Action": ["ec2:StartInstances", "ec2:StopInstances"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "ec2:Region": "us-west-2"
    }
  }
}
medium
A. The Condition key is not valid for EC2 actions
B. The Condition key should be inside the Action key
C. The policy is valid and has no errors
D. The Resource value "*" is not allowed for these actions

Solution

  1. Step 1: Check Condition usage with EC2 actions

    EC2 supports conditions like StringEquals on ec2:Region to restrict actions by region.
  2. Step 2: Verify Resource and structure

    Resource "*" is valid for EC2 start/stop actions because they apply to instances across resources.
  3. Final Answer:

    The policy is valid and has no errors -> Option C
  4. Quick Check:

    Condition on ec2:Region with Resource "*" is valid [OK]
Hint: Conditions can restrict actions by region or other keys [OK]
Common Mistakes:
  • Thinking Condition is invalid for EC2
  • Assuming Resource "*" is always wrong
  • Misplacing Condition inside Action
5. You want to create an IAM policy that allows a user to read objects only from a specific S3 bucket named "my-data-bucket" but denies deleting any objects. Which policy statement correctly achieves this?
hard
A. { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "arn:aws:s3:::my-data-bucket/*" }
B. { "Effect": "Allow", "Action": ["s3:GetObject", "s3:DeleteObject"], "Resource": "arn:aws:s3:::my-data-bucket/*" }
C. { "Effect": "Deny", "Action": "s3:DeleteObject", "Resource": "arn:aws:s3:::my-data-bucket/*" }
D. { "Effect": "Allow", "Action": "s3:*", "Resource": "arn:aws:s3:::my-data-bucket" }

Solution

  1. Step 1: Identify required permissions

    The user needs permission to read objects only, which is "s3:GetObject" on the bucket's objects.
  2. Step 2: Check for delete denial

    Not including "s3:DeleteObject" means no delete permission is granted. Explicit deny is not required if no allow exists.
  3. Step 3: Validate resource ARN

    The resource must include "/*" to specify objects inside the bucket, not the bucket itself.
  4. Final Answer:

    Allow s3:GetObject on objects in my-data-bucket only -> Option A
  5. Quick Check:

    Allow read only, no delete = { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "arn:aws:s3:::my-data-bucket/*" } [OK]
Hint: Allow only needed actions; omit delete to deny it [OK]
Common Mistakes:
  • Allowing delete by mistake
  • Using bucket ARN without /* for objects
  • Using wildcard s3:* granting too many permissions