HashiCorp Vault Associate (003) Question 241
Single answer9b Describe the Vault Secrets OperatorA platform team runs applications in Kubernetes and wants pods to consume database credentials stored in HashiCorp Vault without modifying application code to call the Vault API directly. The team also wants Kubernetes Secrets to stay synchronized when the value in Vault changes. Which solution best meets these requirements?
- A
Deploy the Vault Secrets Operator to watch custom resources in the cluster and sync data from Vault into Kubernetes Secrets.
- B
Use the Vault Agent Injector so it automatically updates Kubernetes Secret objects whenever the secret changes in Vault.
- C
Configure Vault replication between clusters so Kubernetes can read the replicated secrets natively as Kubernetes Secrets.
- D
Enable the Kubernetes auth method in Vault and let pods read secrets directly from Vault without any operator or Kubernetes Secret synchronization.
Show answer and explanation
Correct answer: A
Explanation
The key requirement is to let Kubernetes workloads use secrets stored in Vault without changing application code while also maintaining those values as Kubernetes Secret objects. The Vault Secrets Operator addresses this by using Kubernetes custom resources to define desired synchronization from Vault to Kubernetes Secrets and continuously reconciling state. By contrast, the Vault Agent Injector is used to inject secrets into pods, typically as files or environment variables, rather than managing Kubernetes Secret objects. Vault replication is unrelated to Kubernetes Secret synchronization, and the Kubernetes auth method alone only enables authentication from pods to Vault. HashiCorp documentation for the Vault Secrets Operator describes it as a Kubernetes operator for syncing secrets from Vault into Kubernetes-native resources, which is the best match for this scenario.
- A. Correct.
Correct. The Vault Secrets Operator is designed for Kubernetes environments where teams want secrets from Vault represented as native Kubernetes Secret objects. It watches custom resources and reconciles the desired state by reading from Vault and creating or updating Kubernetes Secrets. This is a good fit when applications expect configuration from Kubernetes Secrets and should not be changed to call Vault directly.
- B. Incorrect.
Incorrect. The Vault Agent Injector mutates pod definitions to add a Vault Agent sidecar or init container that authenticates to Vault and renders secrets into files or environment variables for the pod. It does not function as a controller that keeps Kubernetes Secret objects synchronized with Vault values. This option reflects a common confusion between secret injection into pods and secret synchronization into Kubernetes Secrets.
- C. Incorrect.
Incorrect. Vault replication is for replicating Vault data and state between Vault clusters, such as performance or DR replication. It does not convert Vault secrets into Kubernetes Secret resources or provide a mechanism for Kubernetes-native secret synchronization. Someone might choose this if they associate the word 'sync' with replication, but replication solves a different problem.
- D. Incorrect.
Incorrect. Enabling the Kubernetes auth method allows workloads in Kubernetes to authenticate to Vault, and applications can then read secrets directly from Vault. However, the scenario specifically requires avoiding application changes and keeping Kubernetes Secrets synchronized. Direct application access to Vault does not satisfy the requirement to populate and maintain Kubernetes Secret objects.