Examkin

Question

Difficulty: MediumIdentity and Access Management (IAM)

An enterprise is building an application that stores sensitive customer metadata in a shared Amazon DynamoDB table. The design requires strict tenant isolation, ensuring that users from one tenant cannot view or modify the metadata of another tenant. All client authentication is managed by an external identity provider (IdP) federated with AWS, which supplies a custom tenant identifier during the login process. The application must leverage AWS Identity and Access Management (IAM) to enforce this tenant separation dynamically at the database level.

Which design strategy should the solutions architect implement to meet these requirements securely with the least administrative overhead?

  1. A
    Allow federated sessions to assume the AWS account root user credentials, and write dynamic session policies to restrict database operations by the tenant partition key.
  2. B
    Create individual IAM users for each federated client user inside the AWS account, and attach custom policies that restrict access to their respective tenant partition key.
  3. Implement an IAM policy for the application execution role that uses a condition block matching the dynamodb:LeadingKeys condition key with the federated user's tenant tag variable.Answer
  4. D
    Store the database access credentials for each tenant as a plaintext string in Systems Manager Parameter Store, and configure the application to retrieve these parameters to authenticate requests.

Answer

Implement an IAM policy for the application execution role that uses a condition block matching the dynamodb:LeadingKeys condition key with the federated user's tenant tag variable.
The correct strategy uses IAM policy variables to achieve fine-grained access control. By matching the dynamodb:LeadingKeys condition key with the federated session's principal tag (${aws:PrincipalTag/TenantID}), IAM dynamically verifies that the user can only read or write items whose partition key matches their tenant ID. This enforces strict logical tenant isolation within a single DynamoDB table without managing individual credentials or multiple database tables.

Step-by-Step Solution

1
Map the federated identity attributes to user tags in AWS STS when clients assume the role.
The tenant identifier is securely passed to the AWS session as a principal tag, accessible via the variable ${aws:PrincipalTag/TenantID}.
This establishes a dynamic session variable that uniquely and securely identifies the tenant context for each request.
2
Configure the DynamoDB table to use the tenant identifier as the partition key for all items.
Items belonging to a specific tenant are logically grouped under that tenant's partition key.
This structural requirement enables fine-grained access control using DynamoDB policy conditions.
3
Attach a policy to the application role with a condition statement that checks 'dynamodb:LeadingKeys' against '${aws:PrincipalTag/TenantID}'.
IAM dynamically enforces that any query, put, or delete operation on the DynamoDB table only targets partition keys matching the authenticated tenant tag.
This enforces the required isolation at the database level with minimal latency and no administrative overhead of managing separate users or credentials.

Key Concept

Fine-Grained Access Control in Amazon DynamoDB using IAM Policy Variables and Principal Tags
Estimated Time:2m 0s
Rate this question

Topics

Identity and Access Management (IAM)

More questions from this topic