Refer to the Exhibit Practice Questions

To set the retention period for the labeled content

Why it fails: The classification property groups labels by sensitivity category (for example, Personal or Public) so users see relevant labels; retention is governed by retention labels and policies instead. It is tempting because classification and retention are both label-adjacent governance concepts, and retention labels would be the correct choice when content must be kept or deleted on a schedule.

To define encryption settings for the label

Why it fails: Classification only organises labels into sensitivity categories; encryption is configured separately through the label's encryption settings. It is tempting because both appear on the same label configuration page, and encryption settings would be the correct choice when the requirement is to enforce Azure Rights Management protection on labelled content.

To define user permissions for accessing the content

Why it fails: Classification does not grant or restrict access; permissions come from the encryption settings applied to the label. It is tempting because sensitivity labels do influence access once encryption is enabled, and encryption permissions would be the correct choice when the goal is to limit who can open labelled content.

When the document is shared externally

Why it fails: Sharing the document externally is an activity-level event, but a content-based DLP rule condition does not automatically fire based on that event. Unless the policy explicitly includes the "Content is shared externally" condition, which is not shown in this rule, external sharing alone does not create a match. A document can be shared externally while containing no credit card number, leaving this rule inactive even though the sharing action occurred.

When any sensitive information type is detected

Why it fails: The rule does not say "any sensitive information type" — it is scoped specifically to the Credit Card Number SIT at high confidence. In Microsoft Purview DLP, administrators can combine multiple SITs using operators such as "Any of" or "All of," but the exhibit does not use that configuration. If the document contained a U.S. Social Security number or other sensitive info type, this rule would ignore it because the condition is restricted to credit card numbers.

Never, because the rule is not applied to any location

Why it fails: The exhibit shows only the rule's condition editor, not the overall policy configuration; in Purview DLP, location scopes such as Exchange, SharePoint, OneDrive, and Teams are assigned at the policy level, not inside the rule definition. Therefore, the absence of a location list in the rule view cannot prove that the policy is unapplied. A DLP policy is expected to have locations selected, and the default setup typically applies to common workloads, so concluding "never" from this screenshot is incorrect.

The policy only applies to administrators

Why it fails: This is incorrect because the policy's assignments include "All users," which explicitly covers every user in the directory, not just privileged roles like global administrators. Even if the user in question were an administrator, the policy would still apply to them, so the block cannot be attributed to any admin-only scope.

The user has not registered for MFA

Why it fails: Although the policy also requires MFA, the user is not blocked because they failed MFA—they are blocked because the device fails the compliance grant. If MFA registration were the issue, the sign-in would likely reach the MFA step and prompt for enrollment, but here the device compliance check occurs alongside MFA, and the non-compliant device is the unsatisfied condition.

The policy is disabled

Why it fails: The policy is not disabled; its state is shown as "Enabled" in the exhibit. An enabled policy actively evaluates every sign-in against its conditions. If the policy were disabled, it would not apply at all, and no grant controls would be enforced, so the user would not be blocked by it.

Allows access but logs the sign-in risk

Why it fails: The Conditional Access policy does not allow access under any circumstances when the sign-on risk is high; its grant control is set to 'Block access', which terminates the authentication session entirely. Therefore, there is no session to log as allowed, and sign-in risk events are recorded separately by Microsoft Entra ID Protection regardless of the policy outcome. Access is denied, not granted.

Requires multi-factor authentication for high-risk sign-ins

Why it fails: A grant control of 'Require multi-factor authentication' would challenge the user to complete MFA before access is permitted, but this policy's grant control is 'Block access'. Blocking is an explicit denial—no MFA challenge is issued because the sign-in is rejected based on the configured risk condition. You cannot combine block and MFA as grant controls in the same Conditional Access policy.

Blocks access to all cloud apps when sign-in risk is high

