Why IAM policies protect data in DynamoDB - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the action allowed by the IAM policy.

DynamoDB

{
  "Effect": "Allow",
  "Action": "[1]",
  "Resource": "*"
}

Drag options to blanks, or click blank then click option'

Adynamodb:PutItem

Bs3:PutObject

Cec2:StartInstances

Dlambda:InvokeFunction

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing actions from other AWS services like S3 or EC2.

Using read-only actions instead of write actions.

The dynamodb:PutItem action allows writing data to a DynamoDB table, which is relevant for protecting data access with IAM policies.

2fill in blank

medium

Complete the code to specify the resource ARN for a DynamoDB table named 'Users'.

DynamoDB

"Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/[1]"

Drag options to blanks, or click blank then click option'

AOrders

BLogs

CProducts

DUsers

Attempts:

3 left

💡 Hint

Common Mistakes

Using a different table name than specified.

Confusing table names with other resource types.

The resource ARN must match the DynamoDB table name you want to protect. Here, it is Users.

3fill in blank

hard

Fix the error in the IAM policy effect value.

DynamoDB

"Effect": "[1]"

Drag options to blanks, or click blank then click option'

APermitted

BAllowed

CAllow

DAuthorized

Attempts:

3 left

💡 Hint

Common Mistakes

Using synonyms like 'Allowed' or 'Permitted' which are invalid.

Misspelling the effect value.

The correct value for the effect in IAM policies is Allow. Other values cause errors.

4fill in blank

hard

Fill both blanks to complete the condition that restricts access to a specific IP address.

DynamoDB

"Condition": {
  "IpAddress": {
    "aws:SourceIp": "[1]"
  },
  "Bool": {
    "aws:SecureTransport": "[2]"
  }
}

Drag options to blanks, or click blank then click option'

A203.0.113.0/24

Btrue

Cfalse

D192.168.1.1

Attempts:

3 left

💡 Hint

Common Mistakes

Using a single IP instead of a CIDR block for the IP condition.

Setting SecureTransport to 'false' which disables HTTPS enforcement.

The IpAddress condition restricts access to the IP range 203.0.113.0/24. The Bool condition requires aws:SecureTransport to be true to enforce HTTPS.

5fill in blank

hard

Fill all three blanks to complete the IAM policy statement allowing read access only to a DynamoDB table named 'Inventory'.

DynamoDB

{
  "Effect": "[1]",
  "Action": "[2]",
  "Resource": "arn:aws:dynamodb:us-west-2:987654321098:table/[3]"
}

Drag options to blanks, or click blank then click option'

AAllow

Bdynamodb:GetItem

CInventory

Ddynamodb:PutItem

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'dynamodb:PutItem' which allows writing instead of reading.

Setting Effect to 'Deny' which blocks access.

Using the wrong table name.

The policy must Allow the dynamodb:GetItem action on the Inventory table to grant read-only access.

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