Refer to the Exhibit Practice Questions

The service principal is using federated credentials.

Why it fails: Federated credentials are stored in the `federatedIdentityCredentials` collection of the service principal, not in `passwordCredentials`. An empty `passwordCredentials` array therefore cannot be read as evidence that workload identity federation is in use; it only tells you no password-based client secret exists. The two properties are independent, so a service principal can have federated credentials while still showing an empty password credential list.

The service principal uses certificate-based authentication.

Why it fails: Certificate-based authentication relies on objects in the `keyCredentials` array on the service principal, where public key information and certificate metadata are stored for use in the client credentials flow. An empty `passwordCredentials` array indicates only that no client secret string is configured; it does not indicate whether certificates are configured. To determine certificate usage, you must inspect `keyCredentials`, which is a separate and independent property.

The Microsoft Graph application is disabled.

Why it fails: The disabled state of an application is controlled by the `accountEnabled` Boolean property on the service principal or the corresponding application object, not by the presence or absence of secrets. An empty `passwordCredentials` array merely means no client secret is assigned; the service principal can still be enabled and fully functional using other authentication methods. Therefore, this exhibit does not support the conclusion that the Microsoft Graph application is disabled.

The DLP policy requires administrator override for sharing.

Why it fails: The Block action in a DLP rule is absolute: it prevents the sharing action from completing and does not prompt for a business justification or administrator override. Microsoft 365 DLP does have a 'Block with override' action, but that behavior must be explicitly configured on the rule; the exhibit for this policy shows no such override option. Therefore the policy does not 'require' an administrator override—the rule simply denies the share.

The DLP policy is applied only to SharePoint Online, not OneDrive.

Why it fails: The exhibit's Locations list includes both SharePoint sites and OneDrive for Business, so the DLP policy is not limited to SharePoint Online. OneDrive for Business is a separate workload with its own sharing endpoints, and because it is selected, the same block action applies to documents shared from a user's OneDrive. The block occurs because OneDrive is a configured location, not because the policy ignores OneDrive.

The DLP policy does not include Microsoft Teams.

Why it fails: Microsoft Teams is listed as a location in the exhibit, but its inclusion or exclusion is irrelevant to a OneDrive external-sharing event. DLP policies for Teams govern chat and channel messages, whereas the action that blocks sharing of a file link is enforced by the SharePoint Online and OneDrive for Business workload detectors. Consequently, saying the policy 'does not include Teams' does not explain why or how a OneDrive share is blocked.

To list all users with sign-in blocked

Why it fails: This command filters on the AssignedLicenses property, not on the user's sign-in or account status. A sign-in-blocked user is typically identified by AccountEnabled set to False or by a SignInActivity/SignInBlocked flag, but the Where-Object clause never evaluates those properties. As a result, the command would list unlicensed users whose sign-in is allowed as well as those whose sign-in is blocked, so it cannot serve as a sign-in-blocked report.

To list all unlicensed users with a specific usage location

Why it fails: The command's filter checks only whether the AssignedLicenses collection is empty, so it returns all unlicensed users across every usage location in the tenant. To restrict the result to a specific usage location, you would need an additional condition such as $_.UsageLocation -eq 'US' combined with the license count check. Without that usage-location filter, the output is not scoped to one country/region, making this option incorrect.

To list all users who have a license assigned

Why it fails: This option is the inverse of the command's logic. A licensed user has at least one entry in AssignedLicenses, so their AssignedLicenses.Count is greater than 0, not equal to 0. To list licensed users, you would change the filter to AssignedLicenses.Count -gt 0 (or -ne 0). The command as written explicitly excludes those accounts and therefore cannot list users who have a license assigned.

The user does not have the Global Administrator role.

Why it fails: This option mistakes a filter result for an entitlement fact. In Microsoft 365 Defender, the IdentityInfo table contains one normalized record per discovered identity, including role memberships collected from Active Directory and Microsoft Entra ID. If the user were present but lacked the Global Administrator role, the row would still exist (with other roles or an empty role list); the query's role filter would simply not select it. An empty result therefore indicates that no identity record for this user reached the table, not that the user lacks the role.

The KQL query syntax is invalid.

Why it fails: If the query were syntactically invalid, KQL would return an error banner and the investigation page would not display an empty results set. The syntax shown—using `let` to define a variable followed by a pipeline of operators—is structurally valid and runs successfully. An empty result set proves the query was accepted by the parser; otherwise the tool would have raised a syntax error before returning any data. Thus syntax is definitely not the cause of the missing results.

The role name in the query is misspelled.