Why it fails: This policy's cloud apps assignment is specifically set to 'Office 365', which is a group of apps that includes Exchange Online, SharePoint Online, Teams, and other Office 365 services. It does not target 'All cloud apps', so it will not block access to non-Office 365 resources such as Microsoft Entra ID, Dynamics 365, or third-party SaaS apps. The scope is limited to Office 365 apps only, not the entire catalog of cloud apps.

Purchase fewer licenses next month to offset the unused count

Why it fails: Reducing next month's license count does not lower the current billing period already incurred; Microsoft 365 subscriptions are prepaid per seat, so the unused licenses remain billable through the end of the current term. It also ignores the immediate need to reclaim seats and may violate true-up obligations if your agreement is on a commit model.

Remove licenses from 30 users who have not logged in for 30 days

Why it fails: 30 days is too short to confirm an account is abandoned; legitimate users on parental leave, seasonal schedules, or project reassignments can exceed 30 days without signing in. Removing these licenses prematurely can interrupt business operations and force urgent re-licensing, which is why Microsoft-focused cost optimization guidance typically evaluates a much longer inactivity window, such as 90 days.

Reassign the 30 unused licenses to new users

Why it fails: Reassigning the seats to new users keeps the same license count and the same monthly cost, so the over-licensing problem remains. It may improve license utilization operationally, but it does not reduce spending; to actually lower costs, you must decrease the number of billed licenses by unassigning and not renewing them.

The app will be excluded from installation for the Contoso-Sales group.

Why it fails: If the Contoso-Sales group were excluded from installation, Intune would represent that with a separate exclusion assignment action, typically displayed in an 'Exclude' column or as a distinct exclusion rule in the assignment list. The exhibit shows AutoAssignment, which is a targeted, mandatory installation action, not an exclusion property. An exclusion would prevent the app from being installed on the group's devices, which is contrary to what AutoAssignment does.

The app will be available for users in the group to install from Company Portal.

Why it fails: The 'Available for enrolled devices' assignment type in Intune makes an app visible in Company Portal for users to install on demand. AutoAssignment, on the other hand, pushes the app silently and does not present it as an optional, user-initiated installation. The exhibit's AutoAssignment property therefore does not correspond to a Company Portal availability offer, so this option incorrectly describes the deployment mode.

The app will be assigned but requires user approval before installation.

Why it fails: Intune's Required/AutoAssignment deployment runs in the device context and does not require the user's approval or consent prior to installation. The Intune management agent enforces the policy during device check-in, and the app installs automatically without prompting the user. If user approval were actually needed, the deployment would use a different mechanism such as an Available assignment combined with user consent, not an automatic assignment as shown.

Allows access but prevents downloads from the specified IP range

Why it fails: The policy is configured with an access action of 'Block', not 'Allow'. An 'Allow' policy would explicitly grant access, whereas the exhibited rule uses 'Block' to deny requests from the specified IP range. Additionally, the 'Download' action is set to 'Block', so the policy not only prevents downloads but also blocks all access to the SharePoint site from that range.

Allows access to the SharePoint site only from the specified IP range

Why it fails: It misreads the policy's access decision. The rule is set to 'Block' access from the specified IP range, meaning it denies requests from that range, rather than restricting access to only that range. An 'Allow' access entry with a condition would be required to permit access solely from those IPs, but the exhibit clearly shows 'Block' as the access action.

Disables the policy for the SharePoint site

Why it fails: The policy's 'IsEnabled' property is set to 'True', indicating that the policy is actively enforced. A disabled policy would have 'IsEnabled' set to 'False' and would not apply any access or download restrictions. The exhibit shows no disabling condition, so the policy remains active for the SharePoint site.

External sharing is allowed only for existing guests who expire in 30 days.

Why it fails: This option misreads the policy. With 'sharingCapability' set to Disabled and 'allowExternalSharing' set to false, SharePoint blocks all external user invitations and external link sharing. An expiration period for guests is irrelevant because the overall sharing capability is disabled, so even existing guests cannot be extended or added, and their access would be revoked.

External sharing is allowed but guests expire after 30 days.

