Not every secret needs a Vault server

Speaker notes

• Set up the contrast honestly: everything so far in this module (Vault) assumes a team is willing to run and operate real infrastructure. A small team with a GitOps-based deploy pipeline and no dedicated platform engineer often doesn't have that operational capacity yet — SOPS is the answer for that team, not a lesser alternative.
• Explain the actual mechanism, since it's the interesting part: SOPS encrypts a file's values but deliberately leaves its keys and structure in plaintext. This means a git diff on an encrypted secrets file still shows a reviewer *which* key changed — 'yes, DB_PASSWORD was rotated in this PR' — without ever exposing the actual value. A fully-opaque encrypted blob would destroy that reviewability entirely.
• Land the honest comparison as the actual takeaway, not a sales pitch for either tool: SOPS doesn't eliminate the need to protect a credential somewhere — the age private key still has to live in exactly one place (a CI secret, typically). What it does is concentrate that protection into one purpose-built location instead of leaving the real secret value spread across every clone of a git repository that was never designed to be a secrets store. That's a real, meaningful reduction in exposure, worth stating precisely rather than overselling as 'problem solved.'
• If pushed on when to migrate off SOPS toward Vault: the concrete trigger is needing dynamic, auto-expiring, per-instance credentials (this module's earlier slide) or centralized real-time audit of who accessed what — SOPS structurally can't provide either, since its secrets are still static once decrypted.

Deck map