Why IAM policies protect data in DynamoDB - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

How IAM policies control access to DynamoDB data

Which statement best explains how IAM policies protect data in DynamoDB?

A IAM policies back up DynamoDB data regularly to protect against data loss.

B IAM policies automatically encrypt all data stored in DynamoDB tables without user configuration.

C IAM policies define who can access DynamoDB tables and what actions they can perform, preventing unauthorized data access.

D IAM policies monitor network traffic to detect unauthorized access attempts to DynamoDB.

💡 Hint

Think about how permissions control user actions on data.

IAM policies specify permissions for users and roles, controlling who can read, write, or delete data in DynamoDB. This prevents unauthorized users from accessing or modifying data.

❓ query_result

intermediate

Effect of missing IAM permission on DynamoDB query

Given a user without the dynamodb:Query permission on a table, what will happen when they try to run a query?

DynamoDB

aws dynamodb query --table-name Customers --key-condition-expression "CustomerId = :id" --expression-attribute-values '{":id":{"S":"123"}}'

A The query fails with an AccessDeniedException error.

B The query runs successfully and returns matching items.

C The query returns an empty result set without error.

D The query runs but only returns partial data.

💡 Hint

Consider what happens if permissions are missing for an action.

Without the dynamodb:Query permission, the request is denied and AWS returns an AccessDeniedException error, preventing unauthorized data access.

📝 Syntax

advanced

Identify the correct IAM policy statement to allow reading from a DynamoDB table

Which IAM policy statement correctly allows a user to read items from the DynamoDB table named Orders?

DynamoDB

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "dynamodb:GetItem",
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders"
    }
  ]
}

A

{
  "Effect": "Deny",
  "Action": "dynamodb:GetItem",
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders"
}

B

{
  "Effect": "Allow",
  "Action": "dynamodb:PutItem",
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders"
}

C

{
  "Effect": "Allow",
  "Action": "dynamodb:DeleteItem",
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders"
}

D

{
  "Effect": "Allow",
  "Action": "dynamodb:GetItem",
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders"
}

💡 Hint

Look for the action that reads data and the effect that allows it.

The dynamodb:GetItem action allows reading a single item from the table. The effect must be Allow to grant permission.

❓ optimization

advanced

Optimizing IAM policies for least privilege on DynamoDB

You want to grant a user permission to only update the Status attribute of items in the Shipments table. Which IAM policy approach best follows the principle of least privilege?

A Allow <code>dynamodb:UpdateItem</code> on the <code>Shipments</code> table with a condition restricting updates to the <code>Status</code> attribute only.

B Allow all DynamoDB actions on the <code>Shipments</code> table.

C Allow <code>dynamodb:PutItem</code> on the <code>Shipments</code> table.

D Allow <code>dynamodb:UpdateItem</code> on the entire <code>Shipments</code> table without conditions.

💡 Hint

Think about limiting permissions to only what is necessary.

Using a condition to restrict updates to only the Status attribute ensures the user cannot modify other data, following least privilege.

🔧 Debug

expert

Diagnose why an IAM policy does not allow reading from DynamoDB

A user has this IAM policy but cannot read items from the Inventory table. What is the most likely reason?

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["dynamodb:Scan"],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Inventory"
    }
  ]
}

A The Resource ARN is incorrect and does not match the Inventory table.

B The policy only allows Scan, but the user is trying to use GetItem or Query which are not allowed.

C The Effect should be Deny instead of Allow to permit access.

D The policy is missing the version date, so it is invalid.

💡 Hint

Check which actions the policy allows versus what the user tries to do.

The policy only permits the Scan action. If the user tries to perform GetItem or Query, those actions are denied because they are not included in the policy.

Practice

1. What is the main purpose of IAM policies in DynamoDB?

easy

A. To speed up database queries

B. To create database tables

C. To store data backups automatically

D. To control who can access and modify data

Solution

1. Step 1: Understand IAM policy role

   IAM policies define permissions for users and services to access AWS resources.

2. Step 2: Connect IAM policies to data protection

   By controlling who can read or write data, IAM policies protect the data from unauthorized access.

3. Final Answer:

   To control who can access and modify data -> Option D

4. Quick Check:

   IAM policies = control access [OK]

Hint: IAM policies control access rights to data [OK]

Common Mistakes:

• Thinking IAM speeds up queries
• Confusing IAM with data backup
• Believing IAM creates tables

2. Which of the following is a correct part of an IAM policy JSON for DynamoDB?

easy

