entra1-8  Exercise 3: Run the Method on a Real (or the Fictional) Error
=========================================================

Source: Microsoft Learn error-code reference, credential and renewal pages.
Re-check before relying on any detail.

HOW TO USE THIS EXERCISE WITH YOUR OWN ERROR
  Redact first: replace tenant IDs, client IDs, secret values, names and domain
  names with placeholders (<TENANT>, <CLIENT-ID>, <CLIENT>). Keep the error name,
  the AADSTS number, the trace and correlation structure and the timestamp.
  Then fill the same headings as below. Nothing here needs a real secret.

WORKED ANSWER FOR THE FICTIONAL ERROR
  Error: invalid_client, AADSTS7000215 (invalid client secret provided), two
  hours after the client's administrator created a new secret.

  DECODE
    invalid_client ............ the client (our app) failed to authenticate;
                                it is about the credential, not about a user
    AADSTS7000215 ............. invalid secret: not "expired" (that is 7000222)
    app ID .................... check it is the registration we expect
    correlation / trace ID .... filter the service-principal sign-in log
    timestamp ................. two hours after the new secret was created

  CONFIRM IN THREE PLACES
    Sign-in log: SP sign-in, Failure, 7000215, Credential type: secret.
    Portal: Certificates & secrets lists the NEW secret, with a description
            and an expiry date; the OLD secret is still there (or removed).
    Audit log: "Update application - Certificates and secrets management" two
            hours ago, initiated by the client's administrator.

  WHICH STORY?
    Closest to story 2 (renewed on one side only) with a twist: the new secret
    exists but our product is sending something that is not that secret. Most
    likely: the Secret ID was pasted instead of the Value, or the Value was
    pasted with a stray space or truncated, or our product has not been updated
    at all and is sending a removed/old value. 7000215 (not 7000222) says the
    value does not match any valid secret, which points to a wrong value rather
    than a simply expired one.

  FIX
    1. Do NOT delete anything yet.
    2. Create another secret (the Value of the first may be lost or mistyped),
       description "<system> <date> retry". Copy the Value, not the ID.
    3. The administrator enters the Value directly into our product's credential
       field. Check no stray space; restart/reload.
    4. Prove: a fresh SP sign-in entry with Success; the job runs.
    5. Remove the failed/unused secrets after a safe period; record in the note.

  MESSAGE TO THE CLIENT
    "Thank you for creating the new secret. The error tells us that the value
    we received doesn't match a valid secret in your tenant, which usually
    means the secret ID was entered instead of the secret value, or a character
    was lost in copying. Nothing is wrong with your tenant. Could your
    administrator create one more secret and enter its value straight into the
    credential field of our product? We'll check your sign-in log together
    afterwards. Please don't send us the value by email or chat."

  FIX RECORD
    Cause: invalid secret value supplied after rotation (7000215), not expiry.
    Prevention: add a validation step to our product that checks length/format,
    and a client instruction: "copy the Value column, not the Secret ID".

WHY THIS WORKS AS AN ANSWER
---
It separates "expired" from "invalid", keeps the process the same whichever
story applies, handles the secret safely, and leaves a record that prevents a
repeat.