In this module
IAM0 Check My Knowledge
Scenario 1. Your tenant has 810 member accounts. The data quality audit from IAM0.1 shows 80% are missing employeeHireDate and 25% have no manager assigned. You plan to deploy lifecycle workflows that trigger 7 days before hire date and access reviews that route to the identity's manager. What is the primary governance risk?
The lifecycle workflows will fail with error messages for identities missing the hire date attribute, alerting you to the data quality problem immediately. a
Lifecycle workflows don't fail with errors for missing attributes. They silently skip identities that don't match the trigger condition. An identity with no employeeHireDate simply never appears in the workflow's evaluation scope. You won't receive an error — you'll receive silence, which is harder to detect. IAM0.2 demonstrated this silent failure pattern across all five lifecycle stages.
The workflows and reviews will execute successfully but cover only a fraction of the workforce — lifecycle automation for 20% of new hires and access reviews for 75% of identities — creating a false sense of governance coverage. b
This is the core data quality problem from IAM0.2 and IAM1.3. The governance mechanisms work correctly for identities with the required attributes. They silently exclude identities without them. The workflow completion logs show successful execution. The review completion reports show 100% of scoped items reviewed. But 80% of new hires and 25% of identities are outside scope. The governance program appears to function while covering a minority of the population.
The access reviews will automatically fall back to a secondary reviewer when the primary manager is missing, so the 25% gap is handled by the review system. c
Fallback reviewers are not configured by default. If you create an access review with manager-based reviewers and don't configure a fallback, identities with no manager are skipped entirely. Fallback reviewers can be configured, but they lack the context a direct manager has — they're reviewing access for identities they may not know. The gap needs to be addressed through manager assignment, not through reviewer fallbacks. IAM1.3 established the 80% minimum threshold for manager coverage before deploying manager-based reviews.
The data quality problem only affects dynamic groups, not lifecycle workflows or access reviews. Workflows trigger on dates and reviews route to reviewers regardless of attribute completeness. d
All three governance mechanisms depend on attributes. Lifecycle workflows require employeeHireDate as the trigger anchor. Access reviews require manager as the reviewer target. Dynamic groups require department or employeeType as the membership rule criteria. IAM1.2 mapped these dependencies in the attribute dependency chart — the data quality problem affects every governance mechanism that evaluates user attributes.
Scenario 2. Your annual group access review completed with a 99.4% approval rate across 342 group memberships. The auditor accepts the completion report as evidence of access certification. Rachel Okafor reviews the results and identifies a governance concern. What is the concern?
The review should have been quarterly instead of annual, since annual reviews are too infrequent for any access type. a
Annual reviews are acceptable for low-risk standard access. The cadence isn't the primary concern here — the review quality is. A quarterly review with the same 99.4% approval rate would produce the same governance failure four times a year instead of once. IAM0.3 distinguished between the review cadence (how often) and the review quality (whether the reviewer actually evaluates each membership).
The 0.6% denial rate means the initial access assignments are nearly perfect, and the review confirms that access governance is working as intended. b
The tenure-vs-groups analysis from IAM0.3 directly contradicts this interpretation. Group membership averages 14.8 for identities with 3+ years tenure — more than triple the onboarding baseline. If access assignments were 99.4% accurate, long-tenured employees wouldn't accumulate three times more groups than new hires. The low denial rate indicates reviewers are approving without evaluating, not that access is well-governed.
A 99.4% approval rate across 342 memberships, combined with the tenure-vs-groups data showing systematic access accumulation, indicates reviewers are rubber-stamping approvals rather than evaluating each membership — the review produces compliance evidence without governance value. c
This is the "Approve All" problem from IAM0.3. The review completed — 100% of items were reviewed. The deny rate (0.6%) is statistically indistinguishable from zero. Meanwhile, the permission creep data shows access growing monotonically with tenure. If reviewers were genuinely evaluating memberships, the denial rate would be higher for long-tenured identities with accumulated access. The review creates an audit artifact that looks like governance but isn't. Module 5 addresses this by adding reviewer context (what does this group grant?), usage data (when did this identity last access this resource?), and AI-assisted recommendations.
The review should have targeted specific high-risk groups rather than all 342 memberships, since reviewing everything dilutes the reviewer's attention. d
Targeted reviews for high-risk groups are a valid design choice (Module 5 covers review scope design), but the concern here isn't scope — it's that the reviewer approved 340 of 342 items without context. Narrowing the scope doesn't fix the context problem. A reviewer who rubber-stamps 342 items will rubber-stamp 50 items with the same lack of information. The fix is reviewer context and usage data, not smaller review batches.
Scenario 3. Your non-human identity census from IAM0.4 finds 347 app registrations with 89 holding credentials, 31 with expired secrets, and a Data Migration Tool app holding 12 application permissions including Directory.ReadWrite.All. The developer who created the tool left the organization 8 months ago. What is the most urgent governance action?
Identify and remove the Data Migration Tool's active credentials, then audit and right-size its 12 application permissions — the expired migration tool with Directory.ReadWrite.All is the highest-risk finding because a new secret can be generated in seconds, instantly granting tenant-wide write access. a
The Data Migration Tool is the highest-risk non-human identity in the census. Its credentials may be expired (preventing current use), but its permissions are still granted. Anyone with Application Administrator rights can generate a new client secret in 30 seconds, and the application immediately has Directory.ReadWrite.All — tenant-wide read/write to every object in Entra ID. The departed developer's access may be revoked, but the application's permissions persist independently of any human identity. IAM0.4 described this as "the door is still propped open — cutting a new key takes 30 seconds."
Focus on the 31 expired credentials first, since expired secrets indicate integrations that may have broken without anyone noticing. b
Expired credentials are a governance finding, but they represent lower risk than active permissions on a high-privilege app. An expired credential means the app can't currently authenticate — the integration is already broken or was replaced. The Data Migration Tool with Directory.ReadWrite.All is a higher priority because its permissions are active even if the credential is expired. Module 9 covers credential governance comprehensively, including triage prioritization.
Create an access review for all 347 app registrations to systematically evaluate whether each one is still needed. c
A comprehensive app registration review is the right long-term approach (Module 9 builds this), but it's not the urgent action. Reviewing 347 apps takes weeks. The Data Migration Tool with tenant-wide write permissions is an immediate risk that should be addressed in hours, not weeks. Triage the highest-risk findings first, then build the systematic governance program. IAM0.4's three diagnostic questions applied to the Data Migration Tool all return governance failures: no documented purpose, never reviewed, no accountable owner.
Disable the Data Migration Tool's service principal to prevent any authentication, then schedule a review of all app registrations for the next quarter. d
Disabling the service principal is a reasonable interim step, but it doesn't remove the permissions — a re-enabled service principal with a new credential would immediately regain all 12 application permissions. The complete remediation is: remove or reduce the permissions (especially Directory.ReadWrite.All), then assess whether the app registration should be deleted entirely since the migration is complete. Disabling without permission removal is the same pattern as disabling a user account without removing group memberships — it's suspension, not decommissioning.
Scenario 4. You're applying the three diagnostic questions from IAM0.1 to a security group called SG-Finance-Readers that Priya Sharma (a SOC analyst) belongs to. The group has no owner and no description. You can answer "when was this access last reviewed?" — it was reviewed in the annual group review 4 months ago and approved. Which diagnostic question reveals the actual governance gap?
When was this access last reviewed? The review happened 4 months ago, so the governance is current. a
The review happened. The question was answered. But the review approved a SOC analyst's access to finance resources — the reviewer (Tom Ashworth) didn't know what SG-Finance-Readers grants and approved it along with 95 other memberships in 47 seconds. The review's existence doesn't prove governance value. IAM0.3 demonstrated that a 99.4% approval rate indicates rubber-stamp reviews, not informed certification.
Who is accountable? The group has no owner, so there's nobody accountable for membership decisions. b
This is a real finding — the group is ownerless, which means access review can't route to the group owner and nobody is responsible for membership decisions. But the review still ran (routed to Priya's manager instead). The accountability gap is important but isn't the diagnostic question that reveals the core governance failure in this scenario.
A fourth question is needed: what does this group grant access to? The three diagnostic questions don't cover the resource-level detail. c
The three diagnostic questions are deliberately comprehensive. The first question — "why does this identity have this access?" — implicitly requires knowing what the access grants. If you can't answer why Priya has this access, it's because you don't know what SG-Finance-Readers provides. You don't need a fourth question. You need a complete answer to the first one.
Why does this identity have this access? Priya is a SOC analyst. The group is called SG-Finance-Readers. Nobody can articulate why a SOC analyst needs finance read access — the access was granted during her previous role and survived the transfer. The review approved it without that context. d
This is the governance gap. The review answered "when was access last reviewed?" (4 months ago) and technically answered "who is accountable?" (Tom, as Priya's manager, reviewed it). But neither the reviewer nor the system answered "why does Priya have finance access?" The mover problem from IAM0.2 — access granted for a previous role, surviving a transfer, approved by a reviewer who lacks context — is invisible to a review that doesn't provide resource-level detail. Module 5 addresses this by adding group descriptions, usage data, and AI recommendations to the review interface.
Scenario 5. Your governance state assessment from IAM1.7 returns a composite data quality score of 33%. The CISO asks whether you can deploy lifecycle workflows while the data remediation runs in parallel. Your employeeHireDate coverage is currently at 53%. What is your recommendation?
Deploy lifecycle workflows immediately for the 53% of identities that have hire dates, and extend coverage as remediation progresses. Any automation is better than no automation. a
Deploying at 53% means the workflow automates onboarding for roughly half of new hires. The other half receives the manual process. This creates a split experience — some new hires get the TAP, welcome email, and group assignments automatically, while others don't. IT doesn't know which new hires received automation and which didn't without checking each one. IAM1.3 established 70% as the minimum threshold for lifecycle workflow deployment because below that, the workflow supplements manual provisioning rather than replacing it.
Wait until employeeHireDate coverage reaches 70% before deploying lifecycle workflows. Run the data remediation as the priority — the two-week timeline from the ADR IAM1-001 remediation plan targets 70% coverage. Deploy at 70% with monitoring for the remaining 30%. b
70% is the minimum viable threshold from IAM1.3 where the workflow becomes the primary onboarding mechanism rather than a supplement. At 70%, most new hires receive automated onboarding. The 30% gap is documented as residual risk with manual provisioning as the fallback. The two-week remediation timeline from ADR IAM1-001 is achievable — prioritize the most recent hires for employeeHireDate enrichment. Deploy at 70%, monitor the workflow execution logs for identities that don't trigger, and continue remediation toward 90%.
Don't deploy lifecycle workflows until employeeHireDate coverage reaches 95% or higher. Partial coverage creates inconsistent onboarding experiences that are worse than a consistent manual process. c
95% coverage is ideal but unrealistic as a deployment gate. Historical hires where HR can't provide the date may never reach 95%. Waiting for near-perfect coverage delays governance deployment indefinitely. The 70% threshold from IAM1.3 balances coverage with deployment speed — most identities are automated, the rest are documented exceptions with a manual fallback. The governance program should launch with documented gaps, not wait for zero gaps.
Deploy lifecycle workflows scoped to a single department (Security) where data quality is higher, then expand department by department as remediation progresses. d
Department-scoped deployment is a valid pilot strategy, but it requires employeeType or department-based workflow scoping — which depends on those attributes being populated. If department coverage is 80% but employeeHireDate is 53% within that department, the workflow still can't trigger for identities without hire dates. The threshold applies per-attribute, not per-department. A pilot is useful for testing the workflow mechanics, but it doesn't solve the data quality gate.
Scenario 6. Your tenant has zero administrative units. Phil Greaves holds permanent Global Administrator, User Administrator, Exchange Administrator, and SharePoint Administrator — all at tenant-wide scope. Rachel asks you to reduce Phil's privilege immediately. What is the correct sequence?
Remove all four roles immediately and reassign them as PIM-eligible. Phil activates what he needs, when he needs it. a
Removing all four roles simultaneously from the only person who administers the tenant creates an operational gap. If PIM activation fails (misconfiguration, MFA issue, emergency), nobody can manage the tenant. The correct approach is sequential: convert one role at a time, starting with the least critical, verify PIM activation works for that role, then convert the next. Never remove the last standing Global Administrator assignment without confirming PIM and break-glass procedures work. IAM1.5 documented this as ADR IAM1-003 — delegation changes require the PIM governance framework from Module 7.
Create administrative units first (Module 8), then scope Phil's roles to specific AUs, reducing his tenant-wide access to site-specific access. b
AUs can scope some roles (User Administrator, Helpdesk Administrator) but not all. Global Administrator cannot be scoped to an AU — it's inherently tenant-wide. Exchange Administrator and SharePoint Administrator also can't be AU-scoped because they operate on tenant-wide services. The correct approach starts with PIM (Module 7) to make roles eligible rather than permanent, then adds AUs (Module 8) for the roles that support scoping.
Document the current state as a risk register entry now. Then, in Module 7, convert roles to PIM-eligible sequentially — starting with Exchange Administrator and SharePoint Administrator, then User Administrator, and Global Administrator last. Verify PIM activation works at each step. Configure break-glass accounts before converting the final Global Administrator. c
This is the sequence from ADR IAM1-003. Privilege reduction requires the PIM infrastructure from Module 7 and the break-glass governance from Module 7 as prerequisites. Documenting the risk now (DEL-002 in the risk register) ensures the finding is tracked. The sequential conversion — least critical roles first, Global Administrator last, with break-glass validation before the final conversion — ensures operational continuity throughout the transition. IAM1.5 established that delegation changes without the governance framework around them create empty boundaries.
The current state is acceptable for an 810-person organization. A single IT Director with Global Administrator is standard practice and doesn't require remediation. d
A single identity with permanent Global Administrator and three additional admin roles is not acceptable governance practice at any organization size. Global Administrator grants unrestricted control over the entire tenant — every user, every group, every application, every security control. Permanent assignment means the credential is always active. No activation approval, no time limit, no audit trail for elevation. If Phil's credential is compromised through phishing, credential stuffing, or social engineering, the attacker has full tenant control without any governance barrier. IAM0.3 identified this as a separation of duties finding, and IAM1.5 documented it as DEL-002.
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
Thank you — your feedback has been received.
© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.
You're reading the free modules of Identity and Access Management in Microsoft 365
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.