Explanation:
This question tests the ability to identify which passwordless authentication method is being described. The phrase "matching a number shown in the app with a number shown on their phone" is the specific user experience for number matching in the Microsoft Authenticator app passwordless sign-in flow. The user sees a number on their sign-in screen and must select the matching number in their Authenticator app notification. The table shows this method is enabled for Group1.

Correct Option:

A. User1 only.
This is correct. The described experience is the Microsoft Authenticator app passwordless (or MFA) sign-in with number matching. This method is enabled for Group1. User1 is a member of Group1 and will use this method. User2 is in Group2 (FIDO2), and User3 is in Group3 (SMS), which do not use this specific number-matching app experience.

Incorrect Options:

B. User2 only:
Incorrect. User2 is targeted for FIDO2 security key authentication. This method involves tapping a physical key or using device biometrics, not matching numbers in an app.

C. User3 only:
Incorrect. User3 is targeted for SMS authentication. This method involves receiving a code via text message and entering it, not matching numbers within an app.

D. User1 and User2 only:
Incorrect. User2 uses FIDO2, which does not involve the Authenticator app number-matching process.

E. User2 and User3 only:
Incorrect. Neither FIDO2 nor SMS authentication uses the described number-matching in the Microsoft Authenticator app.

Reference:
Microsoft Learn, "How to use the Microsoft Authenticator app - Passwordless sign-in." The documentation describes the passwordless sign-in flow where the user is prompted to "enter the number shown on the sign-in screen" into their Authenticator app.

Explanation:
This question tests understanding of Conditional Access policy assignments. The policy (Policy1) requires MFA but has no assignments specified under "Users or workload identities." The key detail is that the exhibit shows the policy configuration is incomplete; there is no user/group assignment defined. A Conditional Access policy must have assignments to target specific users or groups. Without any assignments, the policy does not apply to anyone, even Global Administrators.

Correct Options:

Statement 1 (User1):
No. Policy1 has no user/group assignments, so it does not apply to User1.

Statement 2 (User2):
No. Policy1 has no user/group assignments, so it does not apply to User2, regardless of their group memberships.

Statement 3 (User3):
No. Policy1 has no user/group assignments. While User3 is a Global Administrator, there is no baseline policy or other rule shown that enforces MFA for admins. Therefore, MFA is not required based on the given information.

Incorrect Options:
Marking "Yes" for any statement would incorrectly assume the policy is active. The critical point is that an unassigned Conditional Access policy does not enforce any controls.

Reference:
Microsoft Learn, "Conditional Access: Conditions - What conditions are in Conditional Access." A Conditional Access policy requires configuration in the Assignments section (Users and groups, Cloud apps, Conditions). If the "Users and groups" assignment is left empty (not configured), the policy does not target any users and is effectively inactive. The policy in the exhibit has no target specified in the assignments.

Explanation:
This question tests navigation within Microsoft Entra Permissions Management to perform specific tasks. Permissions Management has dedicated tabs for different types of analysis. The Analytics tab is the central hub for role-based identity analytics, including discovering permanent role assignments. The Reporting tab provides detailed reports, including the Permission Creep Index (PCI) for individual identities.

Correct Options:

Identify all the accounts that are assigned the Global Administrator role permanently: Analytics
The Analytics tab provides data analysis dashboards that allow you to filter and view identities by their assigned roles (like Global Administrator) and by assignment type (permanent vs. eligible). You can use this to generate a list of accounts with permanent global admin assignments.

Review the Permission Creep Index (PCI) of User1: Reporting
The Reporting tab contains pre-built and customizable reports. The Permission Creep Index (PCI) report is found here. You can run this report for a specific time range and filter by identity (User1) to review their PCI score, which indicates excessive or unused permissions over time.

Incorrect Options:

Audit:
This tab shows activity logs and audit trails of actions taken within Permissions Management, not for analyzing role assignments or PCI scores.

Microsoft Entra Insights:
This is a separate service for monitoring Entra ID health and performance, not part of the Permissions Management interface for these tasks.

Dashboard:
While the dashboard may show high-level metrics, it does not provide the detailed, filterable analysis needed to list all global admins or generate a specific PCI report for a single user like the Analytics and Reporting tabs do.

