Manage identity and access practice questions

The activation approval requirement is not supported for the Global Administrator role

Why it fails: PIM's approval workflow is fully supported for the Global Administrator role, just as it is for every built-in and custom Microsoft Entra ID role. This misconception often stems from the fact that Global Administrators have broad tenant permissions, including the ability to manage PIM itself, but that does not exempt the role from enforcement of an approval requirement. Because the option states the requirement is 'not supported,' it is incorrect.

The user is a member of the approver group and is self-approving the request

Why it fails: In PIM, a user who is a member of an approver group can approve their own activation request unless the policy setting 'Disable approver approval' has been explicitly enabled. Since the scenario does not indicate this setting is enabled, self-approval is permitted, which means the request can be approved immediately by the user themselves. This bypasses the intent of separation of duties but is a known and expected PIM behavior.

The role activation duration is set to zero, causing immediate activation

Why it fails: The role activation duration setting controls how long the role is active after an activation is approved, not whether an approval is needed. Setting the duration to zero—or any other value—does not bypass the approval workflow; the activation request still must be approved before the role becomes active. Thus, this option incorrectly conflates two independent policy settings and is not a valid reason for bypassing approval.

Set the activation maximum duration to 1 hour.

Why it fails: This setting defines the maximum time a role assignment remains active once activated, typically configurable in PIM settings, but it operates post-activation. It has no bearing on the initial request workflow; an eligible user can still self-activate without any human checkpoint, meaning it doesn't satisfy the requirement for another person's approval. Even a short duration doesn't introduce a secondary review or approval step, so it's not a valid way to enforce approval.

Require justification on activation.

Why it fails: While justification prompts the user to enter a business rationale, this is merely an input field and does not route the request to a designated approver. In Microsoft Entra PIM, requiring justification can be used with or without approval, but by itself it only creates an audit trail; it doesn't add a separate authorization step. Therefore, it doesn't meet the requirement that a person approve the activation.

Configure notification emails for role activation.

Why it fails: PIM's notification settings allow customization of email recipients and messages when activations occur, such as notifying a security team or the user. They are purely informational and are triggered after an activation is completed or when changes are logged, not as a gatekeeping mechanism. Configuring these emails cannot pause, block, or defer the activation; therefore it doesn't introduce an approval requirement.

Create a Conditional Access policy for the Privileged Role Administrator role

Why it fails: Conditional Access policies apply to user sign-in conditions, not to PIM role activation settings. They cannot enforce justification or activation duration.

Use Microsoft Entra ID access reviews to review active role assignments

Why it fails: Access reviews are for periodic attestation of access, not for configuring activation parameters like justification or duration.

Modify the Microsoft Entra ID tenant-wide role activation settings

Why it fails: PIM does not have tenant-wide activation settings; each role has its own settings. Changing a global setting is not possible.

Identity Protection user risk policy

Why it fails: The Microsoft Entra ID Protection user risk policy assesses the likelihood that a user's identity has been compromised, using signals such as leaked credentials, anomalous activity, or threat intelligence. When user risk is elevated, the policy can block access or require additional verification, but it never drives the MFA enrollment workflow. MFA registration is managed separately by a Conditional Access policy that includes the 'Require MFA registration' grant control. Therefore, this policy is incorrect for enforcing that users enroll for MFA.

Microsoft Entra ID Protection sign-in risk policy

Why it fails: The sign-in risk policy in Identity Protection evaluates each authentication attempt in real time, using signals like anonymous IP addresses, impossible travel, or token anomalies. If a sign-in is deemed risky, the policy can demand MFA or block access, but it does not initiate or require proactive MFA enrollment. This is a reactive control that reduces risk for individual sessions, not a mechanism that ensures every user has registered MFA credentials. Because the requirement is registration, this option does not satisfy the company's objective.

Privileged Identity Management (PIM)

Why it fails: Privileged Identity Management (PIM) is designed to manage and govern privileged roles by providing just-in-time activation, approval workflows, and access reviews. While PIM may require an eligible user to perform MFA at the moment of role activation, it does not enforce the initial MFA registration for ordinary non-privileged users. PIM's scope is role activation and access governance, not a tenant-wide enrollment policy. Consequently, it is not the appropriate tool for requiring MFA registration.

Require multi-factor authentication

