Condition keys for row-level security in DynamoDB - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

Identify the correct condition key for user identity in DynamoDB row-level security

Which condition key is used in DynamoDB to restrict access to items based on the user's identity in a row-level security policy?

A dynamodb:PrincipalId

B dynamodb:Attributes

C dynamodb:LeadingKeys

D dynamodb:UserId

💡 Hint

Think about the key that controls access based on partition key values.

The dynamodb:LeadingKeys condition key is used to restrict access to items by matching the partition key values to the user's identity or other attributes.

🧠 Conceptual

intermediate

Purpose of dynamodb:Attributes condition key

What is the main purpose of the dynamodb:Attributes condition key in DynamoDB's row-level security?

A To specify the table name in the policy

B To restrict access based on the partition key values

C To identify the user making the request

D To restrict access based on the attributes being accessed or modified

💡 Hint

Think about controlling access to specific columns or fields.

dynamodb:Attributes is used to control access to specific attributes (columns) of an item, allowing fine-grained permissions on which fields can be read or written.

📝 Syntax

advanced

Identify the valid condition expression for row-level security using dynamodb:LeadingKeys

Which of the following IAM policy condition expressions correctly restricts access to items where the partition key matches the user's ID stored in the request context?

DynamoDB

Condition:
  StringEquals:
    ???

A "dynamodb:LeadingKeys": ["${aws:userid}"]

B "dynamodb:LeadingKeys": "${aws:userid}"

C "dynamodb:LeadingKeys": "aws:userid"

D "dynamodb:LeadingKeys": ["aws:userid"]

💡 Hint

The value for dynamodb:LeadingKeys must be a list of strings with variable substitution.

The dynamodb:LeadingKeys condition expects a list of partition key values. Using ["${aws:userid}"] correctly passes the user's ID as a list.

🔧 Debug

advanced

Why does this row-level security condition fail to restrict access?

Given this IAM policy snippet for DynamoDB row-level security: "Condition": { "StringEquals": { "dynamodb:LeadingKeys": "${aws:userid}" } } Why does this condition fail to restrict access as intended?

A Because dynamodb:LeadingKeys requires a list, not a single string

B Because StringEquals cannot be used with dynamodb:LeadingKeys

C Because aws:userid is not a valid variable for condition keys

D Because the condition key should be dynamodb:Attributes instead

💡 Hint

Check the expected data type for dynamodb:LeadingKeys in conditions.

dynamodb:LeadingKeys expects a list of strings representing partition key values. Passing a single string causes the condition to fail.

❓ optimization

expert

Optimize a row-level security policy to minimize policy size and improve performance

You have a DynamoDB table with a partition key 'UserId' and many attributes. You want to restrict users to only access their own items and only read specific attributes. Which approach optimizes the IAM policy for row-level security?

A Use dynamodb:Attributes only to restrict attributes and rely on table-level permissions for item access

B Use dynamodb:LeadingKeys with the user's ID and dynamodb:Attributes with a list of allowed attributes in the condition

C Use multiple policies per user, each specifying allowed partition keys and attributes explicitly

D Use a single policy with no conditions and filter data in the application code

💡 Hint

Think about combining partition key restrictions with attribute-level restrictions in one policy.

Combining dynamodb:LeadingKeys and dynamodb:Attributes in one condition allows fine-grained, efficient row-level and attribute-level security with minimal policy size and better performance.

Practice

1. What is the main purpose of using Condition Keys in DynamoDB for row-level security?

easy

A. To encrypt data at rest in the database

B. To speed up query performance by indexing rows

C. To backup data automatically to another region

D. To control access by checking each row's attribute against user values

Solution

1. Step 1: Understand Condition Keys role

   Condition keys are used to compare row data with user attributes to decide access.

2. Step 2: Identify main purpose

   This comparison controls which rows a user can read or write, ensuring security.

3. Final Answer:

   To control access by checking each row's attribute against user values -> Option D

4. Quick Check:

   Condition keys = control access per row [OK]

Hint: Condition keys compare row data to user info for access [OK]

Common Mistakes:

• Confusing condition keys with indexing
• Thinking condition keys handle encryption
• Assuming condition keys backup data

2. Which of the following is the correct syntax to use a condition key in a DynamoDB policy to allow access only if the userId attribute matches the requester's ID?

easy

A. "Condition": {"StringEquals": {"dynamodb:LeadingKeys": "${aws:userid}"}}

B. "Condition": {"StringEquals": {"dynamodb:Attributes.userId": "${aws:userid}"}}