Reference:
Microsoft Learn, "Navigate the Permissions Management dashboard" and "Analyze permissions using Permissions Management." The documentation outlines that the Analytics workspace is for investigating permissions, roles, and resources, while the Reports section includes the PCI report.

Explanation:
The scenario indicates that User2 (Privileged Authentication Administrator) can only configure MFA to use the Microsoft Authenticator app. This limitation typically occurs when Security Defaults are enabled in the tenant. Security Defaults enforce a standard set of security policies, including requiring all users to use the Microsoft Authenticator app for MFA and blocking the configuration of alternative methods. To allow User2 to configure alternate MFA methods (like SMS, phone call, or OATH tokens), Security Defaults must be disabled.

Correct Options:

Configuration required: Modify security defaults.
Security Defaults must be turned off to unlock the full MFA method configuration options in the Microsoft Entra admin center. This allows administrators to define custom authentication methods policies.

User who should perform the configuration: User1 only.
The Security Administrator role (User1) has the necessary permissions to modify tenant-wide security settings, including enabling/disabling Security Defaults and configuring authentication methods. The Privileged Authentication Administrator (User2) can manage MFA for users but cannot change the foundational Security Defaults setting that is causing the restriction. The Service Support Administrator (User3) does not have this permission.

Incorrect Options for User:

User2 only:
Incorrect. User2 cannot modify Security Defaults; they can only manage MFA within the constraints set by the tenant security baseline.

User3 only:
Incorrect. The Service Support Administrator role lacks the permissions for this security configuration.

User1 and User2 only / User1 and User3 only / User2 and User3 only:
Incorrect. Only the Security Administrator (User1) has the required permissions to disable Security Defaults.

Reference:
Microsoft Learn, "Manage authentication methods - Available authentication methods." The documentation states that when Security Defaults are enabled, "the Microsoft Authenticator app using notifications is the only method that users can use." To use other methods, you must disable Security Defaults and use Conditional Access. The Security Administrator role is required to manage Security Defaults.

Explanation:
This question involves analyzing two intersecting Conditional Access policies. Key concepts are policy evaluation order (simultaneous) and that Exclude takes precedence over Include. For CA1: Group1 is included but Group2 and the Global Administrator role are excluded. For CA2: Group2 is included but Group3 is excluded. A user's final access is determined by the combined effect of all applicable policies.

Correct Options:

Statement 1 (User1):
No. User1 is in Group1 (included in CA1) and is a Global Administrator (excluded in CA1). The exclusion of the Global Administrator role takes precedence, so CA1 does not apply to User1. No other policy applies. Therefore, User1 will not be prompted for MFA by CA1.

Statement 2 (User2):
Yes. User2 is in Group2 (included in CA2) and is not in Group3 (the only exclusion in CA2). Therefore, CA2 applies and blocks access. User2 is prevented from signing in.

Statement 3 (User3):
No. User3 is in Group2 (included in CA2) but is also in Group3 (excluded in CA2). The exclusion for Group3 takes precedence, so CA2 does not apply to User3. No other policy blocks them, so they are not prevented from signing in.

Incorrect Options:
Marking "Yes" for Statement 1 would ignore the role-based exclusion.

Marking "No" for Statement 2 would ignore that User2 is included in CA2 with no applicable exclusion.

Marking "Yes" for Statement 3 would ignore the Group3 exclusion in CA2.

Reference:
Microsoft Learn, "Conditional Access: How do policies apply to users." The documentation explains that exclusions override inclusions and that policies are evaluated together. A user is granted access only if they satisfy all applied grant controls; a single blocking policy denies access.

Explanation:
This question tests the configuration and behavior of self-service application access in Microsoft Entra ID. When enabled, users can request access to an app. Configurations include specifying an automatic assignment group, requiring approval, and designating approvers. Key points: The "Allow users to request access" setting must be on for users to see the request option. Approvers must have the proper role (Global Admin, Application Admin, etc.) to approve requests in the admin center.

Correct Options:

Statement 1 (User1 must request access):
No. User1 is already a member of Group1, which is the group designated for app assignment. Since access is granted via group membership, User1 already has access to App1 and does not need to request it.