Why it fails: The literal 'Global Administrator' is the exact display name stored in the role property of IdentityInfo and matches the role name used in Microsoft Entra ID, so it is not misspelled. Even if a typo existed, the query would still return an empty result, but the underlying identity record would remain in the table; the correct diagnostic distinction is whether IdentityInfo has any rows at all. If the table were populated, a typo would yield no matches, yet you could still see the user by querying without the role filter. Since no user is returned even in a broader query, the spelling is a red herring.

Isolate the device immediately using Microsoft Defender for Endpoint

Why it fails: Isolating the device immediately in Microsoft Defender for Endpoint is premature because it halts the compromise without first collecting the forensic evidence needed to understand the attack. The isolation action does not reveal the process, command line, or parent process associated with the suspicious connection, and it can also destroy volatile data such as active network sessions if the investigation would have captured them. MDE's isolation should be a containment step taken after the alert is confirmed, not the first investigative action, especially when a benign application could be the source.

Add the IP address to the Tenant Allow/Block List to block it

Why it fails: Adding the IP address to the Tenant Allow/Block List will not block the outbound traffic from the device because that list only operates on messages and files in Exchange Online Protection and Microsoft Defender for Office 365, not on endpoint network connections. The Tenant Allow/Block List is used to override email filtering verdicts for senders, domains, URLs, or file hashes, and it cannot enforce a block at the network adapter level on a Windows device. For blocking an IP from endpoints, you would need a custom indicator in Microsoft Defender for Endpoint, and only after you understand the process and confirm the threat.

Create a Safe Links policy to block the IP address

Why it fails: Creating a Safe Links policy cannot block an IP address because Safe Links is a URL-detonation and time-of-click protection feature for links in email messages and Microsoft 365 apps, not a network-layer firewall or IP filter. Even if you entered the IP into a URL block list, it would only affect occurrences of that literal URL string in supported apps, not the raw IP connections being made from the endpoint. This action would be both ineffective at stopping the traffic and unrelated to the investigative process that should occur first.

The device is not onboarded to Microsoft Defender for Endpoint.

Why it fails: This is incorrect because the query is not scoped to a single device; it would return rows for any onboarded device that matches the AccountName filter. If a device were not onboarded to Microsoft Defender for Endpoint, it would simply not contribute data to the Advanced Hunting tables, but the presence of other onboarded devices would still produce results if they had matching logon events. Moreover, if the query were specifically targeting an unresponsive device, the query would need a DeviceName filter to isolate it. Therefore, the empty result set cannot be attributed to a single device's onboarding status.

The query is case-sensitive and the account name is 'Admin' with a capital A.

Why it fails: KQL's '==' operator is case-sensitive, so if the actual account name were 'Admin' with a capital A, the filter would indeed exclude those events. However, the query is explicitly searching for the exact string 'admin', and the correct interpretation of an empty result is that no logon events with that exact account name exist in the given time window. While case sensitivity could theoretically cause a false negative, it is not the most probable reason unless there is evidence that an 'Admin' account is active. The default assumption for an empty set should be that the data simply does not match the query criteria.

There are no logon events in the last 7 days.

Why it fails: This is incorrect because the query includes a specific filter on AccountName, so the absence of results only tells us that no events matched that filter, not that the entire events table is empty. In fact, logon events from other accounts would be excluded by the filter and would not appear in the output. Additionally, on an active device or environment, logon events are abundant, so a complete absence of logon events over 7 days would be highly unusual and would require a separate investigation. The correct conclusion is limited to the account 'admin', not all logon activity.

The B2BCollaborationOutbound setting is blocking access

Why it fails: The B2BCollaborationOutbound setting controls how Contoso users, the users in the originating tenant, are shared with Fabrikam - specifically, whether Contoso users can be invited to Fabrikam's tenant or access applications hosted there. It says nothing about Fabrikam identities trying to get into Contoso resources. Because the reported problem is an external user from Fabrikam being unable to access Contoso, an outbound policy cannot be the root cause; that failure can only be governed by Contoso's inbound cross-tenant access settings.

The default cross-tenant access policy is set to block all

Why it fails: The default cross-tenant access policy applies only when no tenant-specific policy has been configured for that partner organization. In the exhibit, Fabrikam has its own organizational-specific cross-tenant access settings, and those settings take precedence over the default policy for that tenant. Even if the default policy were shown as blocking - which it is not - the partner-specific inbound B2B collaboration configuration would override it. Therefore, an empty or non-blocking default cannot explain why Fabrikam B2B users are failing to gain access to Contoso.

The B2BDirectConnectInbound setting is empty

