Design security operations, identity, and compliance capabilities practice questions

Retention label

Why it fails: Retention labels manage data lifecycle, not sensitivity classification.

Data Loss Prevention (DLP) policy

Why it fails: DLP policies enforce actions on sensitive data but do not automatically apply labels.

Trainable classifier

Why it fails: Trainable classifiers are used for custom classification but are not required for built-in PII detection.

File Integrity Monitoring (FIM)

Why it fails: File Integrity Monitoring monitors and alerts on changes to critical files, registries, and system software, which helps detect potential security incidents such as Trojan activity or unauthorized modifications. However, it is a detection-only control: it reports on changes after they occur but does not evaluate or fix cloud resource misconfigurations that Microsoft Defender for Cloud identifies as security recommendations. Therefore, it cannot perform automated remediation of recommendations.

Microsoft Defender for Cloud's Regulatory Compliance dashboard

Why it fails: The Regulatory Compliance dashboard provides a dynamic view of your compliance posture against standards like CIS, NIST, and Azure Security Benchmark, tracking assessment results across your environment. It aggregates and scores recommendation compliance but has no means to change or fix the underlying resources; it persists until you manually or programmatically remediate them. Thus it is a reporting and monitoring tool, not a remediation control.

Azure Automation Update Management

Why it fails: Azure Automation Update Management is specifically designed to assess and install operating system updates—such as Windows Update and Linux package patches—on your virtual machines. It does not address the broad scope of security recommendations, which include misconfigurations, network security group rules, disk encryption, and other resource settings that go beyond OS patching. Consequently, it cannot remediate Defender for Cloud recommendations that are not update-related.

Automation rules with playbooks

Why it fails: Automation rules with playbooks are response-oriented: a playbook is a Logic Apps-based workflow that only executes when an alert or incident triggers it, and automation rules define exactly those trigger conditions. For low-fidelity alerts, no incident may ever be created, so a rule never fires, and even when it does, the playbook has no native entity profiling to decide whether the alert warrants investigation. The playbook would require additional lookups and conditional logic to emulate investigation, which is not automatic behavior.

Machine Learning (ML) based anomaly detection

Why it fails: Machine learning-based anomaly detection uses algorithms such as clustering or proportional value analysis to learn statistical baselines and then flag deviations as alerts. It is purely a detection capability: its output is an alert event that still requires a separate triage process, and it does not contain any orchestration or investigative workflow to automatically dive into the alert. Therefore ML anomaly detection might identify odd behavior, but it lacks the ability to autonomously investigate low-fidelity alerts.

Custom analytic rules

Why it fails: Custom analytic rules are KQL-based queries that run on a fixed schedule and generate an alert whenever the query returns matching event counts or patterns. These rules are limited to pattern matching and threshold evaluation; they do not maintain entity profiles, perform correlation across heterogeneous signals, or trigger any investigative actions. Thus they may produce many low-fidelity hits but cannot automatically investigate or enrich any of them, making this option incorrect.

Microsoft Defender for Office 365 Safe Attachments policy

Why it fails: Safe Attachments scans email attachments for malware in a detonation sandbox; it has no device isolation capability. It is tempting because Defender for Office 365 handles automated email threats, but isolating an endpoint on a confirmed incident requires Defender XDR automated response actions, not mail-flow policies.

Manual device isolation from Microsoft 365 Defender portal

Why it fails: Manual isolation requires an analyst to click through the portal, so it cannot satisfy the automatic requirement. It is tempting because it achieves the same containment outcome, but the stem demands machine-triggered response on incident confirmation, which needs an automated investigation and response rule, not human action.

Microsoft Defender for Endpoint's endpoint detection and response (EDR)

Why it fails: EDR provides detection, investigation and manual response actions, but it does not itself trigger automatic isolation from a confirmed incident; that orchestration comes from custom detection or automated investigation and response rules in Defender XDR. EDR is tempting because isolation is an EDR capability, yet the automation layer is missing.

Microsoft Entra Connect

Why it fails: Microsoft Entra Connect is a synchronization engine, not an authentication method. It installs on-premises and replicates user objects, groups, and credential metadata (like password hashes) to Microsoft Entra ID; it does not directly handle sign-on challenges. Its role is to provision the identity data that cloud authentication can then consume, making it a prerequisite or deployment mechanism rather than the answer to how users authenticate during a gradual migration.

Active Directory Federation Services (AD FS)