A. {\"Effect\": \"Allow\", \"Action\": \"dynamodb:PutItem\", \"Resource\": \"arn:aws:dynamodb:region:account-id:table/TableName\"}

B. {\"Effect\": \"Deny\", \"Action\": \"dynamodb:DeleteTable\", \"Resource\": \"arn:aws:s3:::bucket-name\"}

C. {\"Effect\": \"Allow\", \"Action\": \"s3:PutObject\", \"Resource\": \"arn:aws:dynamodb:region:account-id:table/TableName\"}

D. {\"Effect\": \"Allow\", \"Action\": \"dynamodb:Query\", \"Resource\": \"arn:aws:dynamodb:region:account-id:table/\"}

Solution

1. Step 1: Check action and resource match

   {\"Effect\": \"Allow\", \"Action\": \"dynamodb:PutItem\", \"Resource\": \"arn:aws:dynamodb:region:account-id:table/TableName\"} correctly allows the PutItem action on a DynamoDB table resource ARN.

2. Step 2: Identify incorrect resource or action in others

   {\"Effect\": \"Deny\", \"Action\": \"dynamodb:DeleteTable\", \"Resource\": \"arn:aws:s3:::bucket-name\"} uses an S3 bucket ARN with a DynamoDB action, {\"Effect\": \"Allow\", \"Action\": \"s3:PutObject\", \"Resource\": \"arn:aws:dynamodb:region:account-id:table/TableName\"} mixes S3 action with DynamoDB resource, {\"Effect\": \"Allow\", \"Action\": \"dynamodb:Query\", \"Resource\": \"arn:aws:dynamodb:region:account-id:table/\"} has incomplete resource ARN.

3. Final Answer:

   Correct IAM policy JSON for DynamoDB PutItem -> Option A

4. Quick Check:

   Action and resource must match service [OK]

Hint: Match Action and Resource service in IAM JSON [OK]

Common Mistakes:

• Using wrong ARN for resource
• Mixing actions from different AWS services
• Leaving resource ARN incomplete

3. Given this IAM policy snippet, what will happen if a user tries to delete an item from the DynamoDB table?

{
  "Effect": "Deny",
  "Action": "dynamodb:DeleteItem",
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders"
}

medium

A. The user can delete items normally

B. The policy has no effect on delete actions

C. The user is denied permission to delete items

D. The user can delete items only if they own them

Solution

1. Step 1: Understand the Effect field

   The policy has Effect set to Deny, which blocks the specified action.

2. Step 2: Check the Action and Resource

   The action dynamodb:DeleteItem on the Orders table is denied, so the user cannot delete items there.

3. Final Answer:

   The user is denied permission to delete items -> Option C

4. Quick Check:

   Effect Deny blocks action [OK]

Hint: Effect Deny always blocks the action [OK]

Common Mistakes:

• Assuming Deny means allow
• Ignoring the resource ARN
• Thinking ownership affects this policy

4. A developer wrote this IAM policy to allow reading from a DynamoDB table but it doesn't work:

{
  "Effect": "Allow",
  "Action": "dynamodb:GetItem",
  "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table"
}

What is the error?

medium

A. The Action dynamodb:GetItem is invalid

B. The Resource ARN is incomplete; it must specify the table name

C. Effect should be Deny to allow access

D. The policy must include a Condition block

Solution

1. Step 1: Check the Resource ARN format

   The ARN ends with :table but lacks the specific table name, so it is incomplete.

2. Step 2: Understand ARN requirements for DynamoDB

   IAM policies require full ARN including the table name to apply permissions correctly.

3. Final Answer:

   The Resource ARN is incomplete; it must specify the table name -> Option B

4. Quick Check:

   Complete ARN needed for resource [OK]

Hint: Always include full table name in ARN [OK]

Common Mistakes:

• Leaving ARN incomplete
• Confusing Allow and Deny effects
• Thinking Condition is mandatory

5. You want to protect sensitive data in your DynamoDB table by allowing only users with a specific IAM role to update items. Which approach best uses IAM policies to achieve this?

hard

A. Create an IAM policy that allows dynamodb:UpdateItem only for the role's ARN on the table resource

B. Grant all users dynamodb:UpdateItem permission and rely on application code to check roles

C. Use a policy that denies dynamodb:UpdateItem for everyone except the root user

D. Create a policy allowing dynamodb:UpdateItem on all tables for all users

Solution

1. Step 1: Identify the need for role-based permission

   Only users with a specific IAM role should update items, so permissions must be scoped to that role.

2. Step 2: Use IAM policy to allow UpdateItem only for that role on the table

   Creating a policy that allows dynamodb:UpdateItem only for the role's ARN on the table resource enforces this securely.

3. Final Answer:

   Create an IAM policy that allows dynamodb:UpdateItem only for the role's ARN on the table resource -> Option A

4. Quick Check:

   Role-based IAM policy controls updates [OK]

Hint: Scope permissions to specific role and resource [OK]

Common Mistakes:

• Relying on app code instead of IAM
• Using overly broad permissions
• Denying everyone except root is too restrictive