Why it fails: Requiring multi-factor authentication (MFA) in PIM strengthens the authentication process by challenging the user with an additional verification factor, such as a phone call or authenticator app, during activation. However, MFA only proves the user's identity; it does not create an approval workflow or require a separate manager or security group to authorize the request. Even with MFA enforced, the user can activate the role without any human approval, so this setting fails to meet the explicit requirement for manager approval before activation.

Require Microsoft Entra ID join

Why it fails: Requiring Microsoft Entra ID join is a conditional access-like policy that mandates the user's device be Microsoft Entra ID joined before they can activate a role in PIM. This is a device and identity security control that restricts activation to managed corporate devices, reducing risk from unmanaged environments. However, it is completely unrelated to the concept of an approval workflow, because an Microsoft Entra ID joined device condition is automatically assessed based on the device's directory state and does not involve any human approver, let alone a specific security group, to authorize the activation.

Condition: User risk: High, Grant: Block access.

Why it fails: User risk is based on user behavior over time, not specific sign-in risk. The scenario specifies sign-in risk.

Condition: Sign-in risk: High, Grant: Require multi-factor authentication.

Why it fails: This would require MFA instead of blocking, which does not meet the requirement to block access.

Condition: User risk: High, Grant: Require multi-factor authentication.

Why it fails: Incorrect combination: targets user risk rather than sign-in risk, and uses MFA instead of block.

Configure a Conditional Access policy targeting guest users

Why it fails: Conditional Access policies are sign-time evaluation rules that enforce controls such as multi-factor authentication, device compliance, or session restrictions based on risk, location, and application conditions. They do not set or lower the directory-level permissions that govern a guest user's ability to enumerate other users, groups, or applications. Since the default directory browsing behavior remains unchanged unless the 'Guest user access' level is explicitly modified, this option does not address the vendor users' ability to see the entire tenant.

Enable 'External Identities' cross-tenant access settings

Why it fails: Cross-tenant access settings define trust and policy relationships between your Microsoft Entra ID tenant and another Microsoft Entra ID tenant—for example, whether inbound B2B collaboration invites are allowed, and whether MFA or device claims from the external tenant are trusted. They operate at the tenant-to-tenant level and do not grant or restrict an individual guest user's permission to read directory objects. To limit what a specific guest can see, you must change the tenant-wide guest access setting, not apply a cross-tenant policy.

Assign the Application User role to the vendor users

Why it fails: Application User is not a built-in Microsoft Entra ID directory role; rather, application roles are custom roles defined by an application to control authorization inside that software, such as data-level read/write operations. Assigning such an application role does not alter Microsoft Entra ID directory permissions or suppress the guest's default ability to browse directory objects. Restricting guest directory visibility is done via the External Identities guest access setting, not by assigning an application-specific role.

Use Microsoft Entra ID Protection to create a sign-in risk policy that requires MFA registration for medium and above risks.

Why it fails: Identity Protection sign-in risk policies evaluate the real-time risk of each authentication attempt and only challenge users whose sign-in is flagged medium or above. This is fundamentally a risk-based conditional access control, not a registration enforcement mechanism: a user with zero risk events may never be prompted, so the policy cannot guarantee that every user completes MFA registration within a 14-day window. Moreover, the sign-in risk policy's grant controls historically focus on blocking access or requiring MFA at sign-in, not on forcing the MFA registration process itself. To meet a strict 'all users must register within 14 days' requirement, you need a broad, deterministic policy that applies to every user regardless of risk score.

Configure the Microsoft Entra ID audit logs to send an alert when a user has not registered for MFA after 14 days, then manually block them.

Why it fails: This option relies on a reactive, manual workflow: audit logs would need to be monitored or alert rules configured to detect users who have not registered after 14 days, and an administrator would then have to manually block each offending account. There is no built-in, automatic block based solely on the audit log alert; the action depends on human intervention, which introduces delays, potential for oversight, and operational overhead. Furthermore, the Microsoft Entra ID audit logs capture sign-in and registration events but do not natively provide a policy-driven 'block after 14 days' action — that capability only exists in Conditional Access with the MFA registration grace period. The requirement for automatic enforcement cannot be satisfied by a detection-and-manual-response pattern; it demands a proactive access control that blocks at sign-in time without admin action.

Include 'User risk' level 'High' and set Grant to 'Require multi-factor authentication'.