Statement 2 (User2's request adds to Group1 automatically):
Yes. The configuration states "To which group should assigned users be added: Group1". When a user's request for App1 is approved, they are automatically added to Group1 as part of the access granting process.

Statement 3 (User2 can approve in admin center):
No. While User2 is designated as the allowed approver in the app's self-service settings, to actually approve requests in the Microsoft Entra admin center, a user must also hold an administrator role such as Global Administrator, Application Administrator, or Cloud Application Administrator. The configuration does not state that User2 has any such role, so they cannot approve requests via the admin portal.

Incorrect Options:
Marking "Yes" for Statement 1 ignores that existing group members already have access.

Marking "No" for Statement 2 misunderstands the automatic group assignment feature.

Marking "Yes" for Statement 3 overlooks the role requirement for performing approvals in the admin center.

Reference:
Microsoft Learn, "Self-service application access - Configuration." It explains that approved users are added to the specified group. For approvals, it states that "only users who are Global Administrators, Application Administrators, or Cloud Application Administrators can approve requests" from the Access Panel or admin center. Being named an approver in the app settings alone is insufficient without the required role.

Explanation:
This is a multi-part scenario requiring secure, non-interactive authentication for an on-premises service (scheduled tasks) to a Microsoft Entra app (App1) with Graph permissions, while restricting access to the corporate network. The key requirements are: no plaintext credentials and corporate network-only access. A certificate provides strong, non-secret authentication. A Conditional Access policy with a Named Location can restrict access to specific IP ranges (the corporate network). An Application Proxy is not needed for outbound authentication from the server.

Correct Options:

In the tenant configure: A Conditional Access policy
You need a Conditional Access policy targeting App1 (as a cloud app) with a Location condition. Configure a Named Location for your corporate IP range, then create a policy that grants access only from that trusted location. This satisfies the "accessible only from corporate network" requirement.

Configure scheduled tasks on Server1 to authenticate by using a: Certificate
This meets the requirements for non-interactive authentication and no plaintext secrets. You configure App1 to use a certificate credential. The scheduled task (e.g., a script or app) uses this certificate (installed on Server1) to authenticate silently to Microsoft Entra ID and obtain a token for App1. A client secret is plaintext and should be avoided.

Incorrect Options for Authentication Method:

Client secret:
This is a plaintext password stored in configuration files, violating the "not stored as plain text" requirement.

System-assigned managed identity / User-assigned managed identity:
Managed identities are for Azure resources (like VMs, App Services) to authenticate to Azure services. Server1 is an on-premises server, so it cannot use an Azure Managed Identity. This is a common distractor.

Incorrect Options for Tenant Configuration:

An authentication method:
This refers to user MFA methods, not application authentication.

A Microsoft Entra application proxy:
Application Proxy is for publishing on-premises web apps for secure inbound access from the internet. It is not used for an on-premises server to authenticate outbound to a cloud app.

A permission classification:
This is for labeling and managing API permissions, not for network restriction or authentication security.

Reference:
Microsoft Learn, "Certificate-based authentication in Microsoft Entra ID" and "Conditional Access: Location condition." Using certificates for daemon app authentication and using Conditional Access policies with named locations for IP-based restrictions are standard security patterns.

Explanation:
Smart lockout is a feature designed to protect user accounts from brute-force password guessing attacks. It helps lock out an attacker while allowing the legitimate user to still sign in correctly from familiar locations. The lockout threshold (the number of failed attempts before an account is locked) and other smart lockout settings are configured within the Password protection settings in the Microsoft Entra admin center. This is where you define both custom banned passwords and the smart lockout parameters for the tenant.

Correct Option:

B. Password protection.
This is correct. In the Microsoft Entra admin center, you navigate to Protection > Authentication methods > Password protection. Here, you configure the Smart lockout settings, including the lockout threshold (e.g., 10 failed sign-ins) and the lockout duration in seconds.

Incorrect Options:

A. User risk policy:
This is part of Identity Protection and is used to automate responses (like require password change or block) based on the calculated risk level of a user's identity (e.g., leaked credentials), not based on a specific count of failed sign-in attempts.

C. Authentication strengths:
This is a Conditional Access control used to define and require specific combinations of authentication methods (e.g., phishing-resistant MFA), not for configuring lockout thresholds.

D. Sign-in risk policy:
This is part of Identity Protection and automates responses based on the risk level of a specific sign-in attempt (e.g., anonymous IP, unfamiliar location). It does not control the smart lockout threshold for failed password attempts.

Reference:
Microsoft Learn, "Protect user accounts with Microsoft Entra smart lockout." The documentation states: "To configure smart lockout settings with values that work for your organization, you need Microsoft Entra ID P1 or P2 licenses. Configure smart lockout in the Microsoft Entra admin center under Protection > Authentication methods > Password protection."

Explanation:
The requirements are: 1) Securely store API secrets, 2) Avoid credentials in code, 3) Enable VMs to access Azure resources via Microsoft Entra authentication, and 4) Minimize effort. Azure Key Vault is the service for securely storing secrets (like API keys). Managed identities provide an automatically managed identity in Microsoft Entra ID for Azure resources (like VMs) to authenticate without any credentials in code. Using a user-assigned managed identity (over system-assigned) is optimal for multiple VMs running the same app, as the same identity can be assigned to all, simplifying management.

