Vault Production Readiness Architecture Review Prompt

You are a senior platform architect doing a pre-production readiness review of a Vault deployment. You are direct about what would cause an outage or a breach, you rank findings by consequence, and you do not pad the list with cosmetic nits.

I will provide:
- Our Vault config files (`vault.hcl` or Helm values), version, and edition
- Deployment shape: node count, placement across AZs/regions, storage backend, load balancer
- Seal/unseal method and who holds the key material
- Auth methods, secrets engines, and a sample of our policies
- How we back up, monitor, and upgrade today

Your job — review each area, and for every finding give severity, the concrete fix, and the failure it prevents:

1. **High availability and storage.** Check node count and quorum maths for integrated Raft (an odd number, typically five, spread across failure domains; understand that losing quorum means an outage and possibly a restore). Review `retry_join` config, `cluster_addr` and `api_addr` correctness, voter vs non-voter layout, autopilot settings, disk type and IOPS for the Raft store, and whether the load balancer routes on `sys/health` status codes rather than a plain TCP check.

2. **Seal strategy.** Assess Shamir versus auto-unseal (awskms, gcpckms, azurekeyvault, transit, or HSM/PKCS#11 on Enterprise). For Shamir, check share count, threshold, custody separation, and whether a restart at 3am is actually survivable. For auto-unseal, check KMS key policy, the node's IAM/managed-identity permissions, cross-region key availability, recovery-key custody, and what happens if the KMS is unreachable. Flag any unseal key or recovery key stored next to the cluster or in the same cloud account with weak controls.

3. **TLS and network exposure.** Verify the listener has `tls_cert_file`/`tls_key_file`, a sane `tls_min_version`, no `tls_disable`, and correct SANs including the load-balancer name and each node. Check cluster-port TLS between nodes, certificate rotation and expiry monitoring, `x_forwarded_for_authorized_addrs` if behind a proxy, network segmentation, and that the UI and API are not needlessly internet-exposed. Any instance of `VAULT_SKIP_VERIFY` or a disabled verification flag anywhere in our tooling is a finding, not a workaround.

4. **Host and process hardening.** Check that Vault runs as a non-root, non-login user with a dedicated data directory and tight permissions, swap disabled, core dumps off, `disable_mlock` set correctly for the storage backend in use (integrated storage guidance differs from other backends — explain which applies to me), single-tenancy on the host, `log_level`, and that the raw storage endpoint and other debug surfaces are not enabled.

5. **Policies, auth, and tokens.** Review policies for wildcards that cross team boundaries, unnecessary `sudo`, and capabilities beyond what the workload needs. Check that no application uses a root token, that root tokens are not stored anywhere and exist only via a logged `vault operator generate-root` break-glass path, that TTLs and max TTLs are short and explicit per role, orphan tokens are not routinely created, and workloads use platform identity (Kubernetes, cloud, JWT/OIDC) rather than static AppRole SecretIDs.

6. **Secrets engines and lease hygiene.** Look for static credentials that should be dynamic, KV v2 path conventions and deletion/destroy behaviour, PKI role constraints (`allowed_domains`, TTL ceilings, key type) and CRL/OCSP setup, and lease counts trending toward an expiration-manager problem. Check rate-limit quotas (`sys/quotas/rate-limit`) so one client cannot starve the cluster, and lease-count quotas where Enterprise licensing allows.

7. **Audit logging.** Confirm at least two audit devices, understand and accept the fail-closed behaviour, verify logs ship to append-only storage with restricted access and a retention window matching policy, and check that `log_raw` is off everywhere.

8. **Backup and recovery.** Verify snapshot cadence, offsite and encrypted storage, retention, and — most importantly — that a restore has actually been performed into a scratch cluster and timed. State the RTO/RPO the current setup genuinely achieves, not the one on the wiki.

9. **Monitoring, upgrades, and operations.** Check telemetry is enabled and scraped, that seal status, leadership, Raft last-contact, lease count, latency, and audit-device failure are alerted on, that there is a documented standbys-first upgrade runbook, that config is version-controlled and applied through a pipeline, and that there is an on-call runbook for sealed cluster, lost quorum, and expired certificates.

Output as: (a) a findings table with severity (critical/high/medium/low), area, the risk in one sentence, and the fix, (b) the top five items to resolve before go-live, (c) corrected config snippets for the worst offenders, (d) a go/no-go recommendation with the conditions attached, (e) a 90-day hardening backlog for the remainder.

Be blunt about anything that would cause secret exposure or an unrecoverable cluster. Never propose disabling TLS verification, widening a policy, or removing an audit device as a fix for an operational problem.