Components that store, generate or encrypt data, enabled at a path, isolated from each other, tuned per mount, and removed with everything they hold.
Study it
What secrets engines are: mounts, paths, isolation and tuning
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.
Question 1 · choose 1
Two teams' KV engines are enabled at kv-a/ and kv-b/. A reviewer asks whether a faulty or malicious engine at kv-a/ could read kv-b/'s data directly from Vault's storage. What is the answer?
AYes, unless the two mounts use different storage backends
BNo, but only because the teams' policies deny access to each other's paths
CYes, because two mounts of the same engine type share one data root
DNo, because each engine sees storage only through a barrier view rooted at its own random UUID
Show the answer and why
AYes, unless the two mounts use different storage backends
Incorrect
All mounts share one storage backend; isolation comes from the barrier view, not from separate backends.
BNo, but only because the teams' policies deny access to each other's paths
Incorrect
Policies govern clients; the barrier view isolates engines even from each other.
CYes, because two mounts of the same engine type share one data root
Incorrect
Each mount gets its own data root, even for the same type.
DNo, because each engine sees storage only through a barrier view rooted at its own random UUID
Correct
Every mount writes under its own UUID prefix, and the storage layer allows no relative access, so an engine cannot reach other data.
Secrets engines are enabled at paths and isolated to them; the barrier view works like a chroot for each mount.