entra1-10  Exercise 3: Correcting a Wrong Diagnosis
=========================================================

Source: Course chapters 7 and 8 (decode and confirm in three places) and the
client-communication guidance. Re-check wording before sending.

WHAT WENT WRONG
  We told Fabrikam "the secret expired" before confirming the code. The first
  error may have been 7000222 (expired), or we may have inferred expiry from
  the date without reading the code. After the new secret was created the job
  still fails, now with 7000215 (invalid secret), which means a secret was
  presented that Entra does not accept: most likely the Secret ID was pasted
  instead of the Value, or the value was mistyped, or our system still
  sends an old, removed value. The expiry may have been real, but there is a
  second fault on top of it, and our message treated the problem as finished.

CORRECTION MESSAGE
  "Update on the nightly sync. Earlier we told you the secret had expired,
  and that creating a new one would fix it. We should have confirmed one more
  thing before saying so. The expired secret was real, but the new secret isn't
  yet being accepted: Microsoft's log says the value we are sending isn't
  valid. That usually means the secret ID rather than the secret value was
  entered, or a character was lost when it was copied. Nothing is wrong with
  your tenant. Could your administrator create one more secret and enter its
  value directly into the credential field in our product? We'll check your
  sign-in log together afterwards. Please don't send the value by email or chat.
  We'll update you at 15:00."

PROCESS CHANGES
  1. Do not state a cause until the log, portal and audit log agree on it
     (Chapter 8, step 2). Use "we think" wording until then.
  2. Read the exact AADSTS number each time: 7000222 (expired) and 7000215
     (invalid) are different, and need different questions.
  3. Check what our system actually stores and sends before asking for a
     new credential.
  4. In the plan message, say "we will confirm it works before closing".
  5. Close only after proving a fresh Success in the log (not only "no
     error shown").

EVIDENCE THAT SHOULD HAVE BEEN GATHERED BEFORE MESSAGE ONE (in order)
  1. The exact error text with the AADSTS number and the correlation ID.
  2. The matching service-principal sign-in entry (Status, code, application ID).
  3. Certificates & secrets: which secrets exist, their expiry dates, which one
     our system uses (by description and Key ID).
  4. The audit log for the preceding days: any rotation or removal.
  5. What our product has stored (hint/first characters, date it was set).
  Only then: choose between the four stories, and send the diagnosis.

WHY THIS WORKS AS AN ANSWER
---
It owns the mistake plainly, explains the new evidence in client language,
asks for one specific action and turns the error into a process change.