Consider a DynamoDB table Orders with items having attributes OrderID, UserID, and Status. A fine-grained access control policy restricts users to see only orders where UserID matches their own ID.
The following query is run by user with UserID = 'user123':
Scan Orders with FilterExpression: UserID = :uid
ExpressionAttributeValues: { ':uid': 'user123' }
Given the table data:
- {OrderID: 1, UserID: 'user123', Status: 'shipped'}
- {OrderID: 2, UserID: 'user456', Status: 'pending'}
- {OrderID: 3, UserID: 'user123', Status: 'delivered'}
What will be the result of this query?
Think about which items match the filter expression for the user's ID.
The filter expression restricts results to only those items where UserID equals 'user123'. Only orders 1 and 3 match this condition, so only those are returned.
Which of the following DynamoDB features allows you to restrict user access to specific items based on their attributes?
Think about how AWS IAM can control access based on item content.
IAM policies with condition keys like dynamodb:LeadingKeys allow fine-grained access control by restricting access to items with specific partition key values.
Given a DynamoDB table with partition key UserID, which IAM policy snippet correctly enforces fine-grained access control so that users can only access their own items?
Look for the condition that matches the partition key to the user's identity dynamically.
Option B uses dynamodb:LeadingKeys with a variable ${aws:username} to restrict access to items where the partition key matches the user's name, enforcing fine-grained access control.
A developer wrote this IAM policy to restrict access to items with UserID matching the user's ID, but users can still access all items:
{
"Effect": "Allow",
"Action": "dynamodb:GetItem",
"Resource": "arn:aws:dynamodb:region:account-id:table/Orders",
"Condition": {
"StringEquals": {
"dynamodb:LeadingKeys": "user123"
}
}
}Why does this policy fail to enforce fine-grained access control?
Consider how the condition value affects different users.
The policy uses a fixed string 'user123' in the condition, so only that user is restricted. Other users do not match this condition and thus have unrestricted access. To enforce fine-grained control, the condition should use a variable like ${aws:username}.
You have a DynamoDB table Documents with items containing DocID, OwnerID, and Role attributes. You want to enforce fine-grained access control so that:
- Owners can read and write their own documents.
- Users with role 'editor' can read all documents but write only their own.
- Users with role 'viewer' can only read documents they own.
Which approach best optimizes this access control using IAM policies?
Think about how IAM policies can use conditions to differentiate roles and ownership.
Option A leverages IAM condition keys to enforce fine-grained access control per role and ownership, optimizing security and minimizing application complexity.