In this module
MSA1.15 Check My Knowledge
Check My Knowledge — Module 1
Eight scenario questions. Each presents a situation from the NE identity assessment and asks what you'd do or conclude. Pick your answer before reading the explanation.
Scenario 1. You query the organization's tenant and find 810 user accounts. Your CISO asks if a Conditional Access policy targeting "All Users" with "Require MFA" protects the tenant. You check the identity census and find 34 application registrations and 12 service principals. What is the most accurate response?
Yes — "All Users" covers every identity in the tenant, including applications a
"All Users" in a CA policy includes member users (cloud-only and synced) and guest users. It does not include workload identities. Service principals authenticate through the client credentials flow, which bypasses all user-targeted CA policies. The 34 app registrations and 12 service principals operate with no MFA, no device compliance, no risk evaluation.
Partially — applications don't need MFA because they use client secrets instead of passwords b
Client secrets are credentials, not a substitute for access controls. The issue isn't that applications "don't need MFA" — it's that no CA policy evaluates their authentication. A leaked client secret gives an attacker whatever API permissions the application holds with no policy evaluation. Workload ID Premium licensing is required to apply CA policies to service principals.
No — "All Users" does not include workload identities. the organization's 34 app registrations and 12 service principals authenticate outside the CA framework entirely. They need Workload ID Premium licensing and separate CA policies targeting service principals. c
Correct. The CA framework evaluates user sign-ins (interactive and non-interactive) but not client credential flows used by service principals. Without Workload ID Premium, the tenant has a complete CA blind spot for non-human identities. This is MSA1.3's highest-priority finding for workload identities.
You can't determine this without checking the specific CA policy conditions d
The specific policy conditions matter for user targeting, but the structural gap is that workload identities are outside the CA scope entirely. Even a perfectly designed user CA policy doesn't evaluate service principal authentication. The gap is architectural, not configurational.
Scenario 2. NE uses Cloud Sync with Password Hash Sync. A colleague argues that PHS is dangerous because "it puts password hashes in the cloud." They recommend switching to Pass-Through Authentication. How do you evaluate this recommendation?
The colleague is correct — PHS creates unnecessary cloud exposure. PTA is more secure because passwords are validated on-premises a
PTA doesn't eliminate the hash exposure — the NTLM hashes still exist in on-premises AD. An attacker who compromises a domain controller gets them regardless of whether PHS is enabled. PTA moves authentication to on-premises but adds agent servers as attack surface and reduces Identity Protection coverage.
PHS provides stronger security than PTA for most organizations. The hashes in Entra ID are derived (SHA-256 with salt), not raw NTLM. PHS enables full Identity Protection, cloud authentication resilience, and no on-premises agent attack surface. PTA is only appropriate when regulations explicitly prohibit cloud-stored password hashes. b
Correct. The "passwords in the cloud" objection sounds reasonable but doesn't survive analysis. PHS adds a copy of credentials that already exist — and enables better detection of their misuse through Identity Protection. PTA introduces on-premises dependency, reduces Identity Protection, and adds agent servers as Tier 0 attack surface. the organization's ADR-MSA1-002 documents this decision with specific constraint-based reasoning.
Both are equally secure — the choice depends on organizational preference c
They are not equally secure. PHS provides full Identity Protection risk evaluation because authentication happens in Entra ID. PTA provides reduced Identity Protection because Entra ID only sees the authentication result, not the authentication itself. The difference is measurable: specific risk detections (anomalous token, unfamiliar features) have reduced coverage with PTA.
Neither matters — phishing-resistant MFA makes the password irrelevant regardless of where it's stored d
Phishing-resistant MFA is the long-term mitigation (MSA2), but until NE achieves 100% passwordless adoption, the password remains a usable authentication factor. The authentication method (PHS vs PTA) determines how effectively Identity Protection detects password-based attacks during the transition period.
Scenario 3. the organization's legacy Entra Connect server was powered off 8 months ago when Cloud Sync was deployed. The server hasn't been decommissioned. The service account still exists in both Active Directory and Entra ID. the CISO asks whether this is a risk. How do you assess it?
HIGH risk. The service account likely retains the Directory Synchronization Accounts role in Entra ID, granting write access to all synced identities. The SQL LocalDB database on the server's disk contains cached identity data. The computer account can still authenticate to the domain if the server is powered on. The 9-step decommission sequence should be executed immediately. a
Correct. "Powered off" is not "decommissioned." The server's credentials (service account in both directories, computer account in AD) remain valid. The SQL LocalDB contains sync configuration and cached identity data. If the server is powered on — accidentally or by an attacker — it can authenticate and potentially interfere with Cloud Sync. This is MSA1-RISK-002 and MSA1-RISK-003.
LOW risk — the server is powered off and can't do anything b
The server being powered off doesn't remove the risk — it defers it. The service account credentials are still valid. The disk contains identity data. An attacker with physical access could power it on or extract the disk. The risk is in the credentials and data, not in whether the server is currently running.
MEDIUM risk — disable the service account and consider decommissioning when convenient c
The service account should be disabled, but "when convenient" underestimates the risk. The account has write access to Entra ID. The password writeback flag is enabled, meaning the account could (if authenticated) trigger password resets that propagate to on-premises AD. This is a Tier 0 credential that's been forgotten, not a low-priority cleanup.
No risk — Cloud Sync replaced the server's function, so the old credentials are automatically invalidated d
Deploying Cloud Sync doesn't invalidate the legacy server's credentials. Entra ID doesn't automatically revoke the Directory Sync Accounts role from the old service account when a new sync engine is configured. The credentials persist until someone explicitly removes them — which nobody at the tenant has done.
Scenario 4. You create a restricted management Administrative Unit and add the break-glass accounts. A Global Administrator tries to reset bg01's password and receives an error. Your colleague says this is a bug because Global Administrators should have unrestricted access. How do you explain it?
It is a bug — Global Administrators should always be able to manage any account a
This is the intended behavior of restricted management AUs. The entire purpose is to prevent tenant-level administrators (including Global Administrators) from modifying the protected accounts unless they have an explicit AU-scoped role. This is a security feature, not a bug.
The Global Administrator needs to be added to the restricted AU as a member to manage its contents b
Adding a Global Admin as a member of the AU doesn't grant management capability. AU membership means the admin's own account is in the AU (subject to AU delegation). Management capability comes from having a role scoped to the AU — such as User Administrator assigned at the AU scope.
The restricted AU is blocking all management — even AU-scoped admins can't modify the members c
Restricted AUs block tenant-scoped admins but allow AU-scoped admins. If the security architect has the User Administrator role scoped to the restricted AU, he can modify the break-glass accounts. The protection is selective: it blocks broad tenant-level roles while permitting explicitly scoped roles.
This is the intended behavior. Restricted management AUs block all tenant-level administrators — including Global Administrators — from modifying members. Only administrators with roles explicitly scoped to this specific AU can manage these accounts. This is the architectural protection for break-glass accounts documented in MSA1.6. d
Correct. The restricted AU creates a security boundary that even Global Administrators can't cross without an explicit AU-scoped role. This prevents a compromised Global Admin account from modifying the break-glass accounts — which are the last line of defense. The Datadog Security Labs research showed this same mechanism can be weaponised for persistence if an attacker creates their own restricted AU.
Scenario 5. SOC Analyst 2 moved from Engineering to the SOC 3 months ago. Her account has 11 group memberships. You identify 8 as stale (Engineering groups and a completed project). What is the architectural fix — not for Priya specifically, but for the organization?
Run an access review annually to catch accumulated access a
Access reviews (MSA12) are remediation for existing access debt. They detect the problem after it's already occurred. The architectural fix prevents accumulation in the first place. Annual reviews also mean access accumulates for up to 12 months before anyone checks — Priya's 8 stale memberships persisted for months without detection.
Implement Lifecycle Workflow mover automation that triggers when role-relevant attributes change, removing the old department's groups and adding the new department's groups. This requires group-mediated access (all resource access through named groups, not ad-hoc assignments) and reliable HR attribute data. b
Correct. The mover workflow is the architectural prevention mechanism. When Priya's department attribute changes from "Engineering" to "Security," the workflow removes her from SG-Engineering-All, SG-App-CAD-Users, and SG-App-PLM-Users, and adds her to SG-Security-All and SG-App-Sentinel-Readers. This requires two prerequisites: group-mediated access (MSA1.10) so the workflow has groups to manage, and HR attribute accuracy (MSA1.7) so the trigger fires reliably.
Remove Priya from the 8 stale groups and document the cleanup c
This fixes Priya's specific case but doesn't fix the systemic problem. The next person who changes roles will accumulate the same stale access. Individual remediation without architectural change means the problem recurs for every role change — approximately 1,215 events across the organization's current workforce.
Use dynamic groups instead of assigned groups so membership adjusts automatically when department changes d
Dynamic groups handle department-level groups well (DG-Engineering-All updates automatically when department changes). But not all of Priya's stale memberships are department-based — the Safety Compliance project group and application-specific groups (CAD, PLM) aren't derived from a single attribute. Dynamic groups are part of the solution but don't replace the mover workflow for role-specific access.
Scenario 6. the tenant has 147 guest accounts. Your stale identity scan finds that 34 have PendingAcceptance status, the oldest from November 2022. the CISO asks what the risk is. What do you tell her?
No risk — pending invitations expire automatically after 30 days a
B2B invitation links do have a configurable expiration period, but the guest identity object in your tenant persists regardless of whether the invitation link has expired. The identity object with its intended access (group memberships, application assignments) remains in the directory until someone explicitly deletes it.
Low risk — the guests never accepted, so they have no access b
The guests haven't authenticated, but the identity objects exist. Whatever access was intended for them when the invitation was created (group memberships, SharePoint permissions) may already be configured on the guest object. Additionally, default guest permissions allow directory enumeration — even a freshly accepted invitation grants the guest visibility into the tenant's user and group directory.
HIGH risk. Each pending identity is a trust relationship that NE accepted and forgot about. If the guest's email address is compromised, an attacker could potentially accept the invitation and gain whatever access was intended. Additionally, 147 guests can enumerate the directory because the default guest permission level hasn't been restricted. Delete pending invitations older than 90 days and restrict guest permissions. c
Correct. The risk isn't the guest account itself — it's the unreviewed trust relationship. NE accepted a trust relationship with an external email address 3+ years ago and never reviewed it. The combination of stale invitations and default guest permissions (directory enumeration) means the guest population represents both dormant access (the pending invitations) and excessive visibility (all 147 guests can list users and groups).
You should disable all 147 guest accounts until they can be reviewed individually d
Disabling all guests would break active collaboration. 89 guests have accepted and may be actively collaborating with NE staff. The approach is targeted: delete the 34 pending invitations older than 90 days (no active user to disrupt), disable the 12 blank-state guests (review sharing dependencies), and review the 52 accepted-but-inactive guests with resource owners before disabling.
Scenario 7. You're about to rename "SOC Analysts" to "SG-SOC-Analysts" as part of the naming convention migration. A CA policy targets this group. Your colleague warns that renaming will break the policy. Is this correct?
No — CA policies reference groups by their internal object ID (GUID), not by display name. Renaming the group changes the display name but the ID stays the same. The CA policy continues targeting the group correctly after the rename. a
Correct. Entra ID objects have immutable IDs. When a CA policy includes a group in its target scope, it stores the group's GUID — not its display name. Renaming changes the display name only. The CA policy, application assignments, license assignments, and PIM configurations all continue referencing the group by ID. The rename is safe.
Yes — renaming the group requires updating the CA policy to reference the new name b
CA policies don't reference groups by name. If you open the CA policy in the portal after renaming, you'll see the new display name (SG-SOC-Analysts) in the target configuration — because the portal resolves the stored GUID to the current display name. No update needed.
It depends on whether the CA policy was created in the portal or via PowerShell c
Regardless of how the policy was created, it stores the group reference as a GUID. Portal-created and PowerShell-created policies behave identically in this regard.
You should create a new group with the correct name, migrate members, update the CA policy, then delete the old group d
This is unnecessary work and introduces risk (membership mismatch during migration, CA policy downtime during the switchover). The rename operation changes the display name in-place while preserving the ID, membership, and all downstream references. No migration needed.
Scenario 8. You present the NE Identity Assessment to the CISO. She asks: "What's the single most important thing we need to do that we haven't done?" Based on the assessment's findings and roadmap, what do you recommend?
Decommission the legacy Entra Connect server — it's the highest individual risk a
The server decommission is HIGH priority and should happen this month (Tier 2). But it's a one-time fix for a specific risk. The "most important thing" should be the investment that enables the most downstream controls — not just one remediation.
Implement phishing-resistant MFA for all users — authentication is the most critical control b
Phishing-resistant MFA (MSA2) is critically important, but it builds on the identity layer. Without the groups to target the CA policies that enforce authentication strength, without the AU structure for delegated administration, and without the naming convention for queryable governance — the MFA deployment lacks the infrastructure to deploy and manage at scale.
Clean up the 98 stale guest accounts — they represent the largest number of stale identities c
Stale guest cleanup is important (Tier 1 for pending invitations, Tier 3 for inactive-but-accepted). But guest cleanup is a one-time remediation without the lifecycle automation that prevents re-accumulation. Cleaning up 98 guests today doesn't stop the same problem from recurring in 6 months.
Connect the HR system to Entra ID. It's the foundation for everything: lifecycle automation, accurate user attributes for dynamic groups and CA targeting, time-based triggers for joiner and leaver workflows, and the mover process that prevents access accumulation. Without the HR pipeline, most of MSA12's governance architecture can't function. d
Correct. The HR data pipeline is the single largest dependency in the remediation roadmap (Tier 4, item 16). Lifecycle Workflows (item 17) can't trigger without HR attributes. Dynamic groups can't populate reliably without accurate department data. The mover process can't exist without attribute-change detection. Every governance control in MSA12 depends on the HR system providing authoritative lifecycle data. The immediate risk remediations (decommission, stale cleanup) are important, but the HR pipeline is the strategic investment that enables automated governance at scale.
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 m365-security-architecture
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.