Refer to the Exhibit Practice Questions

The secret will renew automatically.

Why wrong: Client secrets in Azure AD app registrations are security credentials that require explicit management. Unlike user passwords that might prompt for renewal, application secrets have a fixed expiration date and do not automatically extend or renew. Administrators or automated processes must proactively generate new secrets and update applications before the current ones expire to maintain service continuity and security.

The app registration will be automatically deleted.

Why wrong: The expiration of a client secret does not lead to the deletion of the entire app registration within Azure Active Directory. An app registration is the foundational identity object for an application, while a client secret is merely one of its associated credentials. The app registration itself, along with its configuration, permissions, and any other valid credentials, will remain intact and functional.

The app will be blocked from signing in.

Why wrong: An application will not necessarily be blocked from signing in simply because one of its client secrets has expired. App registrations can be configured with multiple credentials, such as several client secrets with staggered expiration dates or X.509 certificates. If other valid credentials exist, the application can still successfully authenticate and acquire tokens using those alternatives, ensuring continued operation.

Block access for Global Administrators unless they use MFA

Why wrong: The policy's "Grant" control is explicitly configured to "Require multifactor authentication," which mandates that users must successfully complete an MFA challenge to gain access. It does not select the "Block access" control, which would unconditionally deny access regardless of MFA status. Therefore, the policy enforces the use of MFA as a condition for access, rather than outright blocking access if MFA is not presented. This distinction is crucial for understanding the policy's effect.

Require MFA for all users

Why wrong: This statement is incorrect because the conditional access policy's "Users and groups" assignment is precisely scoped to "Directory roles" and then specifically to "Global Administrator." This configuration ensures that the policy's conditions and access controls apply exclusively to accounts holding the Global Administrator role, rather than encompassing all users within the Microsoft Entra tenant. Therefore, it does not require MFA for every user.

Require MFA for users accessing the Microsoft Entra admin center only

Why wrong: The conditional access policy's "Cloud apps or actions" condition is configured to include "All cloud apps" rather than specific applications. This broad scope dictates that the policy applies to every application integrated with Microsoft Entra ID, not solely to the Microsoft Entra admin center. If the policy were intended to target only the admin center, specific applications would need to be explicitly selected within the "Cloud apps or actions" condition.

Blocks sign-ins for users with high user risk

Why wrong: This statement is incorrect because the conditional access policy explicitly targets "sign-in risk levels" and not "user risk levels." User risk, which assesses the likelihood of a user account being compromised over time, is a distinct condition evaluated by Azure AD Identity Protection. For this policy to block based on user risk, the UserRiskLevels condition would need to be configured with "High" selected, which is not the case in this scenario.

Blocks all sign-ins for the assigned users

Why wrong: This statement is incorrect because the policy does not impose an unconditional block on all sign-ins for assigned users. Instead, it is a conditional access policy that only triggers its "Block access" grant control when a specific condition, namely a "High" sign-in risk level, is met. Legitimate sign-ins from assigned users that do not exhibit high risk will proceed without being blocked by this particular policy.

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

Why wrong: This statement is incorrect because the conditional access policy's "Grant" controls are configured to "Block access," not to "Require multi-factor authentication." While requiring MFA is a common and effective response to high-risk sign-ins to verify identity, this specific policy is designed to prevent access entirely rather than allowing it after an additional authentication challenge.

Top 10 alert titles by number of distinct devices, including all severities

Why wrong: This option is incorrect because the typical Kusto query for this scenario would include a `where AlertSeverity == 'High'` clause, explicitly filtering for high-severity alerts only. This filter contradicts the option's claim of 'including all severities,' as the query's scope is intentionally narrowed to a specific severity level. Therefore, the results would not encompass alerts of medium, low, or informational severities.

Top 10 devices with the most high-severity alerts

Why wrong: This option is incorrect because a query designed to find the 'Top 10 devices' would require the `summarize` operator to group results `by DeviceName`, not `by AlertTitle`. Grouping by `AlertTitle` instead means the aggregation is counting occurrences or distinct devices *per alert type*, not aggregating the total impact or alerts *per individual device*. Consequently, the output would list alert titles, not device names, as the primary ranked entities.

Top 10 high-severity alert titles by total number of alerts

