skip to content

Your TLS 1.2 rule passes its tests but listeners still deploy at TLS 1.0 — where do you look?

level: seniorimportance: should knowfreq 52%

answer

  1. first ask whether any evaluation happened
  2. coverage before correctness
  3. a logged deny is not an applied deny
  4. read the recorded input, not the rule
  5. stale facts produce confident wrong answers

basics

~20 s

Split the failure across the three roles. The rule tests clean, so suspect enforcement first — a deploy path with no guard, a verdict received and ignored, a swallowed error — then the input and the facts fed in.

solid answer

~40 s

Treat decide, enforce and inform as three suspects and clear them in order. The rule tests green, so start with the enforcer: is the guard on **every** path that can create a listener, or is there a second tool, a console change or a break-glass script that never calls it? If it did run, look at what it did with the reply — a deny logged and stepped over, an unrecognised response field read as allow, a broad exception handler turning a timeout into `proceed`. Then the input: did the payload carry the listener's minimum protocol version, as submitted rather than as drafted before defaults? Last, the facts: a stale certificate and protocol inventory record can make a non-compliant listener look fine. Prove an evaluation happened at all before assuming anything.

go deeper

for a junior

Know the first question to ask: was the check even run for this resource? Being able to say the rule is not automatically the culprit already puts you ahead.

for a middle

Be ready to describe the three suspects and one concrete failure in each — an uncovered create path, a denial that was logged and ignored, an input missing the field the rule keys on.

for a senior

An interviewer wants an ordered investigation with evidence at each step: find the decision record, partition on its verdict, and say what you would fix and how you would prove the fix on each branch.

for a principal

Own the systemic version: guardrails fail at coverage far more often than at correctness, so argue for continuous reconciliation between resources that exist and decisions that were recorded, and for who is accountable when they disagree.

## A correct rule and a broken control The guardrail is: **no managed load-balancer listener may accept anything below TLS 1.2.** The rule has unit tests, they pass, and yet TLS 1.0 listeners keep appearing. The three-role split turns a vague `the policy is broken` into an ordered list of suspects. ### Step zero: did an evaluation happen for this resource? Before anything else, find the offending listener and look for a corresponding decision record: a call, an input, a verdict, a timestamp. This one lookup partitions the whole investigation. - **No record at all** — the decider was never asked. The fault is in enforcement coverage, and the rule is irrelevant. - **A record with a deny** — it was asked, it said no, and the resource exists anyway. The fault is in how the answer was applied. - **A record with an allow** — the rule was fed something that made TLS 1.0 look acceptable. Now the input and the facts are the suspects. If you cannot answer this question, that is itself the first finding: an enforcer that leaves no trace cannot be debugged and cannot be evidenced. ### Suspect one: enforcement coverage The most common cause of a working rule and a failing control is a path that never reaches the enforcer. - A second deploy tool, an older pipeline, or a team's own script that calls the cloud API directly. - Manual console changes, or a break-glass role used during an incident and never reverted. - The guard placed on the create path but not on the update path, so a compliant listener is created and then modified downward. - The guard behind a feature flag, or skipped in one environment `temporarily`. Enforcement is only as good as its narrowest coverage. One uncovered path is the whole guardrail. ### Suspect two: the enforcer mishandling a real answer If the call happened, examine the code that consumes the reply, not the rule that produced it. Recurring defects: - The verdict is logged and the deploy proceeds — enforcement reduced to telemetry. - The response shape changed (a renamed field, a nested result) and the enforcer's check silently evaluates to `not denied`. - A broad `catch` around the call turns timeouts, TLS failures and parse errors into `proceed`. - A correction was returned and applied to an object that was then discarded, so the original configuration was submitted. - The enforcer checked the drafted object, then defaults were applied afterwards and the submitted object differed from the evaluated one. ### Suspect three: the input and the facts If the recorded verdict was `allow`, read the recorded input against the offending resource. - **Missing field.** If the payload never carried the minimum protocol version, a condition over it does not fire, and the absence of a deny is read as approval. A rule that is silent on missing data is not a rule that passes. - **Wrong object.** The input described a different listener, or a template rather than the rendered result. - **Stale facts.** If the rule consults a certificate and protocol inventory to decide whether an older floor is tolerable for a given certificate, an inventory record that has not been refreshed since the certificate's profile changed will produce a confidently wrong allow. The rule is right, the evaluation is right, the world moved. ### What the frame buys you Each suspect has a different owner, a different fix and a different proof of repair. Coverage gaps are fixed by moving or duplicating the enforcement point and then testing the uncovered path. Answer-handling bugs are fixed in the enforcer and proved by a test that asserts a deny actually aborts. Fact staleness is fixed at the information source or by having the rule refuse to decide on data older than some bound rather than assuming it is current. And it protects you from the reflex that wastes the afternoon: tightening a rule that was already correct.

  • The decision record shows allow, and the recorded input has no protocol field at all. What is the fix?
    Two fixes, and you need both. The enforcer must include the field it is being asked about, or the check is theatre. And the rule should refuse rather than pass when the field it keys on is absent, so a gathering bug surfaces as a loud failure instead of a quiet approval. Then add a case covering the missing-field input so the behaviour is pinned.
  • How would you prove afterwards that no uncovered path remains?
    Stop relying on the enforcer's own logs, which only show paths that reached it. Reconcile from the other side: list the listeners that actually exist, compare them against decision records, and treat any resource with no matching evaluation as an uncovered path. That reconciliation is worth running continuously, not once.
  • Why is a stale facts source a different class of bug from a wrong rule?
    A wrong rule fails reproducibly — the same input always yields the same wrong verdict, and a test pins it. Stale facts fail intermittently and invisibly: the same input yields different verdicts on different days, tests written against fixtures never see it, and the decision looks perfectly reasoned in the record. It is diagnosed by comparing the fact as recorded against the fact as it was at that moment.

saying these in an interview costs you the question

  • Immediately rewrites a rule that already tests green
  • Never checks whether the enforcer was called at all
  • Assumes one enforcement point covers every path
  • Treats a logged denial as a blocked deploy
  • Ignores the age of facts pulled from an inventory

context

resolving links…