Why it fails: Active Directory Federation Services (AD FS) provides federation-based single sign-on by redirecting cloud authentication attempts back to on-premises AD using SAML or WS-Federation. This approach keeps the authentication decision and credential validation on-premises indefinitely, which contradicts the stated goal of gradually moving to cloud-only authentication. AD FS adds substantial infrastructure complexity and, while it supports a hybrid posture, it is not the first step in a staged transition to cloud authentication.

Pass-through Authentication (PTA)

Why it fails: Pass-through Authentication validates passwords directly against on-premises Active Directory without storing password hashes in the cloud, which contradicts the stem’s requirement to *gradually move to cloud-only authentication* — PTA keeps the on-premises dependency indefinitely. It is tempting because it enables immediate single sign-on using existing credentials during migration, and would be correct if the goal were to maintain full on-premises authentication indefinitely without ever transitioning to cloud-only methods.

Require authentication strength (e.g., phishing-resistant MFA)

Why it fails: Authentication strength is a separate feature, not a direct grant control for MFA.

Require device to be marked as compliant

Why it fails: Device compliance is separate from MFA.

Use app enforced restrictions

Why it fails: App enforced restrictions are for session control.

Identity Protection user risk policy

Why it fails: Identity Protection user risk policy evaluates user behavior and signals to apply conditional access like MFA challenges or password resets when a user account is compromised. It does not provide any mechanism to temporarily elevate privileges or grant just-in-time access to administrative roles. Since it only responds to risk and does not manage role assignments, it cannot fulfill a JIT privileged access strategy.

Privileged Identity Management (PIM) for Microsoft Entra ID roles

Why it fails: Privileged Identity Management for Microsoft Entra ID roles provides just-in-time and time-bound activation of eligible role assignments, requiring users to complete MFA, provide business justification, and optionally wait for approval. This minimizes standing access by letting users activate roles only when needed, with an automatic expiry. It also generates audit logs for every activation, making it the native and most direct solution for JIT access to Microsoft Entra ID directory roles.

Azure RBAC roles

Why it fails: Azure RBAC role assignments are static and persist until explicitly removed, meaning a user with a role has continuous access without any time limit or activation step. RBAC does not support on-demand elevation, approval workflows, or temporary expiration for Microsoft Entra ID roles. While RBAC is necessary for authorizing Azure resource access, it is not a JIT mechanism and would leave standing privileges in place.

Access reviews

Why it fails: Access reviews are a governance feature for regularly recertifying whether users still need their existing role assignments, with results used to keep access current. They do not allow users to request or activate temporary privileges, nor do they enforce time-bound access. Access reviews complement a JIT strategy by cleaning up stale assignments, but they cannot provide the actual on-demand activation that PIM offers.

Entity behavior analytics (UEBA)

Why it fails: UEBA builds behavioral baselines for users and entities, surfacing anomalous activity through analytics, but it does not ingest or synchronize alerts or incidents from Microsoft Defender XDR. It relies on already-collected data such as sign-in logs and requires separate data connectors to be configured. Therefore, while UEBA enriches detection, it cannot serve as the synchronization mechanism the organization needs.

Automation rule to trigger playbook

Why it fails: Automation rules can trigger playbooks to run automated response actions when incidents are created or updated, but they are not the source of incident synchronization. Without the data connector, there are no Defender XDR incidents in Sentinel to trigger anything. Playbooks and automation rules operate on incidents that already exist, so they are optional components used after ingestion, not the required mechanism for synchronization.

The policy does not include 'Microsoft Office 365' in applications

Why it fails: The application condition in Conditional Access is not the source of the problem. Choosing "All apps" comprehensively includes Microsoft Office 365, Exchange Online, and every Microsoft Entra ID-integrated cloud application, making an explicit Office 365 entry redundant and incapable of changing the policy's scope. The real defect is in the client app condition, which fails to cover modern authentication clients.

The grant control should be 'require MFA' instead of 'block'

Why it fails: Blocking is the appropriate grant control for legacy authentication protocols because legacy clients cannot handle interactive MFA challenges—they use basic authentication and do not support the Microsoft Entra ID authentication context required to display a prompt. Requiring MFA on such protocols would be ignored or would cause the sign-in to fail, making "Require MFA" ineffective and incorrect for a legacy-auth block policy. Thus, the grant control setting is not the misconfiguration in this scenario.

The policy state is set to 'enabled' incorrectly

Why it fails: The policy state being set to "Enabled" is correct because the policy is intended to enforce the block on legacy authentication attempts. If it were "Report-only", the policy would only simulate results without actually blocking, and "Disabled" would remove it from the evaluation entirely. An enabled state is essential for enforcement, so this is not an error in the policy configuration.