Why wrong: This option is incorrect because it specifies 'total number of alerts,' which would typically be calculated using the `count()` aggregation function. However, the correct query for 'distinct affected devices' utilizes `dcount(DeviceName)`, which counts only unique device entries. Using `dcount` instead of `count` means the query is measuring the breadth of impact (unique devices) rather than the sheer volume of alert instances, making this option an inaccurate description of the query's output.

The user's license assignments

Why wrong: The Microsoft Graph PowerShell command specified in the exhibit explicitly targets the SignInActivity property of a user object. Retrieving license assignments would require selecting the 'assignedLicenses' property or using a dedicated cmdlet like Get-MgUserLicenseDetail. Since the command does not include these specific properties or cmdlets, it will not return any information regarding the user's assigned licenses.

The user's assigned roles

Why wrong: The command focuses solely on the SignInActivity property, which is distinct from a user's administrative role assignments. To retrieve a user's assigned roles, such as Global Administrator or User Administrator, the command would need to explicitly query the 'appRoleAssignments' or 'directoryRoles' relationships, or utilize cmdlets like Get-MgUserAppRoleAssignment or Get-MgDirectoryRoleMember. The current command's scope does not encompass this information.

The user's group memberships

Why wrong: The SignInActivity property provides authentication data and has no direct correlation with a user's group memberships. To ascertain which security or Microsoft 365 groups a user belongs to, the Microsoft Graph PowerShell command would need to query the 'memberOf' relationship or use specific cmdlets like Get-MgUserMemberOf. The command in question lacks the necessary parameters or property selections to retrieve group membership details.

To create a new service principal.

Why wrong: The `az login --service-principal` command is designed for authenticating an *existing* service principal, not for creating a new one. Creating a service principal typically involves using commands like `az ad sp create-for-rbac` or through the Azure portal, which provisions the identity and assigns necessary permissions. This specific command assumes the service principal's credentials (application ID and client secret or certificate) are already established and are being used to initiate a session.

To list all Azure subscriptions.

Why wrong: The `az login --service-principal` command's primary function is to establish an authenticated session with Azure using a service principal's credentials. It does not, by itself, list Azure subscriptions or any other resources. Once successfully logged in, subsequent Azure CLI commands, such as `az account list`, would then be used to enumerate accessible subscriptions and other resources within the authenticated context.

To log in to Azure as a user with MFA.

Why wrong: The `--service-principal` flag explicitly indicates that the authentication is for an application identity, not a human user. Therefore, this command bypasses interactive user login flows, including those that would prompt for Multi-Factor Authentication (MFA). User logins, especially those requiring MFA, typically involve `az login` without the `--service-principal` flag, often opening a browser for interactive authentication.

The -Settings parameter is deprecated.

Why wrong: The -Settings parameter is a valid and active parameter within the Microsoft Graph PowerShell module, particularly when managing information protection policies or related configurations. If the parameter were deprecated, the command would typically return a specific warning indicating its obsolescence or an error stating the parameter is unrecognized, rather than an issue related to the retrieval of sensitivity labels. Its validity is not the cause of the problem.

The user does not have permissions to view labels.

Why wrong: If the user lacked the necessary permissions to view sensitivity labels, the PowerShell command would typically return an explicit "Access Denied," "Authorization Failed," or similar permission-related error message. The problem described (implicitly, that labels are not returned or found) indicates a fundamental mismatch in the cmdlet's function, suggesting the command is looking in the wrong place or for the wrong object type, rather than being blocked by insufficient user rights.

The label name is misspelled.

Why wrong: While a misspelled label name could certainly prevent a specific label from being found, the primary issue here is the incorrect cmdlet usage. If the cmdlet itself is not designed to retrieve sensitivity labels, even a perfectly spelled label name would not yield results. The error would stem from the command's inability to query for labels, rather than a specific label not matching a provided string.

Add Exchange Online to the locations.

Why wrong: Adding Exchange Online as a location for a retention policy would include email messages, calendar items, and other mailbox content. However, the requirement specifically states the legal team needs to preserve "all documents," which primarily reside in SharePoint Online and OneDrive for Business. Including Exchange Online would unnecessarily broaden the scope of the retention policy beyond the stated requirement, potentially increasing the volume of data under preservation and the complexity of eDiscovery efforts without addressing the core need for document preservation.

Change the retention type to Delete.

