A final screenshot can show a result. Troubleshooting notes explain why you believe the correction caused that result.
That is useful evidence of judgment: the observed problem, hypothesis, chosen check, change, and comparable retest.
Keep the record factual. A reviewer doesn't need a long account of frustration or a dramatic outage narrative. They need enough context to follow your reasoning and identify what the evidence does—and doesn't—support.
Start with the exact failure you observed
“SSO was broken” is too broad to support a useful investigation.
A better note identifies the test account, the test application, the action attempted, the time, and the visible result. Use fictional identities and remove sensitive details before publishing.
For example: “The test user completed the identity-provider step, but the application did not establish a session.”
That description doesn't claim a cause. It narrows the behavior you need to explain and makes a later retest comparable.
Record a hypothesis before changing a setting
Write what you think is happening and what evidence would support or challenge it.
You might suspect a mismatch in application configuration. Your next step should inspect the relevant values or error evidence, not change several unrelated settings until the login works.
When the evidence doesn't support the hypothesis, record that too. A short note such as “The expected account was present, so missing provisioning did not explain this result” shows that you eliminated an alternative.
The point is not to document every thought. Preserve the decisions that explain the path you took.
Make each change traceable
For a controlled lab, record what you changed, why, and how to return to the prior state. Keep the scope small enough that the result is interpretable.
A table can help: observation, hypothesis, check, finding, next action.
If you changed multiple variables at once, don't pretend you isolated the cause. Say that the correction restored the behavior but that your first attempt did not establish which change mattered.
Then repeat the exercise more carefully when practical. Honest uncertainty is more useful than a polished but unsupported root-cause statement.
Retest the original failure and the relevant boundary
After a correction, repeat the failed test under comparable conditions. Then check nearby behavior that should remain correct.
For example:
| Scenario | Checks to retain |
|---|---|
| Access-control correction | Intended user can perform the required action; unrelated user remains denied |
| SSO correction | Intended sign-in succeeds; application authorization limits are stated separately |
The final screenshot now supports a result within a sequence, rather than standing alone as proof of a diagnosis.
Use the three test cases for a credible access-control demonstration to decide which observations matter around a permission change.
Don't claim that restoring sign-in validates every application permission. Keep the retest tied to the original requirement, show any relevant boundary, and record what remained outside the investigation. That precision makes the notes worth reading.
Publish the reasoning, not the entire raw log
Your public notes should be readable and safe. Summarize the relevant events, include only necessary excerpts, and redact identifiers or secrets that don't belong in a portfolio.
Don't publish tokens, credentials, customer information, or employer logs. Even a screenshot can contain more than the visible error you intended to show.
Keep a concise narrative above any detailed appendix: expected behavior, observed failure, evidence, correction, and verification.
Someone should be able to understand the conclusion without scrolling through a wall of terminal output.
Use the notes to prepare for interview questions
Practice answering: “Why did you check that first?” and “How did you know the problem was fixed?”
Your notes should help you answer both without inventing a dramatic story. They should also reveal what you would investigate next if the same symptom had a different cause.
That is a stronger demonstration than memorizing a sequence of successful clicks.
The Six-Figure IAM Career Playbook includes practical IAM labs and guidance on turning them into evidence. The $9 guide is designed to connect your learning with a role you can pursue.
Save the final result, but preserve the reasoning that makes the result believable. That's the part another person cannot infer from a screenshot alone.