C.   defense in depth

Explanation:
Defense in depth is a security strategy that employs a series of layered, redundant defensive mechanisms to protect valuable data and information. If one layer fails, another layer steps up to prevent an attack. Placing multiple layers of defense throughout a network infrastructure is the very definition of this approach. These layers can include:
Physical security
Perimeter security (firewalls)
Network security (segmentation)
Endpoint security
Application security
Data security (encryption)

Why the other options are incorrect:
A. threat modeling:
This is a structured process for identifying, quantifying, and addressing the security risks associated with an application or system. It's a planning and analysis exercise, not the implementation of layered defenses.
B. identity as the security perimeter:
This is a modern security concept that argues the primary security boundary is no longer the physical network but the user and device identity. While identity controls are a critical layer in a defense-in-depth strategy, this term describes a specific philosophy, not the overarching methodology of multiple layers throughout the infrastructure.
D. the shared responsibility model:
This model clarifies the security responsibilities between a cloud provider (like Microsoft) and the cloud customer. It defines who is responsible for securing what, but it is not the methodology for how to implement those security controls (which is defense in depth).

Reference:
Microsoft Learn:
What is defense in depth? - "Defense in depth is a strategy that employs a series of mechanisms to slow the advance of an attack aimed at acquiring unauthorized access to information." The article goes on to describe the multiple layers used in this approach.

C.   integration with Microsoft 365 Defender

Explanation:
Extended Detection and Response (XDR) is a platform approach that unifies security data from multiple sources (like endpoints, email, identity, and applications) into a single system to improve threat detection, investigation, and response.
Azure Sentinel's integration with Microsoft 365 Defender is what provides its core XDR capability. Microsoft 365 Defender is itself an XDR solution that consolidates signals from Microsoft Defender for Endpoint, Microsoft Defender for Office 365, Microsoft Defender for Identity, and Microsoft Defender for Cloud Apps. By connecting this unified XDR platform to the broader SIEM (Azure Sentinel), you extend the visibility and correlation across your entire digital estate, including non-Microsoft data sources.

Why the other options are incorrect:
A. integration with the Microsoft 365 compliance center:
This integration is for compliance and data governance management, not for cross-domain security detection and response (XDR).
B. support for threat hunting:
While threat hunting is a critical capability of Azure Sentinel, it is a function that benefits from XDR data but is not the feature that provides the XDR capability itself. Hunting can be done on any data in the SIEM.
D. support for Azure Monitor Workbooks:
Workbooks are tools for data visualization and dashboarding. They are used to present data, including security data, but they do not provide the underlying XDR capability of ingesting and correlating unified signals from multiple security domains.

Reference:
Microsoft Learn:
Microsoft 365 Defender integration with Microsoft Sentinel - "Microsoft 365 Defender integration with Microsoft Sentinel... provides a more consolidated and streamlined experience for Secure XDR (Extended Detection and Response) and SIEM... This integration allows you to... ingest advanced hunting events from M365D into your Microsoft Sentinel workspace."

Explanations:

1. Statement: You can create custom roles in Azure Active Directory (Azure AD).
Answer: Yes
Explanation: This is true. Azure AD supports custom roles for both application administration and for delegating permissions for managing Azure AD resources. This allows you to create roles with granular, specific permissions that are not covered by the built-in administrator roles.

2. Statement: Global administrator is a role in Azure Active Directory (Azure AD).
Answer: Yes
Explanation: This is true. The Global Administrator (also known as Global Admin) is the highest-level built-in role in Azure AD. A user with this role has access to all administrative features in Azure AD and services that use Azure AD identities.

3. Statement: An Azure Active Directory (Azure AD) user can be assigned only one role.
Answer: No
Explanation: This is false. A single user can be assigned multiple Azure AD administrator roles. For example, a user could be assigned both the User Administrator role and the Groups Administrator role simultaneously. Their effective permissions would be the combined permissions of all assigned roles.

Reference:
Custom Roles:
Microsoft Learn - Custom roles in Azure Active Directory - "Azure AD lets you create custom roles to manage Azure AD resources."
Global Administrator:
Microsoft Learn - Azure AD built-in roles - Global Administrator - "Users with this role have access to all administrative features in Azure Active Directory..."
Multiple Role Assignments:
This is a fundamental principle of Azure AD role-based access control (RBAC). The administrative experience in the Azure portal allows you to assign multiple roles to a single user, and the user's permissions are cumulative.

B.   sensitivity labels

Explanation:
Sensitivity labels in Microsoft 365 are designed to classify and protect sensitive content. A key protection capability is encryption. You can configure a sensitivity label to automatically apply encryption with specific permissions when the label is applied to a document or email.
Conditions for automatic encryption:
You can set rules so that encryption is applied based on conditions you define. For example, you can create a label that automatically encrypts any document containing a credit card number.
User-applied encryption:
Even without automatic conditions, when a user manually applies a sensitivity label that includes encryption settings, the content is encrypted.

