How to enable cross-account DynamoDB access from EC2?

DVA-C02 By islever Editorial Last updated Aug 5, 2026

Short answer

AD Allow the EC2 IAM role the permission to assume the AccessPII role. Include the AssumeRole API operation in the application code logic to obtain temporary credentials to access the PII table.

Question

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. Correct 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. Correct Answer
Include the GetSessionToken API operation in the application code logic to obtain temporary credentials to access the PII table.

Key Takeaways

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.

Common mistake: 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.

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

These links open the official vendor documentation in a new tab.

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.

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.

Discussion 5 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 5

trungtd 👍 5

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
jerry118118 👍 2

a public discussion thread on this question
komorebi 👍 2

The correct answer to ChetGPT is B, D
65703c1 👍 3

AD is the correct answer.
koltysh 👍 1

a d answer

Reader comments & corrections

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

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