Why it fails: B2B direct connect is a different collaboration capability used for Teams shared channels, allowing users from Fabrikam to participate in shared channels in Contoso's tenant without becoming B2B guest directory objects. An empty B2BDirectConnectInbound setting would therefore affect Teams shared-channel access, not the standard B2B collaboration invitation flow that lets external users sign in as guests and access Contoso apps. Since the issue described is about B2B collaboration guest access, the empty direct-connect setting is irrelevant to the failure, even if it appears alongside the collaboration settings in the cross-tenant access policy.

Isolate the device from the network immediately

Why it fails: Isolating the device cuts network connectivity before compromise is confirmed, and does not start an automated investigation; it is a containment action taken afterwards. It is tempting because isolation limits spread, and would be correct once investigation confirms active compromise requiring immediate containment.

Initiate a Live Response session to gather forensic data

Why it fails: Live Response collects forensic artefacts but does not itself trigger the automated investigation the scenario requires; the device must first be flagged for investigation in Defender XDR. It is tempting because forensic triage is valuable, and would be correct when deep artefact collection is needed after automated investigation has already run.

Run a full antivirus scan from Microsoft Defender Antivirus

Why it fails: A full antivirus scan only inspects local files for known malware signatures; it cannot correlate the multi-source alerts already surfaced in Defender XDR or trigger the automated investigation the scenario requires. It is tempting because scanning is a familiar first response to a slow device, and would be right for suspected file-borne malware with no existing alerts.

All users accessing all cloud apps are required to use MFA

Why it fails: The exhibit scopes the policy to a subset of users or apps, so it does not require MFA for every user across all cloud apps. It is tempting because an unscoped MFA grant is the correct design when an organisation mandates phishing-resistant authentication universally.

Access to Office 365 from iOS and Android is blocked

Why it fails: The policy targets iOS and Android device platforms, so it cannot block Office 365 access from those platforms unless those platforms are the configured condition. Blocking iOS and Android is what a platform condition set to those values would achieve.

Users on mobile devices are required to use hybrid Microsoft Entra ID joined devices

Why it fails: Hybrid Microsoft Entra ID joined device controls apply only to Windows desktops, not mobile platforms, so the policy cannot enforce this on iOS or Android. It is tempting because hybrid join is the correct control when you need corporate Windows devices to satisfy Conditional Access through on-premises domain registration.

Add a session control for sign-in frequency.

Why it fails: Sign-in frequency sets how often users must reauthenticate; it adds a session requirement rather than relaxing the compliant-device grant, so the block persists. It is the right control for enforcing periodic reauthentication on sensitive apps or admin portals.

Remove the cloudAppSecurity session control.

Why it fails: Cloud app security session controls govern in-session actions like download blocking, not device compliance; removing one leaves the compliant-device grant untouched, so users remain blocked. It is the correct control when you want to restrict downloads or monitor sessions on unmanaged devices.

Change cloudAppSecurityType to "blockDownloads".

Why it fails: BlockDownloads is a session control applied after access is granted; it cannot override the compliant-device grant that is denying access. It is the correct choice when you want unmanaged devices to view but not download Office 365 content, paired with a permissive grant.

Enable cloud-delivered protection by setting MAPSReporting to Advanced.

Why it fails: Cloud-delivered protection is controlled by the `MAPSReporting` parameter, which accepts values like `Disabled`, `Basic`, or `Advanced`; however, the output shown does not include `MAPSReporting`, so you cannot infer its current state from this command. More importantly, changing `MAPSReporting` only adjusts your membership level in the Microsoft Active Protection Service and does not enable behavior monitoring, which is the issue the output indicates. Cloud-delivered protection is also a separate Defender layer from the local behavior monitoring engine.

Set DisableBlockAtFirstSeen to True to enable Block at First Sight.

Why it fails: The `DisableBlockAtFirstSeen` value of `False` already means Block at First Sight is enabled, because this parameter is named as a disable switch: `True` would disable the feature, while `False` enables it. Setting this value to `True`, as proposed, would actually turn off Block at First Sight, directly contradicting the goal of enabling a protection feature. Block at First Sight is also a cloud-delivered capability that requires MAPS membership, so it is unrelated to the behavior monitoring setting that needs correction.

Set DisableRealtimeMonitoring to True to enable real-time monitoring.

Why it fails: `DisableRealtimeMonitoring` is currently `False`, which indicates real-time monitoring is already active, because `True` is the value that would disable it. Running `Set-MpPreference -DisableRealtimeMonitoring $true` would therefore stop real-time protection, worsening the device's security posture rather than fixing the behavior monitoring gap. While real-time monitoring and behavior monitoring are complementary Defender components, they are controlled by separate registry-backed policies and PowerShell parameters, so changing one does not affect the other.

Automated investigation will be triggered only for alerts with severity High, and email notifications will be sent to all admins.

