HashiCorp Vault Associate (003) Question 234
Single answer9 Access management architectureA platform team uses Vault to manage secrets for several internal applications. Developers authenticate to Vault through the userpass auth method, while applications authenticate using AppRole. The security team wants an access management design that follows least privilege, avoids creating separate policies for every individual user, and ensures applications can read only the secrets for their own environment. Which approach best meets these requirements?
- A
Create broad policies that allow access to all application secrets, then rely on developers and applications to use only the paths they need.
- B
Assign policies directly to each individual user and each application token so access can be customized case by case.
- C
Map developers to shared policies based on job function, and create separate AppRoles with environment-specific policies for each application workload.
- D
Use a single AppRole for all applications and control environment access by changing secret path names when applications are deployed.
Show answer and explanation
Correct answer: C
Explanation
Vault access management architecture is built around authentication methods that map identities or workloads to policies. A scalable design separates human and machine access patterns: humans are commonly assigned shared policies based on team or job function, while applications use distinct machine identities such as AppRoles with tightly scoped policies. This reduces policy sprawl, improves auditability, and enforces least privilege. In Vault, policies determine what paths and capabilities a token receives, so environment or application isolation should be implemented through separate roles and policies rather than naming conventions or user discretion. This approach is consistent with HashiCorp guidance on policy-based access control, AppRole usage for machine authentication, and designing access around identities and roles instead of individual ad hoc exceptions.
- A. Incorrect.
This is incorrect because it violates least-privilege design. Granting broad access to all application secrets increases risk if a token is misused or compromised. Vault access management is policy-driven, so the recommended design is to scope capabilities to only the paths required by each identity or workload rather than trusting clients to self-restrict.
- B. Incorrect.
This is incorrect because although it can work technically, it does not scale well and does not align with a role-based access model. Managing policies per individual user or per token creates administrative overhead and policy sprawl. Vault best practices favor attaching reusable policies to auth entities, groups, or roles so access is consistent and easier to audit.
- C. Correct.
This is correct because it uses shared policies for human users based on function and separate machine identities for applications. For developers, grouping access by role supports scalable access management. For applications, using distinct AppRoles with narrowly scoped policies ensures each workload can read only the secrets for its own environment. This aligns with Vault's policy-based authorization model and least-privilege best practices.
- D. Incorrect.
This is incorrect because using one AppRole for all applications weakens isolation between workloads. Secret path naming alone is not an access control mechanism unless backed by distinct policies. If multiple applications share the same AppRole and policy set, compromise of one application's credentials can expose secrets intended for others.