DVA-C02 Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The identity pool is not configured to use the authenticated role.

  Why it's wrong here

  If the identity pool were not configured, the app would likely fail to obtain any credentials entirely, but the question states the developer set up the identity pool with an authenticated role, so this is not the most likely cause.

• ✗

  The app is not passing the correct identity ID.

  Why it's wrong here

  The AWS SDKs for mobile and web applications are designed to automatically manage the identity ID lifecycle after a user successfully authenticates with Amazon Cognito User Pools. The application code typically does not need to explicitly pass or handle the identity ID directly to obtain temporary AWS credentials. If the identity ID were incorrect or invalid, the application would likely fail to acquire any temporary credentials from Cognito Identity Pools at all, rather than successfully signing in but then encountering permission denied errors for subsequent operations.

• ✓

  The IAM role's trust policy does not allow Cognito to assume it.

  Why this is correct

  The trust policy of an IAM role explicitly defines which entities are permitted to assume that role. For Amazon Cognito Identity Pools to issue temporary AWS credentials to an authenticated user, the IAM role associated with the authenticated identity must have a trust policy that grants the Cognito Identity service principal (cognito-identity.amazonaws.com) the sts:AssumeRole permission. Without this crucial trust relationship, Cognito cannot generate the necessary temporary credentials, leading to 'Access Denied' errors when the application attempts to interact with other AWS services, regardless of the permissions policy attached to the role.

• ✗

  The DynamoDB table is encrypted with a different KMS key.

  Why it's wrong here

  While DynamoDB tables can indeed be encrypted with customer-managed KMS keys, requiring the IAM role to possess `kms:Decrypt` permissions for that specific key, this is a secondary permissions concern. The scenario describes users being signed in but unable to perform *any* operations, which points to a more fundamental failure in obtaining valid AWS credentials with the necessary permissions in the first place. A KMS key issue would typically manifest as specific decryption failures when accessing the table, not a general inability to interact with the service at all, especially if the table uses default AWS-owned or AWS-managed keys.