Why it fails: User risk applies to accounts that may be compromised, and requiring MFA is a common remediation, but the scenario specifically targets sign-in risk during a session.

Include 'Device platforms' 'All' and set Grant to 'Require managed device'.

Why it fails: This addresses device trust, not risk of the sign-in itself.

Include 'Locations' 'All trusted locations' and set Grant to 'Block access'.

Why it fails: This blocks access based on location, not risk level.

Device platforms

Why it fails: The Device platforms condition is evaluated from the user agent string of the client and targets the operating system, such as Windows, macOS, iOS, or Android. It is used to apply policies like requiring a compliant device only on specific OS versions, but it has no awareness of the user's physical or network location. An attacker using a device from a blocked country would still match the allowed platform, so this condition cannot enforce geographic restrictions.

Client apps

Why it fails: The Client apps condition classifies the authentication attempt by the type of application and authentication flow, such as browser apps, mobile apps, modern or legacy authentication clients. It allows policies like blocking legacy authentication protocols (for example, Exchange ActiveSync) or requiring app-based controls for specific client types. Because this condition inspects the application context rather than the source IP address, it cannot determine or restrict the geographic location of the sign-in.

Sign-in risk

Why it fails: The Sign-in risk condition consumes risk levels calculated by Microsoft Entra ID Protection from signals like anonymous IP addresses, atypical travel, or leaked credentials. These risk levels indicate the probability that a sign-in was compromised and are used to trigger responses such as requiring MFA or blocking high-risk attempts. While one of the signals (anonymous IP) may coincide with location, the condition itself represents a risk classification, not a direct geographic allow/block control, so it does not meet the requirement.

Microsoft Entra ID Protection

Why it fails: Microsoft Entra ID Protection identifies and responds to suspicious sign-in or user risks (e.g., anonymous IP, atypical travel), and its risk policies are enforced through Conditional Access, not by themselves. It cannot be configured to evaluate a user's source IP address against corporate network ranges for an application-specific MFA requirement. Any location-based MFA decision must live in a Conditional Access policy with a location condition; Identity Protection only supplies risk signals that such policies can consume.

Microsoft Entra Privileged Identity Management (PIM)

Why it fails: PIM is focused on just-in-time privileged role activation and provides controls such as approval workflows, time-bound assignments, and MFA when activating high-privilege Microsoft Entra ID roles. It does not apply to normal end-user authentication to a line-of-business application, nor does it inspect the network location from which an employee signs in. Even if PIM's activation requires MFA, that is a separate mechanism for administrators; it cannot be used to enforce regular app-access MFA for non-privileged users.

Microsoft Entra application proxy

Why it fails: Microsoft Entra application proxy lets you publish on-premises web apps to external users and supports Microsoft Entra ID pre-authentication so that sign-in is handled by Microsoft Entra ID before traffic reaches the app. However, Application Proxy alone only forwards authentication and does not decide whether MFA is required; that decision is always made by a Conditional Access policy. You could integrate it with CA to enforce MFA for those published apps, but the proxy itself is not the enforcement point.

Create a Log Analytics workspace in the same region as the resources.

Why it fails: A workspace must exist, but creating it is a prerequisite, not an action that enables continuous export.

Assign an Azure Policy definition for 'Deploy export to Log Analytics workspace for Azure Security Center data'.

Why it fails: While such a policy exists to automate deployment, it is not strictly required; manual configuration is sufficient.

An NRT (near-real-time) rule

Why it fails: NRT rules provide low-latency detection but cannot join multiple data sources, which is required for correlating sign-ins and storage access.

A fusion rule

Why it fails: Fusion rules use advanced correlation to identify multi-stage attacks, but they are not customizable for specific user-defined patterns.

A machine learning-based analytics rule

Why it fails: ML-based rules use built-in anomaly detection models and are not designed for custom correlation of specific event sequences.

Microsoft Entra ID sign-in logs

Why it fails: Microsoft Entra ID sign-in logs only show authentication events, such as successful or failed user and service-principal sign-ins, with location, MFA status, and conditional-access results; they do not include storage data-plane actions like blob reads or account key usage. An attacker using a leaked storage account key or SAS token can exfiltrate data without ever generating an Microsoft Entra ID sign-in event, because key-based access bypasses Microsoft Entra ID authentication entirely. Thus sign-in logs alone cannot establish whether storage data was accessed or removed, making them inadequate for detecting exfiltration.

