IAM policy for DynamoDB - Step-by-Step Execution

Concept Flow - IAM policy for DynamoDB

Define Policy Name

↓

Specify Effect: Allow/Deny

↓

List Actions (e.g., dynamodb:PutItem)

↓

Set Resources (Table ARNs)

↓

Add Conditions (optional)

↓

Attach Policy to User/Role/Group

↓

User/Role can access DynamoDB as per policy

This flow shows how to create an IAM policy for DynamoDB step-by-step, from naming to attaching it for access control.

Execution Sample

DynamoDB

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

This policy allows PutItem and GetItem actions on a specific DynamoDB table.

Execution Table

Step	Field	Value	Effect on Access
1	Version	2012-10-17	Defines policy language version
2	Statement	Array of permissions	Groups permissions together
3	Effect	Allow	Grants permission for listed actions
4	Action	[dynamodb:PutItem, dynamodb:GetItem]	Specifies allowed DynamoDB operations
5	Resource	arn:aws:dynamodb:us-east-1:123456789012:table/MyTable	Limits actions to this table only
6	Attach Policy	User/Role/Group	Enables access as per policy
7	Access Result	User can PutItem and GetItem on MyTable	Access granted as per policy

💡 Policy fully defined and attached, user access controlled accordingly

Variable Tracker

Field	Initial	After Step 3	After Step 5	Final
Effect	None	Allow	Allow	Allow
Action	None	None	[PutItem, GetItem]	[PutItem, GetItem]
Resource	None	None	arn:aws:dynamodb:us-east-1:123456789012:table/MyTable	arn:aws:dynamodb:us-east-1:123456789012:table/MyTable

Key Moments - 3 Insights

Why do we specify the Resource ARN in the policy?

Specifying the Resource ARN limits the policy's effect to that specific DynamoDB table, preventing access to other tables. See execution_table step 5.

What happens if Effect is set to Deny instead of Allow?

Setting Effect to Deny explicitly blocks the actions listed, overriding any Allow permissions. This is shown in execution_table step 3 where Effect controls permission.

Can we list multiple actions in the Action field?

Yes, the Action field accepts an array of actions, allowing multiple DynamoDB operations in one policy, as shown in execution_table step 4.

Visual Quiz - 3 Questions

Look at the execution_table, what is the Effect value at step 3?

A Deny

B Allow

C None

D Conditional

💡 Hint

Check the 'Effect' field value in execution_table row with Step 3

At which step is the Resource ARN specified in the policy?

A Step 5

B Step 4

C Step 2

D Step 6

💡 Hint

Look for the 'Resource' field in execution_table rows

If we add 'dynamodb:DeleteItem' to the Action list, what changes in variable_tracker?

A Resource ARN changes

B Effect changes to Deny

C Action field will include DeleteItem

D No change

💡 Hint

Check how the Action field values are tracked in variable_tracker

Concept Snapshot

IAM Policy for DynamoDB:
- Define 'Version' and 'Statement'
- 'Effect' is Allow or Deny
- 'Action' lists DynamoDB operations
- 'Resource' limits to specific tables
- Attach policy to user/role for access control

Full Transcript

This visual execution shows how to create an IAM policy for DynamoDB. First, you define the policy version and group permissions in a statement. Then, set the Effect to Allow to grant access. Specify the DynamoDB actions like PutItem and GetItem. Limit the policy to a specific table using the Resource ARN. Finally, attach the policy to a user or role to enable access. The execution table tracks each step and the variable tracker shows how fields like Effect, Action, and Resource change. Key moments clarify why Resource limits access, the role of Effect, and multiple actions. The quiz tests understanding of these steps and changes.

Practice

1. What does the Action element specify in an IAM policy for DynamoDB?

easy

A. The allowed or denied DynamoDB operations

B. The AWS region where the table is located

C. The encryption method used by the table

D. The billing mode of the DynamoDB table

Solution

1. Step 1: Understand the role of Action in IAM policies

   The Action element defines which DynamoDB operations (like read, write) are allowed or denied.

2. Step 2: Differentiate from other policy elements

   Other elements like Resource specify the table, but Action controls what can be done.

3. Final Answer:

   The allowed or denied DynamoDB operations -> Option A

4. Quick Check:

   Action = Allowed/Deny operations [OK]

Hint: Action controls what operations are allowed or denied [OK]

Common Mistakes:

• Confusing Action with Resource
• Thinking Action specifies table location
• Mixing Action with encryption or billing settings