Why wrong: Changing the retention type to "Delete" would configure the policy to permanently remove content after a specified period, or immediately if no period is set. This action directly contradicts the legal team's requirement to "preserve" all documents. Retention policies are designed to ensure data immutability and availability for legal or regulatory purposes, whereas a "Delete" action serves to dispose of content, making it unsuitable for a preservation mandate.

Change the retention action to KeepAndDelete.

Why wrong: The "KeepAndDelete" retention action is designed to preserve content for a specified duration and then automatically delete it. If the existing retention policy already has this action configured, changing *to* KeepAndDelete would be redundant and would not resolve the underlying issue. The problem statement implies a need to adjust the *length* of preservation, not the fundamental action of preserving and then deleting, making the duration the critical parameter to modify.

The policy targets high sign-in risk

Why wrong: The policy does not target high sign-in risk because the `riskLevels` condition, which is part of the `conditions` block in a Conditional Access policy, is not specified or configured to include "high" sign-in risk. Without an explicit `riskLevels` configuration, the policy will not evaluate or enforce controls based on the sign-in risk detected by Azure AD Identity Protection, meaning it applies irrespective of the user's sign-in risk level.

The policy does not apply to Exchange Online

Why wrong: The statement is incorrect because Conditional Access policies define their scope through the `applications` condition. If the JSON exhibit explicitly lists "Exchange Online" within the `applications` array, it signifies that the policy *is* configured to apply to user access attempts for Exchange Online. Therefore, any user attempting to access Exchange Online while matching other policy conditions would be subject to its controls.

The policy requires device compliance

Why wrong: The statement is incorrect because requiring device compliance is a specific grant control that must be explicitly configured within the `grantControls` section of a Conditional Access policy. If the policy's `grantControls` array does not contain `requireDeviceCompliant`, the policy will not enforce that the accessing device meets compliance standards managed by Intune or other MDM solutions. Therefore, users can access resources from non-compliant devices under this policy.

The email is delivered normally because TeamsChatAndChannel is false.

Why wrong: This statement is incorrect because the `TeamsChatAndChannel` location setting only governs DLP policy application within Microsoft Teams. Email, handled by Exchange Online, is a distinct workload. Since the policy's `Exchange` location is enabled (as implied by the correct outcome), the DLP policy will evaluate emails regardless of the Teams setting, and therefore, email delivery is not determined by `TeamsChatAndChannel` being false.

The email is delivered but an alert is generated.

Why wrong: This is incorrect because the DLP policy explicitly defines `BlockAccess` as the primary action when a sensitive information type is detected in email. While an alert or incident report might also be generated (via `IncidentReport` being true), the most impactful action is to prevent the email from being delivered, not to allow delivery with just an alert or audit log entry.

The email is encrypted before delivery.

Why wrong: This is incorrect because the DLP policy's configured action is `BlockAccess`, which prevents the email from being delivered entirely. While Microsoft Purview DLP policies can be configured to encrypt emails as an action, this specific policy does not specify encryption. The `Encrypt` action would need to be explicitly enabled in the policy rule for encryption to occur instead of blocking the communication.

Sign-ins with high sign-in risk from any location

Why wrong: The rule's logic includes both medium and high sign-in risk levels, not exclusively high risk. Furthermore, the condition explicitly filters for sign-ins originating from *outside* the US, meaning that 'any location' is incorrect as it would encompass US locations which are specifically excluded by the actual rule's criteria.

Sign-ins with medium or high risk from the US

Why wrong: While the specified risk level condition of medium or high sign-in risk aligns with the query's intent, the location condition is fundamentally incorrect. The rule explicitly excludes sign-ins originating from the United States, focusing instead on activities from international locations to detect potential threats and anomalous access patterns.

Sign-ins from users with high user risk outside the US

Why wrong: This option incorrectly references 'user risk' instead of 'sign-in risk.' Azure AD Identity Protection clearly distinguishes between these two types of risk; the rule specifically evaluates the risk associated with the sign-in attempt itself, rather than the cumulative, historical risk profile of the user account.

The policy name is incorrect.

Why wrong: The question stem explicitly states "the exhibit shows a conditional access policy named block l," which implies the policy's name is clearly displayed as "Block Legacy Auth" or a similar variant in the exhibit. Therefore, asserting that the policy name itself is incorrect contradicts the premise that the name is visible and identifiable as intended for its purpose within the context of the provided exhibit.

