HashiCorp Vault Associate (003) Question 235
Single answer9a Describe the Vault AgentA team is deploying a legacy application on several virtual machines. The application cannot authenticate to Vault directly and cannot renew tokens by itself, but it can read a local file and make HTTP requests to localhost. The security team wants to avoid storing a long-lived Vault token on disk while still allowing the application to receive short-lived database credentials and TLS certificates. Which Vault Agent capability best fits this requirement?
- A
Run Vault Agent with auto-auth and template rendering so it can authenticate to Vault, manage the client token lifecycle, and write secrets to local files for the application
- B
Use Vault Agent only as a storage backend so the application can read secrets directly from the Agent's local cache without any Vault authentication
- C
Configure Vault Agent to replace Vault policies by enforcing authorization decisions locally on behalf of the Vault server
- D
Use Vault Agent to generate root tokens locally and distribute them to the application whenever database credentials expire
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Vault Agent with auto-auth and template rendering. Vault Agent is designed to help applications that cannot easily integrate with Vault directly. In practice, Agent can authenticate using a configured auth method, sink or hold the resulting token, renew the token when appropriate, and render secrets to local files using templates. This is especially useful for legacy applications that can consume files but cannot perform Vault login flows or token renewal themselves. Vault Agent can also act as a local proxy and support caching, but it does not replace Vault's core security controls, policy evaluation, or token creation workflows. HashiCorp documentation describes Vault Agent as a client daemon that can perform auto-auth, caching, and template rendering to simplify secret delivery to applications while reducing reliance on manually managed long-lived tokens.
- A. Correct.
Correct. Vault Agent is commonly used in exactly this scenario: it can use auto-auth to authenticate to Vault using a supported auth method, obtain a token, and manage token renewal where possible. With the template feature, it can render secrets such as dynamic database credentials or PKI-issued certificates to local files that the application can read. This helps avoid embedding long-lived Vault tokens in the application or storing them manually on disk.
- B. Incorrect.
Incorrect. Vault Agent is not a storage backend for Vault, and its cache does not eliminate the need for Vault authentication. Agent caching can reduce load and reuse leased responses in some scenarios, but it does not let an application bypass Vault's authentication and authorization model altogether. A common misconception is that the cache is a standalone secret store.
- C. Incorrect.
Incorrect. Vault Agent does not replace Vault policies or make independent authorization decisions. Authorization is still enforced by Vault based on the authenticated identity and attached policies. The Agent is a client-side helper for authentication, caching, API proxying, and templating, not a policy engine that substitutes for the Vault server.
- D. Incorrect.
Incorrect. Vault Agent cannot generate root tokens locally for applications. Root tokens are highly privileged administrative credentials created through Vault's controlled processes, not something Agent issues to workloads. This option reflects a dangerous misunderstanding of both Vault security practices and the Agent's role.