Why the other options are incorrect:
A. Content Search:
This is a tool within the Purview compliance portal for finding content across Microsoft 365 locations (like Exchange, SharePoint, OneDrive). It is used for discovery and investigation, not for applying protection like encryption.
C. Retention policies:
These policies are used to decide how long to retain content, and whether to delete it after a period. Their purpose is records management and information governance, not encryption. They control the lifecycle of content but do not encrypt it.
D. eDiscovery:
This is a legal workflow tool used to identify, hold, and export content for use as evidence in legal cases. It is a process for finding and preserving information, not for protecting it with encryption.

Reference:
Microsoft Learn: Apply encryption using sensitivity labels - "You can configure sensitivity labels to apply encryption to email and documents. This encryption protects the content in transit and at rest, and the content remains encrypted in Outlook... as well as in other apps and services." The ability to use "auto-labeling" policies to apply these labels (and their encryption) based on conditions is a core feature.

A.   text message (SMS)

B.   Microsoft Authenticator app

D.   phone call

Explanation:
Azure Multi-Factor Authentication (MFA) is a critical security feature within Microsoft Entra ID (formerly Azure Active Directory) that requires users to provide two or more forms of verification to access resources. MFA reduces the risk of unauthorized access due to compromised credentials by combining multiple authentication factors such as something you know (password), something you have (mobile device), and something you are (biometric verification).
Microsoft supports several verification options for Azure MFA to ensure users can authenticate securely and conveniently.

1. Text message (SMS) – Correct (Option A)
Azure MFA supports authentication via text messages (SMS) sent to a user’s registered phone number. When a user attempts to sign in, Azure sends a one-time verification code (OTP) via SMS. The user must enter this code correctly to complete authentication. This method is widely used for simplicity and accessibility because it does not require a smartphone or internet access, only a device capable of receiving text messages.
However, while SMS-based MFA provides a second layer of defense, it is less secure than app-based or phone call authentication because SMS messages can be intercepted or redirected through SIM-swapping attacks. Nonetheless, it remains an officially supported and valid method within Azure MFA.
Reference:
Microsoft Learn – Azure AD MFA verification methods

2. Microsoft Authenticator App – Correct (Option B)
The Microsoft Authenticator app is the most secure and recommended method for MFA. It provides two main verification mechanisms:
Push notifications that the user approves with a simple tap.
Time-based one-time passwords (TOTP) generated by the app even without an internet connection.
The Authenticator app leverages strong cryptography and device registration to ensure high assurance. It also supports number matching and location context for additional security, minimizing phishing risks. Because of its strong security posture and ease of use, Microsoft promotes this method as the primary MFA option for enterprise environments.
Reference:
Microsoft Learn – How it works: Azure AD Multi-Factor Authentication

3. Phone call – Correct (Option D)
Azure MFA also allows authentication through an automated phone call to the user’s registered number. The system prompts the user to answer the call and press a key to confirm their identity. This method is effective when mobile data or internet connectivity is limited, making it a useful backup to the Microsoft Authenticator app.
While convenient, it is less secure compared to app-based verification because it relies on telephony networks, which can be targeted for social engineering or call interception. Despite that, it remains a fully supported MFA method in Microsoft Entra ID.
Reference:
Microsoft Learn – Azure AD MFA verification methods

4. Email verification – Incorrect (Option C)
Email verification is not supported as an Azure MFA method. Email is only used for password resets or communication, not for multi-factor authentication. The reason is that email relies on username and password, which does not qualify as a “second factor.” Using email would not provide additional assurance because it depends on the same credentials MFA is designed to protect.
Reference:
Microsoft Learn – Authentication methods in Microsoft Entra ID

5. Security question – Incorrect (Option E)
Security questions are also not supported by Azure MFA. They are considered a weak authentication method because answers can often be guessed or obtained through social engineering or public information. Microsoft does not include this method in Azure MFA since it fails to meet modern security standards. Security questions might appear in legacy systems but not in Microsoft Entra MFA.
Reference:
Microsoft Learn – Microsoft Entra authentication methods

Summary
Azure MFA strengthens identity protection by enforcing multiple verification options. The valid methods — SMS (A), Microsoft Authenticator app (B), and Phone call (D) — provide flexible, layered authentication to secure access to Azure and Microsoft 365 resources. Methods like email and security questions are not supported because they do not meet MFA’s security standards.

Explanations:

1. Statement: Microsoft Defender for Endpoint can protect Android devices.
Answer: Yes
Explanation: This is true. Microsoft Defender for Endpoint is a cross-platform endpoint security solution. While it started with a focus on Windows, it now extends its threat and vulnerability management capabilities to other major platforms, including Android, iOS, and macOS.

2. Statement: Microsoft Defender for Endpoint can protect Azure virtual machines that run Windows 10.
Answer: Yes
Explanation: This is true. Microsoft Defender for Endpoint is a primary tool for protecting endpoints, including both physical devices and virtual machines. You can deploy the Defender for Endpoint sensor on Azure VMs running Windows 10 to provide advanced threat detection, investigation, and response capabilities.