The policy is assigned to no users.

Why wrong: Conditional Access policies require user assignment to be effective. While the "Users" property might not be explicitly shown in a partial exhibit, it is highly improbable for a policy intended to block legacy authentication to be assigned to "No users." By default, or in common configurations, such a policy would typically target "All users" or specific groups to enforce its controls, making the statement that it's assigned to no users incorrect without explicit evidence.

The policy is disabled.

Why wrong: Conditional Access policies have a "State" property that indicates whether they are "On," "Off," or "Report-only." If a policy is merely listed as part of an exhibit without an explicit indication of its state being "Off" or "Disabled," it is generally assumed to be active or in report-only mode. A disabled policy would typically not be considered an active component of the security posture, and its state would be clearly indicated as such within the policy details.

Configure self-service password reset settings.

Why wrong: The provided script does not interact with cmdlets or APIs related to configuring Self-Service Password Reset (SSPR) policies or settings within Microsoft Entra ID. SSPR configuration typically involves defining authentication methods required for reset, enabling the feature for specific user groups, and setting up notification preferences, which are distinct administrative actions from merely registering a user's phone number.

Reset passwords for all users named John.

Why wrong: The PowerShell script's primary action, `New-MgUserAuthenticationPhoneMethod`, is exclusively for adding a phone number as an authentication method for a user within Microsoft Entra ID. It does not contain any commands or logic to initiate a password reset for any user, regardless of their name or other attributes. Password resets would typically involve cmdlets like `Reset-MgUserPassword` or similar administrative functions.

Enable multifactor authentication for the users.

Why wrong: While registering a phone authentication method is often a prerequisite for certain multifactor authentication (MFA) methods, such as SMS or voice call verification, the script itself does not enable MFA for users. Enabling MFA involves configuring Conditional Access policies or per-user MFA settings in Microsoft Entra ID, which are distinct administrative actions that determine when and how MFA is enforced for user sign-ins.

LateralMovement and PrivilegeEscalation

Why wrong: This option is incorrect because the alert details, as presented in the exhibit, do not include any indicators or activities corresponding to the Privilege Escalation tactic. While Lateral Movement might be present, the inclusion of Privilege Escalation, which involves an adversary attempting to gain higher-level permissions on a system or network, makes this combination an inaccurate representation of the observed alert. The exhibit specifically highlights different tactical objectives.

LateralMovement and Exfiltration

Why wrong: This option is incorrect because the Exfiltration tactic is not identified within the security alert's details. Exfiltration involves the adversary stealing data from the network, typically by compressing, encrypting, or otherwise packaging it for removal. Although Lateral Movement might be a component of the alert, the absence of any evidence suggesting data theft means this option does not accurately reflect the complete set of tactics observed.

InitialAccess and Persistence

Why wrong: This option is incorrect because the alert does not indicate any activities related to the Persistence tactic. Persistence describes techniques adversaries use to maintain their foothold in an environment across reboots, credential changes, or other interruptions, such as installing backdoors or creating new accounts. While Initial Access is correctly identified as a tactic, the lack of evidence for maintaining long-term access makes the inclusion of Persistence inaccurate for this specific alert.

Create an analytics rule for ransomware

Why wrong: Analytics rules in Microsoft Sentinel are primarily designed to detect threats and generate security incidents and alerts based on scheduled queries or near real-time data streams. While essential for identifying ransomware activity, their function is limited to detection and notification. They do not inherently provide mechanisms to automate response actions or trigger remediation playbooks directly upon alert generation, making them unsuitable for orchestrating an automated response.

Create a hunting query for ransomware

Why wrong: A hunting query in Microsoft Sentinel is a KQL query used by security analysts for proactive, manual threat hunting and investigation across ingested logs. This process involves interactively searching for indicators of compromise or suspicious patterns that might have bypassed automated detections. Hunting is an investigative activity focused on discovery and understanding, not on automatically executing predefined response actions or playbooks when a threat is identified.

Create a workbook to display ransomware alerts

Why wrong: Microsoft Sentinel workbooks serve as flexible dashboards for visualizing and monitoring security data, including alerts, incidents, and logs from various sources. They enable security teams to create custom reports and gain insights into the security posture and threat landscape, such as ransomware activity. However, workbooks are purely a presentation and analysis tool; they do not possess any functionality to trigger automated responses or execute remediation workflows.