How to enable cross-account DynamoDB access from EC2?

A company stores all personally identifiable information (PII) in an Amazon DynamoDB table named PII in Account A. Developers are working on an application that is running on Amazon EC2 instances in Account B. The application in Account B requires access to the PII table. An administrator in Account A creates an IAM role named AccessPII that has permission to access the PII table. The administrator also creates a trust policy that specifies Account B as a principal that can assume the role. Which combination of steps should the developers take in Account B to allow their application to access the PII table? (Choose two.)

Allow the EC2 IAM role the permission to assume the AccessPII role. Source Reference Answer
Allow the EC2 IAM role the permission to access the PII table.
Include the AWS API in the application code logic to obtain temporary credentials from the EC2 IAM role to access the PII table.
Include the AssumeRole API operation in the application code logic to obtain temporary credentials to access the PII table. Source Reference Answer
Include the GetSessionToken API operation in the application code logic to obtain temporary credentials to access the PII table.

Community Votes

85%

15%

85% of anonymous learners picked answer AD. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

Cross-account access requires a chain of trust: the source account's role needs sts:AssumeRole permission, and the application code must actively invoke the AssumeRole API to switch contexts.

This question tests the implementation of cross-account access using IAM roles and STS AssumeRole. The consensus among candidates is that the EC2 instance role must have permission to assume the target role, and the application must explicitly call the AssumeRole API to obtain temporary credentials.

Many candidates choose B and D, mistakenly believing that granting direct DynamoDB permissions to the EC2 role is sufficient. However, without assuming the cross-account role, the EC2 role's permissions are confined to Account B and cannot access resources in Account A.

Community Discussion (5 comments)

trungtd 👍 5 Selected: AD

AssumeRole -- Returns a set of temporary security credentials that you can use to access AWS resources. -- These temporary credentials consist of an access key ID, a secret access key, and a security token. -- Typically, you use AssumeRole within your account or for cross-account access. https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

65703c1 👍 3 Selected: AD

AD is the correct answer.

jerry118118 👍 2 Selected: AD

https://www.examtopics.com/discussions/amazon/view/96243-exam-aws-certified-developer-associate-topic-1-question-434/

koltysh 👍 1 Selected: AD

a d answer

komorebi 👍 2 Selected: BD

The correct answer to ChetGPT is B, D

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Understanding Cross-Account Access with IAM Roles

To allow an application in Account B to access a DynamoDB table in Account A, a specific sequence of IAM configurations and API calls is required. This scenario is a classic example of cross-account delegation using AWS Security Token Service (STS).

Why Option A is Correct

The first step is to grant the EC2 instance's IAM role (in Account B) the permission to assume the AccessPII role in Account A. This is done by attaching an inline or managed policy to the EC2 role that allows the sts:AssumeRole action on the ARN of the AccessPII role. Without this permission, the EC2 instance has no authority to request temporary credentials for the cross-account role.

Why Option D is Correct

The second step is for the application code running on the EC2 instance to explicitly call the AssumeRole API operation. This API call returns a set of temporary security credentials (access key, secret key, and session token) that represent the AccessPII role. The application must then use these temporary credentials to sign its requests to the DynamoDB table in Account A. The AWS SDKs provide built-in support for this pattern, often through credential provider chains.

Why the Other Options are Incorrect

Option B is incorrect because granting the EC2 role direct permission to access the PII table is futile. The table exists in Account A, and an IAM policy in Account B cannot grant permissions to resources in another account. Permissions must be granted by the resource owner (Account A) via the AccessPII role.
Option C is a distractor. There is no specific "AWS API" to obtain credentials from an EC2 role in this context. The EC2 instance metadata service provides credentials for the instance's own role, but to access cross-account resources, the application must use STS to assume the target role.
Option E is incorrect because the GetSessionToken API is used to get temporary credentials for an existing IAM user, typically for MFA-protected sessions. It is not designed for cross-account role assumption.

Official Reference

Exam Strategy

When you see a cross-account access question, immediately look for the combination of 'permission to assume the role' (sts:AssumeRole) and the 'AssumeRole API call'. Direct resource permissions in the source account are almost always a trap.

Related Analysis

Practice All DVA-C02 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DVA-C02 Practice Test →

← Back to DVA-C02 Study Guide