VA-003 Compare and configure secrets engines Practice Question
A multi-national company uses Vault's AWS secrets engine to manage access to multiple AWS accounts. They have a central Vault cluster and need to generate IAM users in account A that assume a role in account B for cross-account access. The team has configured the AWS secrets engine with the root credentials of account A. They created a role on the engine that should generate STS credentials for the cross-account role. However, when they try to generate credentials, Vault returns an error: 'AccessDenied: User: arn:aws:iam::<accountA>:user/vault-user is not authorized to perform: STS:AssumeRole on resource: arn:aws:iam::<accountB>:role/CrossAccountRole'. What additional configuration is required?
⚠ Common exam trap
HashiCorp often tests the misconception that configuring the AWS secrets engine role with the cross-account role ARN is sufficient, when in fact the underlying IAM permissions for the Vault user must also be explicitly granted.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Attach an IAM policy to the Vault user in account A that allows sts:AssumeRole on the cross-account role ARN.
The error indicates that the Vault user in account A lacks the IAM permission to call sts:AssumeRole on the cross-account role in account B. Even though the AWS secrets engine is configured with root credentials of account A, the engine uses those credentials to make API calls on behalf of the Vault user. Therefore, you must attach an IAM policy to the Vault user in account A that explicitly allows sts:AssumeRole on the target role ARN in account B. This is a prerequisite for cross-account access via STS.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a new role in the AWS secrets engine that uses the cross-account role ARN directly.
Why it's wrong here
The role configuration in Vault defines which role to assume, but the underlying IAM user still needs permissions.
- ✗
Change the AWS secrets engine mount path to avoid conflicts.
Why it's wrong here
Mount path is irrelevant to IAM permissions.
- ✗
Set up AWS federation with SAML to allow cross-account access.
Why it's wrong here
Federation is a different mechanism; the secrets engine uses IAM users/roles, not SAML.
- ✓
Attach an IAM policy to the Vault user in account A that allows sts:AssumeRole on the cross-account role ARN.
Why this is correct
The Vault user needs explicit permission to assume the target role.
Go deeper
Related to this question
About these practice questions
One of 498 original VA-003 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This VA-003 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the VA-003 exam.