No, because 'minimumTlsVersion' should be 'TLS1_0'

Why it fails: This option incorrectly claims the template should set 'minimumTlsVersion' to 'TLS1_0'. TLS 1.0 is a legacy, deprecated protocol that has known vulnerabilities and is no longer considered secure. Azure recommends enforcing TLS 1.2 or later, so setting the minimum to TLS1_0 would weaken the storage account's security posture. The template correctly uses 'TLS1_2', making this assertion false.

No, because 'supportsHttpsTrafficOnly' should be false

Why it fails: This option erroneously states that 'supportsHttpsTrafficOnly' should be false. In an ARM template for Azure Storage, this property must be set to true to enforce HTTPS and reject any plain HTTP requests. Setting it to false would allow insecure HTTP traffic, defeating the purpose of a secure configuration. The template correctly sets it to true, so this reason for rejection is invalid.

No, because 'defaultAction': 'Deny' blocks all traffic including HTTPS

Why it fails: This option misunderstands the scope of 'defaultAction': 'Deny' in the context of Azure Storage network rules. The 'Deny' default action applies only to public network access, controlling which source IPs or virtual networks can reach the storage account; it does not govern the TLS protocol or HTTPS enforcement. For connections that are allowed (e.g., from selected networks), the 'supportsHttpsTrafficOnly' and 'minimumTlsVersion' properties still enforce HTTPS and TLS 1.2. Therefore, the claim that Deny blocks all traffic including HTTPS is incorrect—it blocks unauthorized public traffic, not the protocol enforcement itself.

Assign the standard to each subscription individually

Why it fails: Defender for Cloud allows assigning a standard once at the management group level, which propagates to every child subscription. Doing it per subscription is inefficient, especially in multi-subscription environments, because it requires manually repeating the assignment for each subscription, risks missing or misconfiguring a subscription, and does not cover newly created subscriptions until someone remembers to assign it again.

Create an Azure Policy initiative and assign it to the management group

Why it fails: Azure Policy initiatives are used to apply enforcement and audit effects to Azure resources, but a regulatory compliance standard in Defender for Cloud (e.g., CIS, NIST) is a distinct compliance-assessment artifact that maps to a Microsoft-managed policy initiative specifically designed for that framework. Creating your own generic initiative will not reproduce the framework's full control mapping, and compliance data won't surface in the Defender for Cloud Regulatory Compliance dashboard because that dashboard keys off the platform's built-in standard assignments, not custom policies.

Use Microsoft Defender for Cloud's default policy

Why it fails: Defender for Cloud's default policy (the Azure Security Benchmark / ASC Default initiative) is automatically assigned and provides broad security hygiene recommendations, but it is not tailored to specific regulatory frameworks that your organization may be legally or contractually obligated to meet, such as PCI DSS, HIPAA, or GDPR. It covers only the Microsoft-centric benchmark, so organizations requiring compliance proof against an external standard must explicitly enable and assign that standard after the default policy; the default is never a substitute.

Conditional Access policy requiring multi-factor authentication

Why it fails: A Conditional Access policy that requires multi-factor authentication validates the user's authentication strength but cannot capture the business reason or service-ticket reference for an elevation request. MFA does not introduce any workflow for typing a justification or routing an approval, so it leaves no per-activation rationale for auditors to inspect. It answers whether the right person signed in, not why they need elevated access.

An access review for the privileged role

Why it fails: An access review for the privileged role operates on a recurring schedule such as monthly, quarterly, or yearly, and asks role owners to recertify that existing assignments remain necessary. It is not triggered by an activation attempt and cannot enforce a justification or ticket number at the moment of elevation. It instead prevents static roles from becoming stale, which is a different governance goal from per-request approval.

Microsoft Entra Identity Protection user risk policy

Why it fails: Microsoft Entra Identity Protection user risk policy evaluates risk signals such as leaked credentials or impossible travel and can challenge or block a sign-in that it deems risky. It is an identity-protection mechanism focused on compromised accounts, not a PIM control that governs privileged elevation. Because it acts during authentication, it has no concept of a role activation request and therefore cannot record a ticket number or approval for that elevation.

The email is encrypted but can be forwarded

Why it fails: The first clause is correct because Do Not Forward applies an encryption envelope via Azure RMS; however, the second clause is wrong. The RMS usage rights template for Do Not Forward does not include the 'Forward' right, and Outlook will disable the Forward button. Even if a recipient uses a client that doesn't enforce the UI, the RMS license will fail to grant the forward right when the email is opened, so the email cannot be forwarded.