Why it fails: This option incorrectly assumes a guest expiration policy is configured. In the SharePoint admin center, external sharing expansion is governed by the sharing capability setting, not by a timeout. The value 'Disabled' means external sharing is entirely off, and any guest expiration policy would only apply if sharing were allowed, which is false here.

External sharing is allowed but only for users in the same tenant.

Why it fails: This option confuses internal collaboration with external sharing. Users in the same tenant are internal users, not external guests. The policy's Disabled setting prevents sharing with any user outside the organization, but internal sharing remains unaffected, so saying external sharing is allowed for same-tenant users is a contradiction and does not describe this policy.

Communication site

Why it fails: A communication site uses the SITEPAGEPUBLISHING#0 template, a publishing-focused modern template designed for broadcasting news and information to a broad audience. It does not use a Microsoft 365 group, so the exhibit's GROUP#0 identifier cannot be a communication site. The group-based template is the definitive mismatch.

Classic team site

Why it fails: A classic team site is provisioned with the STS#0 template, which is the legacy SharePoint team site model without a connected Microsoft 365 group. Since the exhibit shows GROUP#0 rather than STS#0, it is not a classic team site, because classic sites never carry the modern group-connected template identifier.

Hub site

Why it fails: A hub site is not a site template; it is an organizational feature that can be enabled on an existing communication site or team site. When you inspect site properties, a hub site still reports its original template ID, such as GROUP#0, and its hub association is stored separately in the HubSiteId property. Therefore, seeing GROUP#0 tells you the site type (group-connected team site), not that it is a hub site.

The retention policy is not effective

Why it fails: The retention policy is absolutely applied and effective. The PowerShell output shows a RetentionPolicy assignment (LegalHoldPolicy) with a retention hold enabled, so the policy is active. However, the presence of litigation hold (LitigationHoldEnabled: True) temporarily suspends the policy's deletion action, making it appear ineffective when it is actually being overridden by the hold.

The mailbox has no retention policy applied

Why it fails: The mailbox definitely has a retention policy applied. The output displays the RetentionPolicy property set to LegalHoldPolicy, which confirms the assignment. Litigation hold and retention policy are independent settings; having litigation hold enabled does not remove or negate the applied retention policy, so this statement is factually incorrect.

The mailbox will automatically delete items after 30 days

Why it fails: Litigation hold prevents automatic deletion of any mailbox items, regardless of the configured retention policy. A 30-day delete action from the retention policy would be suspended, and items would not be purged automatically. The output indicates litigation hold is enabled, so auto-deletion does not occur.

Only the user's display name and email.

Why it fails: The command does not request the mail or email property at all; it explicitly selects DisplayName, UserPrincipalName, AssignedLicenses, and UsageLocation. Additionally, userPrincipalName (UPN) is not the same as the user's SMTP email address, so saying 'email' misidentifies the property. The result also includes license assignments and usage location, which this option omits, making it incomplete and technically incorrect.

All properties of the user.

Why it fails: The command uses an explicit property selection that includes only four fields: DisplayName, UserPrincipalName, AssignedLicenses, and UsageLocation. Microsoft Graph PowerShell does not automatically return every Microsoft Entra ID user attribute; even its default response contains a limited property set. By explicitly selecting these four, the command restricts the output to exactly those properties and discards all other user attributes, so 'all properties' is factually wrong.

Only the user's display name.

Why it fails: The command actually returns three additional properties beyond the display name: UserPrincipalName, AssignedLicenses, and UsageLocation. Selecting only the display name would produce one column, but the output includes four distinct data fields. This option ignores the license assignment and location data, which are key licensing-related fields that the command is explicitly designed to retrieve.

user2 is not assigned any administrative role

Why it fails: The JSON shows that user2 has an eligible assignment for the Global Administrator role. This is a role assignment—it is not 'no role.' The assignment type is 'Eligible,' meaning user2 is listed as a potential holder of that administrative role, but the role is not active until activated. So the statement that user2 is not assigned any administrative role is factually incorrect because the assignment exists in Entra ID even if not yet activated.

