HashiCorp Vault Associate (003) Question 240
Single answer9b Describe the Vault Secrets OperatorA platform team runs applications in Kubernetes and wants pods to consume database credentials from HashiCorp Vault without modifying application code to call the Vault API directly. The team also wants the credentials exposed to the application as native Kubernetes Secrets that can be refreshed when the Vault value changes. Which solution best fits this requirement?
- A
Deploy the Vault Secrets Operator to watch custom resources in the cluster and sync values from Vault into Kubernetes Secrets
- B
Use only the Vault Agent Injector, which writes rendered secrets to a shared volume and automatically converts them into Kubernetes Secret objects
- C
Enable the Kubernetes auth method in Vault and let kubelet retrieve secrets directly from Vault as environment variables
- D
Configure a Vault replication secondary cluster in Kubernetes so applications can read secrets locally as standard Kubernetes Secrets
Show answer and explanation
Correct answer: A
Explanation
This scenario tests understanding of what the Vault Secrets Operator does in practice. The operator is a Kubernetes-native integration that syncs data from Vault into Kubernetes Secrets based on custom resources, making it useful when applications expect standard Kubernetes Secret consumption patterns and should not be rewritten to call Vault directly. By contrast, Vault Agent Injector focuses on injecting Vault-aware sidecars/init containers and rendering secrets to files, while the Kubernetes auth method is an authentication mechanism rather than a secret synchronization solution. Vault documentation and Kubernetes integration guidance distinguish these patterns clearly: choose Vault Secrets Operator when the goal is syncing Vault-managed data into Kubernetes Secret resources, and choose Agent Injector when applications can consume secrets from files rendered into the pod.
- A. Correct.
Correct. The Vault Secrets Operator is designed for Kubernetes environments where teams want secrets from Vault synchronized into native Kubernetes Secret objects. It watches operator custom resources, authenticates to Vault, reads the requested data, and writes or updates Kubernetes Secrets so workloads can consume them through normal Kubernetes mechanisms such as environment variables or mounted secrets. This is the best fit when applications should not be changed to call Vault directly.
- B. Incorrect.
Incorrect. The Vault Agent Injector is a different integration pattern. It injects a sidecar or init container and commonly renders secrets to a file in a shared volume for the application. It does not primarily sync Vault values into Kubernetes Secret objects, so it does not satisfy the requirement to expose the data as native Kubernetes Secrets.
- C. Incorrect.
Incorrect. Enabling the Kubernetes auth method allows workloads or components to authenticate to Vault using service account tokens, but kubelet does not natively retrieve Vault secrets and turn them into environment variables on its own. Authentication is only one part of the solution and does not provide the operator-style synchronization described in the scenario.
- D. Incorrect.
Incorrect. Vault replication is for Vault cluster topology and data replication between Vault clusters, not for presenting secrets to applications as Kubernetes Secret objects. A secondary cluster may improve locality or resilience for Vault itself, but it does not solve the requirement to sync secrets into Kubernetes.