The email is not encrypted but cannot be forwarded

Why it fails: This statement is incorrect because Do Not Forward is, by definition, a rights-protected template that includes encryption. The email is bundled into an encrypted message (using CMS or the proprietary RMS format) before being sent, ensuring confidentiality at rest and in transit. While it is true that forwarding is prohibited, the claim that encryption is absent is false; the protection is in fact the same AES-256 class encryption as other protected messages.

The email is encrypted and the recipient cannot reply

Why it fails: The Do Not Forward policy explicitly preserves the recipient's ability to reply and reply-all, so the assertion that replies are blocked is false. The RMS usage license grants the 'Reply' and 'Reply All' rights while withholding Forward, Print, and Copy rights. A recipient can compose a new reply, and the reply will be sent from their client without the original DNF restrictions attached, though any newly attached sensitivity label applies separately.

Configure Microsoft Intune device compliance policies

Why it fails: Intune policies are for device management.

Deploy Azure Information Protection scanner

Why it fails: Scanner is for on-premises data classification.

Synchronize with Microsoft Entra ID

Why it fails: Synchronization is automatic; not a configuration.

Reduce the retention period for all logs to 30 days

Why it fails: Retention period affects only storage cost, not ingestion cost. Ingestion cost is based on the volume of data sent to Log Analytics, which remains unchanged regardless of how long you keep the data. Shortening retention for all logs would not reduce the daily ingestion bill, and it would likely break compliance or forensic requirements by deleting important security data after 30 days.

Ingest the events into a separate Log Analytics workspace with a shorter retention

Why it fails: Creating a separate Log Analytics workspace with shorter retention does not lower ingestion cost, because the per-GB ingestion price is the same across workspaces. This approach adds significant management overhead, such as additional workspace configuration and complex cross-workspace querying in Sentinel. It also fragments your security data, making unified incident investigation and correlation harder, and storage savings are minimal compared to ingestion costs.

Filter out Event ID 4624 at the source using Windows Event Forwarding

Why it fails: Filtering out Event ID 4624 at the source using Windows Event Forwarding would indeed prevent ingestion and reduce cost, but it removes the data entirely before it reaches Sentinel. This means you lose the forensic and detection value of successful login events, which are crucial for attack path analysis, lateral movement detection, and post-incident investigation. WEF filtering is also a static, source-side configuration that cannot be easily adjusted to recover historical events if your security needs change later.

Create a custom alert rule in Microsoft Sentinel

Why it fails: Creating a custom alert rule in Microsoft Sentinel requires you to first ingest VM-related activity logs into a Log Analytics workspace, then build and maintain KQL queries to detect missing JIT configuration. This duplicates functionality that Defender for Cloud natively provides as a built-in assessment, and it introduces delay and operational overhead without improving detection fidelity. The built-in Defender for Cloud recommendation is already continuously evaluated and surfaced in the secure score, so a custom Sentinel rule is both redundant and less integrated with the platform's native compliance reporting.

Configure JIT access on the VM and monitor via activity logs

Why it fails: Configuring JIT access on an individual VM and then monitoring activity logs is a manual, reactive approach that depends on enabling diagnostic settings and routing logs to a SIEM with custom alert rules. Activity logs primarily capture actions like 'Microsoft.Security/locations/jitNetworkAccessPolicies/initiate/action' but do not provide the continuous compliance status of all VMs against the JIT policy. This method lacks automated assessment and won't proactively alert you to VMs that have JIT disabled, whereas Defender for Cloud's built-in recommendation continuously evaluates all resources and surfaces non-compliant ones immediately.

Enable JIT access on all VMs

Why it fails: Enabling JIT access on all VMs addresses the remediation aspect but fails to provide the required alerting capability. The recommendation in Defender for Cloud is not a configuration action; it is a compliance control that detects and alerts when management ports are exposed without JIT protection. Simply enabling JIT on all current VMs would still leave the organization without a monitoring mechanism to catch future VMs created outside the policy, and it omits the secure score and compliance reporting that the built-in recommendation provides. Therefore, enabling alone is insufficient to meet the requirement to receive alerts on missing JIT.

Create an automation rule in Microsoft Sentinel.

Why it fails: Automation rules in Microsoft Sentinel are designed to manage incidents after they are created—automatically assigning owners, changing status, adding tags, or invoking playbooks when an incident is created or updated. They do not ingest raw alerts or create incidents from security signals; they only operate on incidents that already exist in the workspace. Because the goal is to generate an incident from a Defender for Cloud alert, an automation rule is not the correct mechanism.

