Lesson 15 · Senior platform judgment

Secrets, key handling, and operational blast-radius thinking

How to reason about secret management beyond “we use SOPS,” including where decryption happens, how many key layers exist, and what compromise domains those choices create.

Your win: explain the repo’s secret-handling model as a set of blast-radius decisions instead of a bag of tools, and describe where compromise boundaries really sit.

In plain English Plain English: secrets design is really about deciding who can decrypt what, where, and with what consequences if they are compromised.

Why this page is more about boundaries than tools

Tool names are easy to memorize, which is why weak answers stop there. “We use SOPS.” “We use KMS.” “We encrypt keys.” Those statements are not wrong. They are just incomplete.

The stronger conversation is about boundaries: where is encrypted data stored, who can unwrap it, where does plaintext first appear, and what other layers still apply after that? Once you ask those questions, the system starts to look like an operational boundary map instead of a product list.

The blast-radius rule A secrets design should be explained in terms of decryption boundaries and compromise domains, not just encryption technologies.

Why in-process decryption changes the story

The repo’s model is not “all secrets are decrypted for the service by some outside helper.” The Go process itself loads encrypted config and decrypts it at boot. That means the service process becomes part of the trust boundary in a very direct way.

That does not automatically make the design bad. But it does tell you where plaintext first appears, who needs decrypt capability, and what compromise radius that creates. That is the level of explanation senior interviews are really testing.

Backend use case In this repo, services load encrypted secret files, decrypt them in process through `configs.LoadAll`, and separately use an app-level AES path for some DB-stored private keys under `internal/golibs/crypt/`.

Common mistake Treating the secrets story as if one encryption tool explains every secret boundary in the platform.

Why multiple layers still need one story

This is another place where people drift into checklist answers. SOPS is one layer. KMS is part of how that layer works. The app-level AES path for DB-stored keys is another layer. If you explain them separately without connecting them, your answer sounds fragmented.

The better move is to tell one coherent story: what is protected at rest, what gets unwrapped at boot, and what remains separately protected later in the system.

Follow the decryption boundary, not just the file format

Use the SOPS docs with the repo map so the abstract encryption model stays tied to the actual runtime boundary.

→ SOPS docs
→ Repo toolkit map

Check yourself (from memory)

Q1. What is the most senior way to explain a secrets design?

Boundaries and blast radius are the real story.

Why is “where plaintext first appears” an important security question?

recall, then click to reveal

Because it identifies a real trust boundary. That is where compromise risk becomes operationally meaningful, regardless of how strong encryption was at rest.

Want a “what is the blast radius of this secret-handling choice?” design drill? Ask me.

Sources. SOPS docs; repo toolkit map.