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.