Home
Vault Enterprise Learning Guide

Unit 11 — Engagement Synthesis

Part of the Vault Enterprise resident architect learning path. Work through the topics in order or use the sidebar to jump directly to a section.

Architecture:

  1. Is this the HVD reference architecture — 6 nodes, 3 AZs, redundancy zones — or a flat all-voter cluster? The failure analysis differs.
  2. What’s your seal mechanism, and who controls the KMS key or HSM? What prevents its deletion?
  3. Do your secondary clusters use a different seal mechanism than the primary?
  4. Do you still have your initial root token?
  5. How many audit devices, of which types, writing where? Have you tested behavior when one blocks?

Namespaces and organization:

  1. What’s your namespace granularity, and how many do you project? (Storage limits and leader election time.)
  2. Is onboarding self-service, or does it go through the platform team’s backlog?

Identity:

  1. How is an identity removed, not just granted? What’s your revocation latency, and what’s your token TTL? (They’re the same question.)
  2. Does the platform each workload runs on issue it a cryptographic identity?

Dynamic secrets:

  1. Is any root credential shared between mounts, or between a secrets engine and an auth method?
  2. When your database fails over, does its connection string change?
  3. What’s your lease budget at peak?

PKI:

  1. Where is your root CA today, and who can sign with it?
  2. Do your clients check CRL or OCSP? Have you verified, or is it assumed?
  3. Do you have a requirement that private keys never leave the host? (Determines sign vs issue, which determines whether Agent templating is viable.)
  4. How does each application learn a new certificate is available?
  5. Who debugs a failed renewal at 3am — platform or application team?

Finding Why it matters Reference
Initial root token still exists Should be revoked after first auth method validated §3.3
One audit device, or two of the same type Blocking failure takes Vault down §3.1
Default token TTL never overridden 32 days; makes deprovisioning SLAs unmeetable §5.5
Root credential shared across mounts Rotating one breaks the others §7.4
CI pipeline fetching secrets for applications Not brokering; violates never-proxy; unattributable compromise §6.7
no_store=true with no LB change The 3–5x gain never materializes §8.5
Namespace-per-application at scale Storage limits and leader election time §4.3
PR without paired DR Orphaned leases on cluster loss §10.7
Auto-unseal with no seal-key protection Cluster unrecoverable if key deleted §2.5
Entity metadata sourced from IdP feeding templated policies 2.0.1 glob restriction §5.4

When a customer’s requirements conflict, name the conflict rather than picking a side. The HSM-plus-throughput case is the canonical example: managed keys add latency outside Vault’s control, and the resolution is the hybrid pattern — HSM for the signing CA where risk concentrates, Vault-managed with seal wrap for issuing CAs where volume lives.

When a customer’s team refuses a capability, look for the documented workflow that removes the need rather than arguing. DBA refuses superuser → rootless static roles. Security refuses private keys on the wire → sign endpoint, no Agent templating.

When a customer reports a product defect, check patch level first, then check whether it’s documented behavior. The Okta SCIM group-removal case is a real 2.0.0 limitation; the external-group-refresh-on-login behavior is not a defect at all.

When advising on delegation, the answer is always three layers: namespace isolation for tenancy, cryptographic constraints where available (PKI name constraints), and Sentinel for what ACLs can’t express. ACLs alone are never sufficient for self-service tenancy.