user2 cannot access any administrative features

Why it fails: While an eligible Global Administrator does not have immediate access to administrative features, they are not permanently barred from them. User2 can initiate an activation request in Privileged Identity Management (PIM), and once approved/activated (with MFA and justification if required), they will gain the full permissions of Global Administrator for the duration of the activation. Therefore, 'cannot access any administrative features' is too absolute—eligible users can access them after a deliberate activation step.

user2 is permanently assigned the Global Administrator role

Why it fails: The assignment shown in the JSON is explicitly 'Eligible,' not 'Active.' An active assignment would grant permanent or long-term administrative rights immediately, but an eligible assignment requires activation each time and is usually time-limited. Calling it 'permanently assigned' misrepresents the PIM model, where eligible roles are idle until activated and then expire according to the activation duration policy.

The admin does not have the correct permissions.

Why it fails: The admin does not have the correct permissions. If the admin lacked sufficient RBAC permissions, the Get-CsTeamsMeetingPolicy cmdlet itself would typically throw an access-denied error. Successfully retrieving policy objects indicates the admin has at least read access, and likely has the Teams Communications Admin or Global Admin role needed to modify policies. The issue is not about access; it's about policy precedence.

The admin forgot to run a Grant-CsTeamsMeetingPolicy command.

Why it fails: The admin forgot to run a Grant-CsTeamsMeetingPolicy command. Grant-CsTeamsMeetingPolicy is only necessary when explicitly assigning a per-user policy to a specific user or group. The global policy is applied automatically to all users who do not have a per-user assignment, so no Grant command is needed for global changes. If the admin wanted to apply a custom policy to selected users, then Grant would be relevant, but the scenario is about the global policy being ineffective.

The AllowTranscription property is misnamed.

Why it fails: The AllowTranscription property is misnamed. AllowTranscription is a valid, documented property of the CsTeamsMeetingPolicy object in the Teams PowerShell module. If the property name were invalid, the Set-CsTeamsMeetingPolicy cmdlet would return a parameter-binding error before any change is made. The fact that the change appears to succeed but not affect users points back to a policy scope or precedence problem, not a property naming issue.

The user is granted access because the second policy requires MFA.

Why it fails: The statement is false because Conditional Access policies are evaluated as a set, and a grant control such as MFA in a second policy cannot override a block action in the first policy. Since the first policy explicitly blocks high-risk sign-ins, the user is denied even though the second policy would otherwise require MFA. No token is issued, so access is never granted.

The user is prompted for MFA due to the second policy.

Why it fails: The user does not receive an MFA prompt because the second policy's grant controls are never reached. In Conditional Access, when multiple policies apply, a block action takes precedence over grant controls; authentication is stopped before the service triggers MFA. Thus, the high-risk condition causes the session to be terminated at the block policy, and the MFA policy has no effect.

The user is allowed access but with session restrictions.

Why it fails: The user is not allowed access with session restrictions because session controls are enforced only after the user is granted access. A block policy, however, denies the sign-in before any grant or session control can be applied. Since the high-risk block policy is triggered, the sign-in is terminated entirely, leaving no session to enforce restrictions on.

Users from trusted IPs are blocked.

Why it fails: The policy's grant controls require MFA or a compliant device, and its conditions target locations; trusted IPs are not blocked by such a policy. It is tempting because location conditions can exclude trusted IPs, but that exclusion would appear as a separate, explicitly configured condition.

Users must provide MFA only.

Why it fails: The policy grants access only after MFA, but the exhibit also lists device compliance as an alternative grant control, so MFA alone is not the full requirement. It is tempting because MFA is the most visible control, yet the policy permits either MFA or a compliant device.

Users must provide MFA or use a compliant device.

Why it fails: The exhibit's grant control requires MFA, and a compliant device is a separate, alternative control, not a combined OR requirement shown here. It is tempting because both controls commonly appear together, but the policy as displayed enforces only the MFA grant.