A company has a multi-account environment. Account A has a production application that is hosted on an Amazon EC2 instance. The application needs to query data in an Amazon DynamoDB table that is…

Question

Options

• AUpdate the IAM policy that is attached to the EC2 instance's IAM role to allow the
• BIn Account B, create an IAM role that has permission to query the DynamoDB table. Add the EC2
• CUpdate the IAM policy that is attached to the EC2 instance's IAM role to allow the
• DIn Account B, create a static IAM key that has the appropriate permissions to query the

• A
  8% (2)
• B
  58% (15)
• C
  23% (6)
• D
  12% (3)

Explanation

Option B is correct because cross-account access to DynamoDB requires IAM role assumption: you create a role in Account B that trusts Account A's EC2 IAM role as a principal, then the EC2 instance calls sts:AssumeRole to temporarily acquire permissions in Account B - no long-lived credentials ever leave Account B.

Options A and C are wrong because simply updating the EC2 instance's IAM policy in Account A cannot grant access to resources owned by Account B - DynamoDB does not support resource-based policies (unlike S3), so the trust relationship must be established via a role in Account B that explicitly allows Account A to assume it.

Option D is the least secure approach: static IAM access keys are long-lived credentials that can be accidentally committed to code, leaked in logs, or stolen - AWS explicitly recommends roles over access keys whenever possible.

Memory tip: Think "the resource's account owns the trust." When accessing a resource cross-account, always create the IAM role in the account that owns the resource (Account B), then point its trust policy at the entity in the other account (Account A's EC2 role). Static keys = bad, role assumption = good.

No community discussion yet for this question.