# Progressive hints — Follow the evidence

Use one hint at a time. Keep the same private ledger and leave enough time for cleanup.

## Hint 1 — Define healthy before introducing a failure

Does the request verify the CA and hostname? Does its body contain this run's marker? Is each periodic backend/settings combination healthy? A configured resource is not a completed data path.

## Hint 2 — A backend is not only a VM

Application Gateway health belongs to a backend server and its settings/probe combination. Compare the working control settings with the broken exercise settings before changing the VM.

## Hint 3 — Read the actual probe response

The Probe fault requests a file that does not exist. Which path does IIS serve successfully? Does the probe accept only 200? Keeping 404 out of the accepted range preserves its value as a health check.

## Hint 4 — Split certificate trust from certificate identity

A certificate signed by a trusted CA can still be wrong for the expected hostname. Compare the backend settings' name with the leaf certificate SAN. Keep the private address, CA trust and validation settings fixed.

## Hint 5 — A 403 needs a decision source

Is the denial from the managed WAF rules or the independent custom block marker? Find the actual request transaction and all contributing rule rows. Do not infer managed-rule behavior from the custom marker.

## Hint 6 — Scope the exception to the known safe field

Which exact field contains the legitimate documentation snippet? Which managed rules actually matched it? A whole-request Allow rule skips later inspection; a per-rule field exclusion leaves other request fields subject to those rules. This exclusion is on the gateway-associated policy, so it applies to that field across all associated paths. The /docs teaching request does not create a path-specific exception.

## Hint 7 — Prove the boundary survived the repair

Run the same attack-like fixture through a different, nonexcluded parameter. Then run the independent custom block marker. Repair is incomplete if everything becomes allowed.

## Hint 8 — Recovery and deletion need new observations

Send fresh requests after repair; do not reuse an old response. Repeat repair safely. For cleanup, verify exact-resource absence after Azure finishes deletion, then repeat cleanup and compare the protected baseline.