HashiCorp Vault Associate (003) Question 213
Single answer8b Explain the uses of storage backendsA company is deploying Vault for a production application and must choose a storage backend. The security team wants Vault's data such as encrypted values, leases, and configuration to survive Vault restarts and be shared consistently across nodes in an HA deployment. During a design review, an engineer suggests using the file storage backend on each server because "Vault encrypts data before writing it, so any local disk is fine for clustered production use." Which statement best addresses the role and use of storage backends in this scenario?
- A
Storage backends persist Vault's data, so production deployments need a backend that provides durable shared storage or integrated coordination for HA; separate local file backends on each node would not provide a single consistent cluster state.
- B
Storage backends are used only for audit logs, so the choice of backend does not affect Vault's HA behavior or data persistence.
- C
Storage backends store unencrypted secrets, so the file backend is unsuitable for any environment where disk encryption is not enabled.
- D
Storage backends are interchangeable with secrets engines, so using the file backend on each node lets every node generate and manage its own independent secrets safely in the same cluster.
Show answer and explanation
Correct answer: A
Explanation
The key use of a Vault storage backend is to persist Vault's internal data so it survives restarts and can support operational requirements such as HA and recovery. This includes encrypted secret data, leases, tokens, and other cluster state. For production, HashiCorp guidance emphasizes choosing a backend appropriate for durability and HA rather than treating storage as just local disk on each node. The file backend can be useful in development or simpler single-node cases, but using separate local file storage on multiple nodes does not provide a shared cluster state. Also, storage backends are distinct from audit devices and secrets engines: audit devices record activity, secrets engines provide secret-management functionality, and the storage backend persists Vault's internal state. These distinctions are central to understanding how to design a reliable Vault deployment.
- A. Correct.
Correct. A Vault storage backend is where Vault persists its core data, including encrypted secret data, leases, auth data, and configuration/state needed by the cluster. In production, the backend must support durability and, for HA, a consistent shared view of data or integrated mechanisms that allow nodes to coordinate correctly. Running separate local file storage on each node would create isolated data stores rather than one shared Vault cluster state.
- B. Incorrect.
Incorrect. This confuses storage backends with audit devices. Audit devices handle logging of Vault requests and responses, while storage backends persist Vault's operational data. The storage choice directly affects durability, recovery, and HA design.
- C. Incorrect.
Incorrect. Vault's storage backend does not store plaintext secrets by default; Vault encrypts data before writing it to storage using its barrier encryption model. Someone might pick this option because they know disk security matters, but the statement is wrong because it misunderstands what Vault writes to storage and overstates a limitation of the file backend.
- D. Incorrect.
Incorrect. Secrets engines are components that generate, store, or manage secrets for clients; they are not the same as storage backends. Storage backends persist Vault's internal data. Using separate file backends per node would not create a healthy shared cluster; it would create disconnected Vault instances with different states.