Example investigation report
What a DiamOps proof report looks like
This is a realistic example of a completed investigation report. The data is simulated. It shows what a recruiter receives when a candidate shares their DiamOps proof.
Account locked after password change
Scenario difficulty: Intermediate · Role path: IT Support
Report ID: DMO-2024-DEMO-001
Completed: 31 May 2026
Session duration: 18 minutes
DEMO REPORTOverall: 4.6 / 6.0
Scored automatically across six operational dimensions. Scores reflect the quality of investigation notes, evidence reviewed, and documentation — not time taken.
5 / 6
Correctly identified the account lockout as authentication-related. Scoped the issue to one user before expanding investigation.
4 / 6
Reviewed sign-in logs and identified the pattern. Did not check audit log for conditional access policy changes.
5 / 6
Notes are clear, structured, and reproducible. Symptom, scope, evidence, and action all recorded. Minor gap: no verification step documented.
5 / 6
Recognised the P2 priority and confirmed with the user within the expected window. Did not note the SLA timer explicitly.
4 / 6
Resolved independently without unnecessary escalation. Could have flagged the pattern to the team as a potential wider issue.
5 / 6
Correctly identified saved credentials as the root cause. Diagnosis matched the embedded scenario root cause.
Scores are generated by DiamOps AI and are indicative. They reflect operational judgment demonstrated in the investigation, not knowledge of the correct answer in advance.
Original ticket
INC-2024-0841
P2 — High
Resolved
Identity & Access
j.harrison (Finance team)
Microsoft 365 sign-in
"Hi IT, I changed my password this morning and now I keep getting locked out every few minutes. I log in fine and then 10 minutes later I'm locked out again. It's been happening since about 9am. Please help urgently — I can't access my email."
How the candidate worked through this
These are the notes written by the candidate during the investigation. They show how the candidate thinks, not just what they did.
Initial assessment: User reports repeated lockouts after a password change. The timing (since 9am, recurring every ~10 minutes) is consistent with a cached credential somewhere repeatedly trying the old password. Starting with the sign-in logs.
Evidence review: Microsoft Entra sign-in logs show failed authentication from j.harrison at 09:03, 09:14, 09:22, 09:31. All failures show error code 50053 (account locked). The authentication source alternates between browser and "Windows credentials" — this suggests a saved Windows credential or an application using stored auth.
Scope check: Confirmed this is isolated to j.harrison only. No other accounts showing similar pattern. Not a wider M365 issue.
Root cause conclusion: The recurring lockouts are caused by saved Windows credentials (Credential Manager) still holding the old password. Every time Windows attempts a background sync (e.g., OneDrive, Outlook), it uses the saved credential, fails, and increments the lockout counter.
Resolution steps taken: (1) Unlocked the account in Entra admin. (2) Guided user to Windows Credential Manager and removed the saved credential for their M365 account. (3) Asked user to re-authenticate in Outlook and OneDrive. (4) Confirmed no further lockouts after 15 minutes.
User update: Sent ticket update: "Your account has been unlocked. The issue was caused by saved login details in Windows that were still using your old password. These have been removed. Please re-enter your password when Outlook or OneDrive prompts you. The issue should not recur."
Data sources consulted
Reviewed failed authentication events for j.harrison. Identified error code 50053 and authentication source pattern.
Relevant — root cause evidenceConfirmed the lockout threshold is 10 failed attempts within 10 minutes. Consistent with the observed pattern.
Supporting evidenceChecked for similar lockout patterns on other Finance team accounts. None found — confirms isolated incident.
Scope check — not relevantChecked Microsoft service health dashboard for any authentication incidents. No active incidents at time of investigation.
Eliminated — not relevantDiagnosis
Root cause identified: Saved Windows credentials in Credential Manager were still holding the user's previous password. After the password change, Windows continued silently authenticating with the saved (now incorrect) credential, triggering repeated authentication failures and lockouts.
Scenario root cause: Old saved credentials are repeatedly trying the previous password. Match: Yes.
Note for recruiters
This report was generated from a DiamOps simulated investigation. The scenario, ticket, logs, and evidence are all simulated. The investigation notes and documentation are written by the candidate. The score reflects the quality of the candidate's reasoning, evidence review, and documentation — not whether they knew the answer in advance.
DiamOps investigation reports are one input for assessing operational readiness. They should complement, not replace, interviews, references, technical assessments, and employer judgement.
Generate your own investigation report
Free to start. Pick a role path, work a realistic investigation, and share your proof with a recruiter.