2. Which of the following is the correct syntax to specify a DynamoDB table resource ARN in an IAM policy?

easy

A. "Resource": "arn:aws:s3:::mybucket"

B. "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable"

C. "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table"

D. "Resource": "arn:aws:dynamodb:us-east-1:123456789012:database/MyTable"

Solution

1. Step 1: Identify correct ARN format for DynamoDB table

   The ARN format for a DynamoDB table is: arn:aws:dynamodb:<region>::table/.

2. Step 2: Compare options to the correct format

   "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable" matches the correct format exactly. "Resource": "arn:aws:s3:::mybucket" is for S3, C misses table name, D uses wrong resource type.

3. Final Answer:

   "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable" -> Option B

4. Quick Check:

   Resource ARN for DynamoDB table = "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable" [OK]

Hint: DynamoDB table ARN ends with 'table/YourTableName' [OK]

Common Mistakes:

• Using S3 ARN format instead of DynamoDB
• Omitting the table name in ARN
• Using 'database' instead of 'table' in ARN

3. Given this IAM policy snippet, what DynamoDB actions are allowed?

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

medium

A. Full access to all DynamoDB tables

B. Writing and deleting items in the Orders table

C. Only reading items from the Orders table

D. No access because the policy is incomplete

Solution

1. Step 1: Analyze the Action list in the policy

   The policy allows only "dynamodb:GetItem" and "dynamodb:Query", which are read operations.

2. Step 2: Check the Resource and Effect

   The resource is the Orders table only, and Effect is Allow, so only reading from Orders is allowed.

3. Final Answer:

   Only reading items from the Orders table -> Option C

4. Quick Check:

   Allowed actions = GetItem and Query (read) [OK]

Hint: GetItem and Query mean read-only access [OK]

Common Mistakes:

• Assuming write or delete permissions are included
• Thinking policy applies to all tables
• Ignoring the Effect value

4. You wrote this IAM policy but it does not allow any access to your DynamoDB table. What is the error?

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

medium

A. Resource ARN is incomplete; missing table name

B. Action should be an array, not a string

C. Effect should be Deny to allow access

D. Policy is missing a Condition block

Solution

1. Step 1: Check the Resource ARN format

   The ARN ends with 'table' but does not specify the table name, so it does not point to any specific table.

2. Step 2: Understand impact of incomplete ARN

   Without a full ARN including the table name, the policy does not grant access to any resource.

3. Final Answer:

   Resource ARN is incomplete; missing table name -> Option A

4. Quick Check:

   Resource ARN must include table name [OK]

Hint: Resource ARN must specify full table name [OK]

Common Mistakes:

• Thinking Action must be an array always
• Confusing Effect Allow with Deny
• Assuming Condition is required for access

5. You want to create an IAM policy that allows a user to read from any DynamoDB table in your account but only write to a specific table named 'Inventory'. Which policy setup is correct?

hard

A. { "Effect": "Allow", "Action": ["dynamodb:PutItem"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/*" }, { "Effect": "Allow", "Action": ["dynamodb:GetItem", "dynamodb:Query"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Inventory" }

B. { "Effect": "Allow", "Action": ["dynamodb:GetItem", "dynamodb:Query", "dynamodb:PutItem"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/*" }

C. { "Effect": "Allow", "Action": "dynamodb:*", "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Inventory" }

D. { "Effect": "Allow", "Action": ["dynamodb:GetItem", "dynamodb:Query"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/*" }, { "Effect": "Allow", "Action": ["dynamodb:PutItem"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Inventory" }

Solution

1. Step 1: Identify read permissions scope

   Read actions (GetItem, Query) should apply to all tables, so Resource uses wildcard '*'.

2. Step 2: Identify write permissions scope

   Write action (PutItem) is limited to the 'Inventory' table only.

3. Step 3: Match policy statements to requirements

   { "Effect": "Allow", "Action": ["dynamodb:GetItem", "dynamodb:Query"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/*" }, { "Effect": "Allow", "Action": ["dynamodb:PutItem"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Inventory" } correctly separates read and write permissions with proper Resource ARNs.

4. Final Answer:

   Separate statements: read on all tables, write only on Inventory -> Option D

5. Quick Check:

   Read = all tables, Write = Inventory only [OK]

Hint: Use separate statements for different resource scopes [OK]

Common Mistakes:

• Granting write access to all tables
• Mixing read and write on wrong resources
• Using wildcard for write when not intended