Create a playbook in Microsoft Sentinel.

Why it fails: A playbook is a set of automated procedures built on Azure Logic Apps that runs in response to an incident or an alert, typically performing remediation actions such as isolating a compromised device or opening a ticket. Playbooks are triggered by automation rules or directly from an incident after it has been generated; they cannot create a Sentinel incident from a Defender for Cloud alert. For incident creation, you must define an analytics rule that evaluates the alert data stream and produces an incident.

Create a watchlist in Microsoft Sentinel.

Why it fails: Watchlists in Microsoft Sentinel are user-defined tables of data—such as IP ranges, domain names, or known adversaries—that are used for enrichment, filtering, and correlation within analytics rules and hunting queries. They act as lookup references, enabling detections to compare against a known set of values, but they do not generate incidents on their own. To turn a Defender for Cloud alert into an incident, you need an analytics rule with a template that recognizes that alert type, not just a watchlist.

Create a Conditional Access policy that grants access, requiring MFA for all locations.

Why it fails: Creating a policy that grants access with MFA for all locations applies the MFA grant control to named locations marked as trusted as well, because the condition includes 'Any location' without exclusion. This fails the requirement to require MFA only from untrusted networks, and it forces users on the corporate VPN or office egress IPs to perform an extra MFA prompt. The policy should exclude trusted IPs/named locations from the location condition rather than covering all locations.

Create a Conditional Access policy that requires MFA for all users and all locations.

Why it fails: This policy is too broad in both user and location scope: it targets every user, including those accessing from corporate trusted IPs, and it mandates MFA for every possible location condition. Because 'All locations' includes trusted IPs, the policy would not honor the organization's existing trusted network baseline and would add friction for internal users. The intended solution narrows the scope by excluding trusted locations while still requiring MFA for sessions originating elsewhere.

Create a Conditional Access policy that blocks access from all locations except trusted IPs.

Why it fails: Selecting 'Block' as the grant control for all locations except trusted IPs is a denial-of-access control, not an MFA enforcement control. It prevents access entirely from unsanctioned networks instead of challenging those users with MFA, which is the desired behavior. Additionally, blocking depends on an allowlist of trusted IPs, meaning any new or unknown egress IP would result in a complete lockout rather than a multifactor challenge.

Audit only.

Why it fails: Audit only logs the DLP rule match to the Purview compliance portal but does not block, allow an override, or notify the user. In an enforcement scenario, this action fails to prevent data exfiltration—it merely creates an audit record that can be reviewed later. Since the stated goal is to enforce DLP, relying solely on auditing leaves the sensitive data accessible and is therefore insufficient.

Notify only.

Why it fails: Notify only sends an email or in-app notification to the user (and optionally an administrator) when the DLP rule matches, but it does not block the activity. This is a non-enforcement action: the data can still be shared or transferred despite the warning. It is commonly used for awareness or in test mode, but it does not stop data loss, so it fails the requirement to enforce DLP.

Block.

Why it fails: Block completely prevents the sensitive data from being shared or transmitted without any option for the user to override the action. While this absolutely enforces the policy, it lacks a justification workflow, which can cause business disruption when an employee has a legitimate need to share the data. In Purview, block-only actions are often too rigid for production use because they force IT to handle many exception requests, so this option is less appropriate than block with override.

The reviewer query returns no users.

Why it fails: The reviewer query (an accessReviewReviewerScope) selects which users will act as reviewers, not the users whose access is being reviewed. If it returns zero users, the review definition is still created and the review instance will still start, but no reviewers will be assigned, causing the review to be unable to receive decisions until reviewers are manually added. This does not block the review from starting, so it is not the cause.

The autoReviewEnabled setting is false.

Why it fails: The autoReviewEnabled setting controls whether decisions are automatically recorded based on the admin's configured decisions, not whether the review starts. When set to false, an admin must manually finalize decisions after the review period ends, but the review instance is still created and begins on time. This setting only affects the decision-making phase after the review has already started, so it is irrelevant to the missing start.

The scope query syntax is incorrect.

Why it fails: The scope query in an access review defines which users, groups, or application resources are in scope for review. If the query syntax were incorrect, the review definition would fail validation at creation time and would not be saved at all — it would not merely remain unstarted after creation. Since the definition exists and the query is valid, incorrect scope syntax cannot be the reason the review has not started.