VA-003 Compare and configure secrets engines Practice Question
A company wants to use Vault to generate IAM users dynamically for each application, following the principle of least privilege. Which secrets engine configuration should they use?
⚠ Common exam trap
HashiCorp often tests the distinction between dynamic user creation ('iam_user') and temporary credential generation ('federation_token' or 'assumed_role'), where candidates mistakenly choose 'assumed_role' because it is commonly used for temporary access, but it does not create per-application IAM users for granular isolation.
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
✓
Enable AWS engine with a dedicated IAM user (limited permissions) and use 'iam_user' credential type
The AWS secrets engine can be configured with a dedicated IAM user that has limited permissions, and by using the 'iam_user' credential type, Vault dynamically creates a new IAM user for each application. This approach adheres to the principle of least privilege by ensuring each application gets a unique set of credentials scoped to its specific needs, without sharing or reusing static keys.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Enable AWS engine with a dedicated IAM user (limited permissions) and use 'iam_user' credential type
Why this is correct
The AWS engine's iam_user credential type creates a distinct IAM user per request, with permissions bounded by the role's policy. Pairing it with a limited-permission IAM user for the engine enforces least privilege for each application.
- ✗
Enable AWS engine with a root IAM user and use 'federation_token' credential type
Why it's wrong here
The federation_token type issues temporary STS tokens tied to an existing IAM user, so Vault cannot create per-application IAM users with scoped policies. It suits federating existing identities into AWS, not dynamic least-privilege user generation, which requires the iam_user credential type.
- ✗
Enable AWS engine with a static access key and use 'iam_user' credential type
Why it's wrong here
A static access key with the iam_user credential type creates IAM users, but the keys are long-lived and shared, contradicting dynamic, least-privilege generation. Static keys suit a fixed integration where credentials are rotated manually rather than issued per application instance.
- ✗
Enable AWS engine with an IAM role and use 'assumed_role' credential type
Why it's wrong here
assumed_role returns temporary STS credentials inheriting the role's full permissions, not distinct IAM users per application, so least-privilege scoping per app is unachievable. It fits granting Vault workloads role-based AWS access, whereas the question demands dynamically generated IAM users.
Go deeper
Related to this question
About these practice questions
Courseiva writes every VA-003 question from scratch — 366 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.