Azure Key Vault audit logs

Why it fails: Azure Key Vault audit logs record operations performed directly against the vault, such as secret retrieval, key wrapping, and certificate access, but they do not capture storage data-plane events like blob reads or container listings. Even when a storage account uses a Key Vault-managed customer key, the Key Vault log shows only the encryption key operation, not the actual storage data access or exfiltration of blobs. Therefore, these logs are not a valid source for detecting direct data exfiltration from Azure Storage.

Playbooks (Azure Logic Apps)

Why it fails: Playbooks are automated workflows that can send emails, create tickets, and perform custom actions. They can be triggered by automation rules or directly from incidents, and combined with an analytics rule, they can create incidents and send notifications.

Scheduled analytics rules

Why it fails: Scheduled analytics rules are detection mechanisms, not response mechanisms. They execute a KQL query on a defined cadence (e.g., every 5 minutes) and generate an alert or incident when the query returns results. They have no built-in capability to send emails or perform any post-detection actions; their role ends at raising the alert. Any email or notification must be layered on afterward using an automation rule and a playbook, so the analytics rule alone cannot fulfill the team's requirement.

Livestream

Why it fails: Livestream is a debugging and investigation tool in Microsoft Sentinel that shows raw events in near real-time as they flow into the workspace. It is intentionally passive—it lets an analyst watch a live log stream to verify a query or monitor a specific event type, but it can neither run automated response actions nor trigger alerts or emails. Because it is designed for human observation rather than machine-driven remediation, it is not suitable for any automated notification workflow.

Defender for Servers Plan 1

Why it fails: Defender for Servers Plan 1 delivers foundational protections for Azure VMs such as endpoint detection response, file integrity monitoring, and network security hardening, but it deliberately excludes the integrated vulnerability assessment feature. Without that built-in scanner, Plan 1 cannot identify installed applications with known Common Vulnerabilities and Exposures (CVEs), so it would never surface a 'Critical' severity vulnerability alert. The built-in Qualys-based scanning engine and its associated recommendations are exclusively available in Defender for Servers Plan 2.

Defender for Cloud Apps

Why it fails: Defender for Cloud Apps operates as a cloud access security broker (CASB) focused on shadow IT discovery, access control, and session monitoring for SaaS applications such as Office 365 and Dropbox. It applies conditional access policies and detects risky user behavior but has no agent or integration to inspect the OS-level or application-level security of Azure VMs. Therefore, it cannot report on VM software vulnerabilities, making it irrelevant to this critical alert scenario.

Defender for Storage

Why it fails: Defender for Storage monitors Azure Storage accounts for attack paths such as anomalous public access, phishing, suspicious blob downloads, and malware embedded in files, but it is entirely scoped to storage data plane activity. It does not deploy agents or read guest-level OS state on compute resources, and its threat detections are tied to storage telemetry rather than VM vulnerability databases. A vulnerability alert for a VM must originate from a server-specific Microsoft Defender plan, not from storage protection.

Defender for Servers Plan 1

Why it fails: Defender for Servers Plan 1 provides foundational endpoint protection such as OS-level threat detection, network security, and behavioral monitoring, but it deliberately does not include the integrated Qualys-based vulnerability assessment scanner. Without this scanner, Defender for Cloud cannot automatically discover known CVEs on the VM's operating system or installed applications. As a result, the plan does not produce the critical vulnerability alerts that the company needs, making it insufficient even though it is a valid server protection tier.

Defender for SQL

Why it fails: Defender for SQL is a resource-specific plan that secures Azure SQL Database, Azure SQL Managed Instance, and SQL servers running on machines by providing database-level vulnerability assessments, advanced threat protection, and data classification. It does not, however, include an OS-level vulnerability scanner for the underlying virtual machine; its scanning scope is limited to the SQL engine and its misconfigurations. Therefore, while it can protect a SQL Server workload, it cannot detect critical vulnerabilities in the guest operating system or non-SQL software on a general-purpose VM, so it does not meet the stated need.

Defender for App Service

Why it fails: Defender for App Service is scoped exclusively to web applications hosted on Azure App Service, detecting web-application attacks such as SQL injection, cross-site scripting, and overprivileged app registrations. It works by monitoring outbound and inbound traffic to the App Service endpoints and analyzes app behavior, but it does not integrate with or inspect the underlying VM's OS, kernel, or installed software. Because the company needs vulnerability assessment on VMs themselves, this plan is irrelevant to the scenario and offers no visibility into OS-level CVEs.

