Lesson 18 · Senior platform judgment
Senior platform add-ons interview questions
High-signal questions about migrations, guardrails, secrets, reliability, delivery, and runtime shape — with answer structures that sound like real platform judgment.
Your win: answer senior platform questions with mechanism + trade-off + repo-grounded consequence, not just a list of tools or practices.
Why these questions feel different from the base course
The base course teaches the toolkit clearly. This page asks something harder: can you defend that toolkit honestly, under pressure, without oversimplifying what it guarantees?
That is why the answer shape matters so much. Strong answers in this section usually do three things in order: name the mechanism, name the trade-off or weakness, and connect it to a concrete repo consequence. That rhythm makes the answer sound lived-in instead of memorized.
How to get the most out of this page
Do not read the table like reference trivia. Use it like answer practice. Cover the right-hand column, say your answer out loud, then compare your structure to the model shape.
If your answer has only mechanism, it sounds junior. If it has mechanism plus trade-off, it sounds better. If it has mechanism plus trade-off plus repo consequence, it starts to sound like real platform judgment.
Question bank
| Question | Best answer shape |
|---|---|
| Why can a fix-forward migration model be defensible? | Because rollback is often messy in live systems, so the team standardizes on additive review and forward corrective motion instead. |
| What makes a safety check a real guardrail? | It must reliably run in the right path and be able to block a bad change, not just exist in the repo. |
| Why is “we use SOPS” an incomplete security answer? | Because the real question is where decryption happens, who can unwrap keys, and what compromise domain that creates. |
| What is the honest difference between outbox and publish-after-commit? | Outbox closes the dual-write gap with stronger durability, while publish-after-commit is cheaper and faster but accepts a crash gap with compensation or caller retry. |
| Why can swallowed push failures still be a rational design choice? | Because avoiding double-push can matter more than aggressive retry semantics in that delivery path. |
| Why is runtime shape worth naming explicitly? | Because a CronJob, a one-off job, and a KEDA-scaled long-running consumer have very different scheduling and failure semantics even if they share one binary. |
| What is the strongest one-line description of the platform build model? | One binary contains many service and job entrypoints, and runtime role is selected by cobra subcommand plus mounted config. |
| What should a senior review ask about a platform add-on design? | What failure it protects against, how strong the protection really is, and where false confidence might remain. |
| Why is a partially-enforced guardrail worth calling out? | Because it can create confidence disproportionate to the actual behavior it constrains. |
| What makes a platform answer sound mature? | Separating guaranteed behavior, recovery behavior, and consciously accepted risk. |
Use the playbook and map together
The senior playbook compresses the judgment layer; the repo map gives you the ground truth that makes answers sound real.
Check yourself (from memory)
Q1. A strong senior platform answer usually includes…
Sources. Repo toolkit map; curated platform-add-ons resources.