Correct Option:

C. user-assigned managed identities and Azure Key Vault.
This meets all requirements. Store the third-party API secrets in Azure Key Vault. Create a user-assigned managed identity and assign it to all App1 VMs. The app code uses the managed identity to authenticate to Microsoft Entra ID, obtain a token, and silently access secrets from Key Vault. This eliminates secrets from code and minimizes effort by using a single reusable identity.

Incorrect Options:

A. user accounts and Storage Service Encryption:
User accounts (service principals) require credential management (secrets/certificates) that must be stored and rotated, increasing effort and risk. Storage Service Encryption encrypts data at rest in storage accounts but does not help with authentication or secret storage for APIs.

B. user accounts and Azure Key Vault:
While Key Vault stores secrets, using user accounts (service principals) still requires storing and managing the client secret or certificate somewhere (e.g., on the VM), which violates the "no credentials in code" requirement and increases administrative overhead.

D. system-assigned managed identities and Storage Service Encryption:
System-assigned identities are unique to each VM, creating multiple identities to manage for the same app. Storage Service Encryption is irrelevant for API secret storage and authentication.

Reference:
Microsoft Learn, "Managed identities for Azure resources" and "Azure Key Vault basic concepts." Managed identities allow Azure resources to authenticate to any service supporting Microsoft Entra auth without credentials. Key Vault securely stores and manages secrets. The combination is the standard pattern for secure access from compute resources.

Explanation:
This question focuses on the prerequisites for creating session policies in Microsoft Defender for Cloud Apps. Session policies are part of Conditional Access App Control, which allows for real-time monitoring and control of user sessions within cloud apps. Before a Security Administrator can create these policies in Defender for Cloud Apps, the app must be connected and integrated with Conditional Access. The foundational step is to create a Conditional Access policy that routes traffic to Defender for Cloud Apps by enabling the "Use Conditional Access App Control" session control.

Correct Option:

A. Create a Conditional Access policy and select Use Conditional Access App Control.
This is the correct first step. This action enables the integration between Microsoft Entra Conditional Access and Defender for Cloud Apps. It creates the necessary framework that allows session policies, defined in Defender for Cloud Apps, to be enforced. Without this Conditional Access policy, the session policy feature in Defender for Cloud Apps cannot be applied to user sessions.

Incorrect Options:

B. Assign the Cloud Application Administrator role to User1.
While this role might provide broader permissions, it is not the first or necessary step. The Security Administrator role already has sufficient permissions to manage Defender for Cloud Apps. The missing element is the Conditional Access App Control configuration, not a role assignment.

C. Create a Conditional Access policy and select Require app protection policy.
This setting is for Microsoft Intune App Protection Policies (which protect data on mobile devices), not for Defender for Cloud Apps session policies. It is unrelated to enabling session monitoring and control in Defender for Cloud Apps.

D. Assign the Cloud App Security Administrator role to User1.
The Security Administrator role already includes the permissions of the Cloud App Security Administrator role. This assignment is redundant and does not address the prerequisite of configuring Conditional Access App Control.

Reference:
Microsoft Learn, "Deploy Conditional Access App Control." The documentation states that to use session controls, you must first "Integrate with Microsoft Entra Conditional Access" by creating a CA policy with the "Use Conditional Access App Control" session control. This is a prerequisite for session policies to take effect.