C. "Condition": {"StringEquals": {"dynamodb:LeadingKeys": "${aws:username}"}}

D. "Condition": {"StringEquals": {"dynamodb:Attributes.userId": "${aws:username}"}}

Solution

1. Step 1: Identify correct condition key for partition key

   "dynamodb:LeadingKeys" is used to check the partition key value in policies.

2. Step 2: Match with user ID variable

   "${aws:userid}" is the correct variable for the requester's user ID.

3. Final Answer:

   "Condition": {"StringEquals": {"dynamodb:LeadingKeys": "${aws:userid}"}} -> Option A

4. Quick Check:

   LeadingKeys with aws:userid = correct syntax [OK]

Hint: Use dynamodb:LeadingKeys for partition key in condition [OK]

Common Mistakes:

• Using dynamodb:Attributes instead of LeadingKeys for partition key
• Mixing aws:username with userId variable
• Incorrect JSON structure in condition

3. Given a DynamoDB table with partition key userId and a policy condition: "Condition": {"StringEquals": {"dynamodb:LeadingKeys": "123"}}, what will happen if a user with ID 123 tries to read a row with userId = 123?

medium

A. Access is allowed because the condition matches the partition key

B. Access is denied because the condition only checks sort keys

C. Access is allowed for all rows regardless of userId

D. Access is denied because the condition key is invalid

Solution

1. Step 1: Understand the condition key usage

   The condition checks if the partition key (userId) equals "123".

2. Step 2: Match user ID with row key

   The user ID is "123" and the row's userId is also "123", so condition passes.

3. Final Answer:

   Access is allowed because the condition matches the partition key -> Option A

4. Quick Check:

   Matching LeadingKeys value = access allowed [OK]

Hint: Condition matches partition key value means access allowed [OK]

Common Mistakes:

• Thinking condition checks sort key only
• Assuming condition key is invalid syntax
• Believing access is always denied without extra permissions

4. You wrote this condition in your DynamoDB policy: "Condition": {"StringEquals": {"dynamodb:LeadingKeys": "${aws:userid}"}}. But users report they cannot access their own rows. What is the likely problem?

medium

A. The variable ${aws:userid} is incorrect; it should be ${aws:username}

B. The condition key dynamodb:LeadingKeys only works with sort keys, not partition keys

C. The variable ${aws:userid} might not match the actual partition key values stored

D. The policy is missing the action permission for reading items

Solution

1. Step 1: Check variable correctness

   ${aws:userid} is a valid variable but must match stored partition key values exactly.

2. Step 2: Consider data mismatch

   If stored userId values differ in format or case, condition fails and denies access.

3. Final Answer:

   The variable ${aws:userid} might not match the actual partition key values stored -> Option C

4. Quick Check:

   Mismatch between variable and stored keys = access denied [OK]

Hint: Ensure variable matches stored partition key exactly [OK]

Common Mistakes:

• Assuming aws:userid is always wrong
• Confusing partition and sort keys in condition
• Ignoring missing action permissions

5. You want to enforce row-level security so that users can only update their own items in a DynamoDB table with partition key userId and sort key itemId. Which condition key setup correctly enforces this in an IAM policy?

hard

A. "Condition": {"StringEquals": {"dynamodb:LeadingKeys": "${aws:userid}"}}

B. "Condition": {"StringEquals": {"dynamodb:LeadingKeys": ["${aws:userid}", "${aws:itemid}"]}}

C. "Condition": {"StringEquals": {"dynamodb:Attributes.userId": "${aws:userid}", "dynamodb:Attributes.itemId": "${aws:itemid}"}}

D. "Condition": {"ForAllValues:StringEquals": {"dynamodb:LeadingKeys": "${aws:userid}"}}

Solution

1. Step 1: Understand table keys

   Partition key userId determines ownership; sort key itemId identifies specific items within a user's partition.

2. Step 2: Identify correct condition

   StringEquals on dynamodb:LeadingKeys with an array of [${aws:userid}, ${aws:itemid}] checks both partition and sort keys match, enforcing row-level security for specific items.

3. Final Answer:

   "Condition": {"StringEquals": {"dynamodb:LeadingKeys": ["${aws:userid}", "${aws:itemid}"]}} -> Option B

4. Quick Check:

   StringEquals dynamodb:LeadingKeys with array = partition and sort key match [OK]

Hint: Use array in dynamodb:LeadingKeys to match partition and sort keys [OK]

Common Mistakes:

• Using dynamodb:Attributes for primary key value checks
• Applying ForAllValues:StringEquals which mismatches sort key
• Using single string instead of array for both keys