An auditor asks you to prove the reporting service cannot reach the payments database. What evidence would you produce, and why is a screenshot of the security group not it?

What the interviewer is testing

Whether you understand that reachability is a property of a composition, and a rule is one term in it. A path exists or does not exist depending on route tables, security groups, network ACLs, peering and transit attachments, host firewalls, DNS, mesh policy and credentials together. Showing one layer answers a different question from the one asked.

The second thing being tested is evidence literacy: the difference between what is possible, what happened and what is still true.

The clarifying questions that change the answer

• Does "cannot reach" mean at the network layer, or that a successful connection could not authenticate? The controls and the evidence differ.
• Is the claim point-in-time for an audit date, or a continuing control? A continuing control needs a mechanism, not a document.
• Are administrative paths in scope? A bastion, a break-glass role, a batch job in the same subnet and a support tunnel are all paths, and hiding them is how an audit finding becomes a breach finding.

A strong answer's arc

1. A computed reachability analysis over the live configuration. Cloud providers offer analysers that evaluate the whole path symbolically and return no-path with the reason. This is the only artefact that proves a negative, because a test that fails to connect proves one attempt failed.
2. A continuous negative probe. A job running as the reporting service's own identity attempts the connection on a 60 second interval and alerts if it ever succeeds. That is over 500000 attempts across a year, against the single observation a screenshot provides, because the property the auditor cares about is that it held all year rather than on the day you looked.
3. Flow logs over the audit window showing no accepted flows between the two groups. Evidence of history, not of possibility, and the weakest of the three on its own.
4. Policy as code with a failing test. The rule pair that would permit the path breaks the build, so the property is defended at change time rather than discovered at audit time.

Common weak answers

• "There is no rule allowing it." Says nothing about other paths, and nothing about who can add a rule in five minutes without review.
• "Egress is default deny." Most default-deny estates carry a blanket allowance to a proxy or a NAT device, and that is a path.
• "Nobody has the credentials." Not a network control, and it changes whenever someone rotates a secret into the wrong place.

Decision rule: prefer the analyser for the claim that a path cannot exist, the probe for the claim that it still cannot, and flow logs only to corroborate. Never hand over a rule list, because the question is about the system and a rule list is about one layer of it. Zero-trust guidance published since 2020 makes the same point from the other direction: network position is not an authorisation, so the network evidence has to be paired with the identity evidence.

What a strong answer adds

Name the administrative exception explicitly and put it in the evidence pack with its own monitoring, because an undisclosed break-glass path discovered by an auditor costs far more than a disclosed one. Then state the operating cost honestly: the probe needs the real identity to be meaningful, which means a long-lived test identity that must itself be governed.