HashiCorp Vault Associate (003) Question 239
Single answer9a Describe the Vault AgentA platform team is deploying a legacy application on virtual machines. The application cannot call Vault APIs directly, but it needs a database username and password from Vault at startup. The team also wants to avoid storing a long-lived Vault token on disk. Which approach best uses Vault Agent to meet these requirements?
- A
Run Vault Agent with auto-auth and a template stanza so it authenticates to Vault, obtains and renews a token, and renders the database secret to a local file for the application to read.
- B
Run Vault Agent only as a TCP load balancer in front of Vault so the application can connect without any code changes and receive secrets automatically.
- C
Configure Vault Agent to permanently store the root token on disk and pass that token to the application as an environment variable.
- D
Use Vault Agent to replicate the entire Vault data store onto the VM so the application can read secrets locally even if Vault is unavailable.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Vault Agent with auto-auth and templating. This is a practical pattern for legacy applications that cannot authenticate to Vault or call its API directly. Vault Agent can authenticate on behalf of the workload using an auth method such as AppRole, AWS, Kubernetes, or others, then manage the token and render secret values into files the application already knows how to read. This reduces operational risk by avoiding hardcoded or long-lived tokens.
From a Vault Associate perspective, candidates should recognize Vault Agent as a client-side helper process, not a replacement for Vault server. Its core capabilities include auto-auth, template rendering, and in some deployments caching/listener functionality. It does not replicate Vault storage and should not be used to distribute root credentials. These behaviors are consistent with HashiCorp documentation for Vault Agent, especially the Auto-Auth and Template features, and with Vault security best practices around short-lived credentials and least privilege.
- A. Correct.
Correct. Vault Agent is commonly used when an application cannot integrate directly with Vault. With auto-auth, the agent can authenticate using a supported auth method and manage the resulting token lifecycle, including renewal when applicable. With the template feature, the agent can render secrets to local files using Consul Template-style syntax, allowing a legacy application to consume secrets from the filesystem instead of calling the Vault API. This also avoids manually placing a long-lived token on disk.
- B. Incorrect.
Incorrect. Vault Agent is not a generic TCP load balancer that automatically injects secrets into applications. While Vault Agent can provide local helper functionality such as auto-auth, templating, and caching/listener modes, simply putting it in front of Vault as a network proxy does not by itself solve the application's inability to call the Vault API or read and render secrets automatically.
- C. Incorrect.
Incorrect. Storing a root token on disk is a serious security anti-pattern and not a recommended use of Vault Agent. Vault best practices strongly discourage use of the root token for applications. Vault Agent is specifically valuable because it can acquire tokens through auto-auth so applications do not need embedded, long-lived, highly privileged credentials.
- D. Incorrect.
Incorrect. Vault Agent does not replicate Vault's storage backend or create a full local copy of Vault data. It can cache responses in some modes and render secrets locally, but it is not a replication mechanism for the Vault data store.