A build alert gives you a token id, an image digest and a source address — which pivot runs first?

## The twenty-minute problem With a live intruder you do not get to run every pivot. You get one question at a time, and each answer arrives late enough that the choice matters. Interviewers ask this because the wrong instinct — "run them all, see what sticks" — is common and produces a pile of records nobody can reason about. ## Two axes, multiplied **Decision value.** Before choosing, name the decision you are trying to unblock. Usually it is one of: do we widen containment, do we stand this down, or do we escalate to a declaration. Then ask of each candidate pivot: *does the answer, in either direction, change that decision?* A pivot whose every possible result leaves you doing the same thing is not worth twenty minutes no matter how interesting it looks. **Selectivity.** How many things in the estate carry this value? - An **image digest** is a content address: a fixed digest names byte-identical content, so hits are exact and few. "Which other clusters, namespaces or nodes pulled this digest" bounds where the artefact reached. - A **token or session id** is selective when credentials are minted per job, and nearly worthless when one long-lived token serves the whole estate — check which world you are in before betting the clock on it. - A **source address** is the weakest in this environment: ephemeral pod addresses are reassigned, and egress passes through a shared NAT so the address describes the estate, not the actor. Multiply the two. A highly selective pivot whose answer changes nothing loses to a moderately selective one that decides containment. ## Estimate cardinality before you commit Cheap discipline: count the value's frequency over a short window before you pull the full result. If `runner-egress-nat` appears forty thousand times an hour, you have learned in ten seconds that it is a **filter** — something you add to narrow another query — and not a **link**. This one habit prevents most twenty-minute losses. ## Predict the result first Write down what you expect: "I expect this digest to appear only in the `ci` namespace on the two runner nodes; anything outside that widens the incident." Two benefits. A null result becomes evidence — you ruled something out — instead of feeling like wasted time. And you cannot quietly retro-fit the finding to the story you already believed, which is the failure mode where the analyst finds exactly what they went looking for. ## Sequence, do not fan out Run one pivot, read it, choose again. Fanning out three searches at once is tempting because it feels parallel, but the results arrive together and you have no chain of reasoning connecting them — and in a live incident the second pivot should usually be chosen *because* of what the first returned. The exception is a slow query you can start in the background while you run a fast one, which is a scheduling decision, not a strategy. ## Defending a choice that turned out wrong Sometimes the pivot dead-ends and forty minutes are gone. The defence is not that it worked; it is that the reasoning was sound on the information available: - the decision it would have unblocked, and how each possible result mapped to an action; - the expected result you stated in advance; - the cardinality estimate showing it was a link, not a filter; - what the null result *did* rule out. What is not defensible is picking the pivot because it was the easiest query to type, because the tool had a button for it, or because it was the field the alert happened to put first. Those are the answers interviewers listen for. ## The pivot everyone under-values Your own case history. Pivoting an entity through closed alerts and past cases costs seconds and occasionally returns the single most valuable result available — an event a week old that another analyst closed, which the new entity now connects. Cheap, fast, and it changes the decision when it hits, which is exactly the profile the two axes reward.