‹ All SAP-C02 questions

SAP-C02 Practice Question 26: Multi Tenant DynamoDB Isolation

AWS Certified Solutions Architect – Professional (SAP-C02) · Test 3 · question 6 of 10

Design for New Solutionshard

A SaaS company stores data for 9,000 tenants in a single pooled Amazon DynamoDB table whose partition key is tenantId and whose sort key is recordId. Mobile clients authenticate against an Amazon Cognito user pool that issues a tenantId claim, exchange the token at a Cognito identity pool, and call DynamoDB directly with the resulting temporary credentials.

A penetration test found that a crafted request could return another tenant's records, because the tenant filter was applied in client code. The remediation must guarantee that a request carrying tenant A's credentials cannot read or write an item belonging to tenant B even if every line of client code is wrong or hostile. Creating a table per tenant has been rejected on cost and quota grounds, and the team wants the control enforced by AWS rather than by code it has to maintain.

Which approach meets the requirement?

Select one answer
Show answer and explanation

Answer:

  • C. Have the identity pool assume an IAM role whose policy allows the item-level DynamoDB actions on the table with a ForAllValues:StringEquals condition on dynamodb:LeadingKeys matching the tenant identifier, and that does not grant dynamodb:Scan

dynamodb:LeadingKeys is DynamoDB's fine-grained access control condition key for the partition key. With a ForAllValues:StringEquals condition on it (populated from a policy substitution variable carrying the caller's identity) IAM itself rejects any GetItem, Query, PutItem, UpdateItem, DeleteItem, or batch request whose partition key is not the caller's tenant. The check happens in the authorization layer, before DynamoDB touches an item, so a bug or a hand-crafted request in the client changes nothing. Omitting dynamodb:Scan matters and AWS calls it out explicitly: Scan returns items regardless of the leading keys, so granting it would open a path around the condition.

Option A is better than the current code but is still the company's own code enforcing the boundary, which is what the remediation says it wants to stop relying on. It also adds a hop to every request and, if the prefixing logic has a defect, tenants leak again.

Option B does enforce isolation in IAM, but the stem rejects table-per-tenant, and at 9,000 tenants it collides with per-account table quotas and multiplies the operational surface of backups, alarms, and capacity.

Option D protects data at rest, not queries. DynamoDB encrypts a table with one key, not per item, so there is no per-tenant key to scope; even if there were, a Query returning another tenant's plaintext-visible key attributes is already a data leak.

Reference: Using IAM policy conditions for fine-grained access control

Practice Test 3 ›

Study guides for SAP-C02