Continuous export

Why it fails: Continuous export is a configuration feature that streams security alerts and recommendations to a Log Analytics workspace or Event Hub in near-real time, enabling SIEM ingestion, long-term retention, or custom analytics. Although it can send the same data points that workflow automation consumes, its sole function is telemetry delivery; it has no execution engine to evaluate or modify the underlying Azure resources, so it cannot remediate the security findings it transports.

Alert suppression rules

Why it fails: Alert suppression rules are designed to filter or hide alerts that match deterministic criteria—such as specific alert IDs, resource names, or severities—so security operators are not flooded with known benign activity. These rules only suppress the visual alert generation pipeline in Defender for Cloud; they do not change the security configuration of the workload and cannot invoke any remediation, making them a noise-reduction mechanism rather than an automated response tool.

Regulatory compliance dashboard

Why it fails: The regulatory compliance dashboard evaluates your environment against frameworks like CIS, PCI DSS, and Azure CIS through a series of security assessments, then scores and visualizes which controls are satisfied or failed. Its output is a compliance posture report with recommendations on the covered resources; the dashboard does not include an execution step, so fulfilling those controls still requires a separate action such as manual changes or a workflow automation that applies the fix.

Continuous export

Why it fails: Continuous export is a data pipeline feature that streams security alerts and recommendations from Defender for Cloud to destinations such as Log Analytics workspaces, Event Hubs, or a custom SIEM using the Continuous export settings on environment settings. It pushes JSON data for downstream analytics, archiving, or correlation, but it performs no action on the resources themselves. The exported data might allow another system to trigger a fix, but the export mechanism itself never performs remediation or modifies Azure resources. This is why it fails to meet the requirement.

Email notifications

Why it fails: Email notifications in Defender for Cloud are configured under Email notifications in the environment settings, where you can set severity levels and recipients to receive alert summaries or real-time emails. These messages simply inform security personnel that a recommendation or alert exists, and any remediation would require a separate manual process by the person reading the email. There is no embedded Logic App, runbook, or automation account that can act on the notification, so it cannot apply fixes automatically. The notification system is unidirectional and advisory only.

Security policies

Why it fails: Security policies are Azure Policy definitions and initiatives assigned at the subscription or management group level to assess whether resources meet standards like CIS or NIST. When a resource is found non-compliant, Defender for Cloud surfaces it as a recommendation with a Remediate button, but that action is manual and does not happen automatically. Policy effects such as DeployIfNotExists or Modify can auto-remediate at creation time, but standard security policies in Defender for Cloud only report compliance status; they do not automatically apply fixes after a recommendation is generated. Therefore, policies alone cannot deliver the automated remediation the company wants.

Near-real-time (NRT) rule

Why it fails: Near-real-time (NRT) rules are designed for low-latency analytics over high-volume event streams such as those from Microsoft 365, and they run a KQL query as often as every minute to minimize alert delay. However, NRT rules have a constrained feature set—for example, they do not support certain operators, lookups, or multiple data sources—and they are intended for scenarios where sub-minute responsiveness is critical. Microsoft Entra ID audit logs typically do not require this level of urgency, and their analysis is better served by a scheduled query rule that allows more flexible and complex query logic.

Fusion rule

Why it fails: A Fusion rule is a machine-learning-driven analytics rule that automatically correlates a broad set of Sentinel and Microsoft security alerts to detect sophisticated multistage attack chains, combining many individual alerts into a single incident based on incident enrichment and intelligence. It does not accept a custom KQL query against a specific log table, and it cannot create an incident directly from Microsoft Entra ID audit log entries. Rather than evaluating a single data source, Fusion relies on a constellation of existing alerts and is therefore unsuitable for creating incidents from a custom query.

Microsoft Security incident creation rule

Why it fails: A Microsoft Security incident creation rule is a connector-based rule that ingests alerts already generated by Microsoft security services such as Microsoft Defender for Cloud, Microsoft 365 Defender, and Defender for Endpoint, and automatically converts those alerts into Sentinel incidents. It is not a query-based detection mechanism—it never runs KQL against Microsoft Entra ID audit logs. Consequently, it cannot create an incident based on a custom query you write; it simply mirrors the alert output of connected security products.