3. Statement: Microsoft Defender for Endpoint can protect Microsoft SharePoint Online sites and content from viruses.
Answer: No
Explanation: This is false. The protection for SharePoint Online, OneDrive, and Microsoft Teams against viruses and malware is provided by Microsoft Defender for Office 365, specifically its "Safe Attachments for SharePoint, OneDrive, and Microsoft Teams" feature. Defender for Endpoint is focused on securing user devices (endpoints), not cloud-based collaboration storage.

Reference:
Android & Cross-Platform Support:
Microsoft Learn - Microsoft Defender for Endpoint on Android - "Microsoft Defender for Endpoint on Android enables your workforce to work securely and productively on their mobile devices."
Protecting Azure VMs:
Microsoft Learn - Onboard Windows servers to the Microsoft Defender for Endpoint service - This includes guidance for onboarding Azure VMs.
SharePoint Online Protection:
Microsoft Learn - Safe Attachments for SharePoint, OneDrive, and Microsoft Teams - "Safe Attachments for SharePoint, OneDrive, and Microsoft Teams... protects your organization when users collaborate and share files." This is a feature of Defender for Office 365.

Explanations:

1. Statement: With Advanced Audit in Microsoft 365, you can identify when email items were accessed.
Answer: Yes
Explanation:
This is true. A key capability of Advanced Audit is providing access to crucial events for internal investigations and forensic activities. This includes the MailItemsAccessed event, which is a critical piece of evidence for determining the scope of a potential email breach, as it helps identify when mail items in a mailbox were accessed.

2. Statement: Advanced Audit in Microsoft 365 supports the same retention period of audit logs as core auditing.
Answer: No
Explanation:
This is false. A primary difference between core (basic) auditing and Advanced Audit is the retention period:
Core Auditing: Retains audit records for 90 days (or 1 year for certain E3 subscriptions).
Advanced Audit: Extends the retention of audit records for up to 1 year (for E5) or 10 years (with an add-on license), which is crucial for long-term investigations and compliance.

3. Statement: Advanced Audit in Microsoft 365 allocates customer-dedicated bandwidth for accessing audit data.
Answer: Yes
Explanation:This is true. To support high-volume access to audit logs, especially when using APIs for large-scale investigations, Advanced Audit provides increased bandwidth allowances. This ensures that organizations can retrieve large sets of audit data in a timely manner without being throttled, which is a limitation with core auditing.

Reference:
Microsoft Learn:
Advanced Audit in Microsoft 365 - "Advanced Audit helps organizations to... conduct forensic and other investigations by providing access to crucial events such as MailItemsAccessed and Send." ... "Longer retention of audit records: Advanced Audit retains all Exchange, SharePoint, and Azure Active Directory audit records for one year (for E5) and 10 years (with an add-on)." ... "Access to crucial events for forensic investigations... and higher bandwidth for accessing the Office 365 Management Activity API."

Explanations:

1. Statement: Azure Active Directory (Azure AD) Identity Protection can add users to groups based on the users’ risk level.
Answer: No
Explanation: This is false. Identity Protection itself does not have a direct action to add users to groups. Its primary remediation and mitigation actions are focused on identity security, such as requiring a password change, requiring MFA, or blocking sign-in. While you could theoretically use a risk detection as a trigger for a separate automation (like a PowerShell script or a workflow in Logic Apps) that adds a user to a group, this is not a native, out-of-the-box capability of Identity Protection.

2. Statement: Azure Active Directory (Azure AD) Identity Protection can detect whether user credentials were leaked to the public.
Answer: Yes
Explanation: This is true. This is a specific and core risk detection type in Identity Protection called Leaked credentials. Microsoft proactively searches the web and the dark web for publicly available username and password pairs. If a match is found for a user in your tenant, it triggers a risk detection, allowing you to force a password reset.

3. Statement: Azure Active Directory (Azure AD) Identity Protection can be used to invoke Multi-Factor Authentication based on a user’s risk level.
Answer: Yes
Explanation: This is true. This is a fundamental feature of Identity Protection's risk-based policies, specifically the Sign-in risk policy. You can configure this policy so that if a sign-in is deemed medium or high risk (e.g., from an anonymous IP address or an unfamiliar location), the user will be required to pass Multi-Factor Authentication to complete the sign-in, proving their identity.

Reference:
Microsoft Learn:
What is Identity Protection? - Risk - Lists "Leaked credentials" as a user risk detection type.
Microsoft Learn: How To:
Configure and enable risk policies - Describes configuring the Sign-in risk policy where you can choose "Require MFA" as a control and the User risk policy where you can choose "Require password change" as a control. Group management is not listed as a control.

D.   

a connector

Explanation:
To on-board Azure Sentinel, you first need to connect to your security sources. Azure
Sentinel comes with a number of connectors for Microsoft solutions, including Microsoft
365 Defender solutions, and Microsoft 365 sources, including Office 365, Azure AD,
Microsoft Defender for Identity, and Microsoft Cloud App Security, etc.
Reference:
https://docs.microsoft.com/en-us/azure/sentinel/overview