Condition keys for row-level security in DynamoDB - Step-by-Step Execution

Concept Flow - Condition keys for row-level security

Request arrives

↓

Evaluate Condition Keys

↓

Match user attributes with item attributes?

Yes No↓

Allow access

↓

Return data or error

When a request comes, DynamoDB checks condition keys to see if the user can access each row. If the user's attributes match the row's attributes, access is allowed; otherwise, it is denied.

Execution Sample

DynamoDB

Condition:
  "dynamodb:LeadingKeys": ["${www.example.com:user_id}"]

This condition allows access only to rows where the partition key matches the user's ID.

Execution Table

Step	Request User ID	Row Partition Key	Condition Check	Access Decision
1	user123	user123	user123 == user123	Allow
2	user123	user456	user123 == user456	Deny
3	user789	user789	user789 == user789	Allow
4	user789	user123	user789 == user123	Deny
5	-	-	-	Stop: No more rows

💡 Execution stops after checking all rows for matching user IDs.

Variable Tracker

Variable	Start	After 1	After 2	After 3	After 4	Final
Request User ID	user123	user123	user123	user789	user789	-
Row Partition Key	user123	user456	user789	user789	user123	-
Condition Result	N/A	True	False	True	False	-
Access Decision	N/A	Allow	Deny	Allow	Deny	-

Key Moments - 2 Insights

Why does access get denied when the user ID and partition key don't match?

Because the condition key requires the user's ID to match the row's partition key exactly, as shown in execution_table rows 2 and 4 where the condition check is false, so access is denied.

What happens if the condition key is missing or incorrect?

If the condition key is missing or does not match, DynamoDB denies access by default to protect data, ensuring no unauthorized row-level access occurs.

Visual Quiz - 3 Questions

Look at the execution table, what is the access decision at step 3?

A Error

B Deny

C Allow

D Unknown

💡 Hint

Check the 'Access Decision' column at step 3 in the execution_table.

At which step does the condition check fail for user123?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Look at the 'Condition Check' column for user123 in the execution_table.

If the request user ID changes to 'user456', what would happen at step 1?

A Access allowed for row with partition key 'user123'

B Access denied for row with partition key 'user123'

C Access allowed for all rows

D Access denied for all rows

💡 Hint

Compare the condition check logic where user ID must match the row partition key.

Concept Snapshot

Condition keys in DynamoDB control row-level access.
They compare user attributes (like user ID) with item keys.
Access is allowed only if the condition matches.
If no match, access is denied to protect data.
Use "dynamodb:LeadingKeys" for partition key checks.

Full Transcript

When a request comes to DynamoDB, it checks condition keys to decide if the user can access each row. The key condition is usually that the user's ID matches the row's partition key. If they match, access is allowed; if not, access is denied. This ensures users only see their own data. The execution table shows examples where user IDs and partition keys are compared step-by-step, resulting in allow or deny decisions. If the condition key is missing or incorrect, DynamoDB denies access by default to keep data safe.