Why it fails: The threshold for automated investigation is not limited to High severity. The policy uses a minimum severity level of Medium, which includes Medium and High (and Critical), so alerts at Medium severity would also trigger investigations. Furthermore, email notifications are sent only to admin@contoso.com as defined by the recipient list, not broadcast to all admins; the policy does not contain any setting to notify the global administrator or all tenant admins automatically.

Automated investigation will be disabled, and email notifications will be sent to admin@contoso.com.

Why it fails: The configuration actually enables automated investigation rather than disabling it. The policy likely contains an 'EnableAutomatedInvestigation' or similar setting set to true, which turns on the feature. While the notification part is correct—emails go to admin@contoso.com—the assertion that automated investigation is disabled contradicts the core functionality of the policy, so the overall statement is false.

Automated investigation will be triggered for all alerts regardless of severity, and no email notifications will be sent.

Why it fails: This option is false because the severity threshold is not set to all alerts; it is specifically configured for Medium and above, which excludes Low severity alerts. Additionally, email notifications are enabled and delivered to admin@contoso.com, contrary to the claim that no notifications are sent. The policy therefore filters by both severity and recipient, rather than investigating everything silently, so the behavior described here does not match the configuration.

Your users can use their Microsoft Authenticator app to sign in to partner tenants.

Why it fails: The default cross-tenant access policy controls integration and trust with external organizations, but it does not contain any setting that dictates or provisions Microsoft Authenticator for your users when they sign in to partner tenants. Authentication method selection is governed by the user's home tenant and the target tenant's authentication policies, not by cross-tenant access settings. The available settings are limited to inbound trust claims, outbound user restrictions, and B2B collaboration/direct connect rules, so the Authenticator app is not a configurable item here.

B2B direct connect is enabled for all external organizations.

Why it fails: The inbound direct connect section of the default policy is empty, meaning no B2B direct connect trust relationships are configured for any external organization. B2B direct connect is not enabled by default for all organizations; it requires explicit per-tenant configuration through organizational settings, and an empty inbound direct connect setting indicates that external organizations cannot directly access your Teams/SharePoint resources via this mechanism. Therefore, this statement is false.

Compliant device claims from external tenants are trusted.

Why it fails: The IsCompliantDeviceAccepted property is set to $false, so device compliance claims from external tenants are explicitly not trusted. As a result, conditional access policies that require a compliant device will not be satisfied by an external device's home-tenant compliance status. The user would need to register or enroll their device in your tenant and meet your device compliance policies to gain access.

An existing application registration is updated

Why it fails: Because the command's verb is `create`, not `update`, the CLI posts a new object to the Graph `applications` endpoint; there is no reference such as `--app-id` or `--object-id` that could select an existing registration for modification. `az ad app update` is the separate, explicit command that mutates an already-registered app, and it would be used with an identifier of the existing application. Here, the sole operation is a POST, so the result cannot be an updated existing registration.

The application is configured with single-tenant sign-in audience

Why it fails: The sign-in audience is determined by the `--sign-in-audience` parameter, and the value shown in the exhibit is `AzureADMultipleOrgs`, which indicates a multi-tenant application that accepts work or school accounts from any Microsoft Entra ID tenant. A single-tenant configuration would require the value `AzureADMyOrg`, restricting sign-in to users from the home tenant only. Since the exhibit explicitly uses the multi-tenant audience, this option misrepresents the app's tenancy.

An admin consent is granted for the Microsoft Graph permissions

Why it fails: Declaring permissions through `--required-resource-accesses` only creates the permission entries in the app registration; it does not grant admin consent. Admin consent requires a separate step, such as using the Azure portal's 'Grant admin consent' button, calling the `adminconsent` endpoint, or running `az ad app permission admin-consent`. Until that step is taken, the required permissions remain in an unconsented, pre-authorization state even though they are listed on the application.

Only users in a specific security group can create Microsoft 365 Groups

Why it fails: The directory setting GroupCreationAllowedGroupId is used to limit Microsoft 365 Group creation to members of a specific security group. In this scenario, that setting is empty, so no such restriction is active. Therefore, group creation is not limited to a specified security group; all users can create groups.

A naming policy is enforced for new groups

Why it fails: A naming policy for Microsoft 365 Groups requires a PrefixSuffixNamingRequirement (such as a fixed prefix or suffix) and optionally blocked words. The reported setting shows PrefixSuffixNamingRequirement is empty, meaning no group name pattern is enforced. Thus, new groups are not subject to a naming policy, making this option incorrect.

Groups must have a classification label

Why it fails: Classification labels for Microsoft 365 Groups rely on the DefaultClassification directory setting to assign a default label when none is chosen. With DefaultClassification empty, groups are created without an automatic classification, and the policy does not require users to select one. Consequently, requiring a classification label is not in effect.