Engineers who move up the DevOps career ladder tend to be asked a particular kind of question: something is wrong with access, nobody knows why, and a decision is needed by the end of the day. The skill being tested is diagnosis. This article collects six recurring symptoms from the IdentityOps field, each followed by a likely cause and a corrective step. The material draws on the Ops Atlas, the reference published by xOps School, which treats IdentityOps as an emerging discipline concerned with the population of accounts across a company and the evidence each one offers at sign-in. Learning to move from symptom to cause is what separates a senior engineer from a capable executor.
Symptom one: a leaver can still read company mail
Diagnosis. The directory account was disabled, yet the person’s phone remains signed in. The Atlas explains the mechanism: sessions and tokens outlive the account that produced them. On one major cloud identity service the stock access token is valid for roughly sixty to ninety minutes, stretching toward a full day when continuous access evaluation is turned on. A revoke command exists, but it may take minutes to propagate, and a revoke at the central service can leave app-held sessions alive.
Fix. Build the leaver runbook as an ordered sequence: HR termination recorded, directory account disabled, sessions and tokens revoked, downstream deactivation pushed, timestamps captured. Test it against a dummy user monthly. Engineers working through the stages mapped in this piece on growing from a junior DevOps role to a senior one will recognise this as a typical senior-level hardening task.
Symptom two: the dashboard says provisioning succeeded, but the account is still live
Diagnosis. There are at least three plausible causes, and the Atlas names each. First, the order of operations: on one platform, unassigning a user and then triggering an on-demand push leaves the account enabled until the final push finishes. That on-demand route is quick, normally well inside half a minute, yet it applies only to users already unassigned from the application. Second, the scheduled cycle of that platform runs about every forty minutes as of October 2026, so waiting is sometimes the real answer. Third, a quarantined provisioning job slows down to once a day and may be disabled after four or more weeks, silently stopping all removals.
Fix. Check the job’s health before the user’s status. Then verify the outcome by comparing the application’s own user export with the directory, because the Atlas warns against reconciling from provisioning logs alone: logs record what the system attempted, not what the application now holds. For applications that authorise through OAuth, such as common collaboration and storage services, the Atlas says the job must be stopped first before changes behave as expected.
Symptom three: removing someone from one tool wiped their access to everything
Diagnosis. A second identity platform distinguishes deactivation from suspension, and the two are not interchangeable. The Atlas notes that deactivation is destructive and deprovisions the user from all applications, whereas suspension keeps assignments in place. Picture an operator choosing deactivation for someone on temporary leave: one click, and every assignment disappears.
Fix. Document which action maps to which life event. Temporary leave means suspension; permanent departure means deactivation after the other steps are complete. Also confirm that the platform setting allowing deprovisioning is enabled, since the Atlas lists it as a prerequisite.
Symptom four: accounts appear in an application that nobody provisioned
Diagnosis. Just-in-time creation at first login. The Atlas describes it as having no removal channel, because the application learns of the person only when they arrive and never learns when they leave. It adds that one container-platform vendor advises using SCIM and leaving just-in-time creation off.
Fix. Move the application to SCIM where the licence permits. The Atlas cautions that many software-as-a-service vendors reserve SCIM for higher plans, and that HR-driven provisioning on one platform requires specific licence tiers. Budget for it before you promise the migration. Also test what an inactive flag does in each application, since the SCIM standard leaves that interpretation to the application.
Symptom five: a service credential turns up in a place it should not be
Diagnosis. Machine identities lack the life-cycle events people have. There is no resignation letter for an API key. The Atlas catalogues cases where this mattered. In autumn 2023 a service-account credential discovered in an employee’s personal storage led to hijacked sessions at five customers, and one affected company had skipped rotating a token and three accounts it assumed were idle. In 2024, a run of customer-environment intrusions involved passwords left unchanged for as many as four years, plus missing second factors and missing allow lists.
Fix. Start with an inventory, noting that the standard AWS credential report only covers the first two access keys and lists users, not roles. Then register an owner, purpose, expiry and review interval for each credential. Prefer short-lived ones, rotate on schedule, and decommission with evidence: disable, wait, delete. Treat any shared service account used by several humans as a defect to eliminate, because attribution is impossible.
Symptom six: the help desk keeps issuing resets to people who sound right
Diagnosis. The recovery path has become the easiest way in. The Atlas cites a CISA advisory about a criminal group that talked help desks into credential resets, swapped SIM cards, spammed approval prompts and registered rogue federated providers, and notes that phone call-backs cannot be trusted given SIM swapping.
Fix. Tier the recovery. Self-service through a second enrolled authenticator comes first. For assisted cases, a one-time pass goes out only once their manager has confirmed them, whether through a camera-on conversation or by meeting in person. For privileged accounts, require in-person or supervised video proofing and a second administrator. Every recovery should trigger a notification, as NIST guidance expects. For the assurance level of two, the Atlas says two codes by different methods, or one code plus a bound authenticator, are required.
A short triage order
When a report lands, work through the same four questions every time. Is the identity real and owned? Did the removal command run, and did it finish? Does the application agree with the directory? Is any live session or token still valid? Answering them in order stops you from chasing the wrong layer. Keep timestamps from each answer, because the end-to-end record is what lets you prove the fix later, and it is also what a quarterly drill will ask for. Engineers who can narrate this order calmly in an incident review gain trust quickly.
Turning diagnoses into a career asset
Write each of these as a short case note: symptom, evidence, cause, fix, prevention. Over a year, a collection of twelve such notes becomes a portfolio that shows judgment. The progression laid out in this roadmap covering the skills, projects and certifications behind DevOps career growth places diagnostic ability at the senior end; identity incidents make an excellent training ground.
Where to read the source material
The full list of anti-patterns, including disabled-equals-offboarded and counting weak methods as multi-factor, is in the Ops Atlas reference page on IdentityOps. Read it as a checklist of symptoms. When a fault arrives at your desk, ask first which of these patterns it resembles, then confirm with evidence rather than assumption.
Documenting what you learned
After each fix, add two lines to a shared runbook: what the symptom looked like from the user’s side, and which log or export confirmed the cause. Colleagues on the next shift will meet the same faults, and a precise note saves them an hour. Include the licence or plan dependency where one applied, because that detail is the first thing people forget.
A closing note on method
Good diagnosis in this domain follows one discipline: distinguish intent from outcome. The platform intended to remove the account; the application still shows it. The policy intended strong sign-in; the logs show weak methods used. The team intended to rotate the key; the dashboard shows an age of three years. Whenever intent and outcome diverge, you have found the work.