Design security operations, identity, and compliance capabilities practice questions

Archive all logs to Azure Storage after 90 days

Why wrong: Archiving all logs to Azure Storage after 90 days moves them out of Sentinel's operational store, so you lose native KQL query, detection, and investigation capabilities. To analyze archived data, you must rebuild pipelines to re-ingest or use external tools, which adds latency and complexity. This approach cuts costs but fails to preserve the interactive security operations workflow that Sentinel is designed to provide.

Use the Basic logs tier for all logs and set retention to 365 days

Why wrong: Using the Basic logs tier for all logs with 365-day retention drastically limits the power available for security analysis. Basic tier supports only a subset of KQL operators and lacks features like functions, saved queries, and certain alerting scenarios, which are essential for threat detection and investigation. While it reduces cost, it would prevent you from performing the advanced analysis required for security-critical events, making it unsuitable as the sole tier for Sentinel workloads.

Set the default retention to 30 days and export logs to Log Analytics Workspace

Why wrong: A default retention of 30 days is far below the required one-year period, so the environment would not meet compliance for long-term log access. Exporting to another Log Analytics workspace does not resolve this because the exported data is a copy, not a continuation of the original workspace, and it introduces duplicate storage costs and management overhead. Furthermore, the exported workspace lacks the seamless integration with Sentinel's incidents, alerts, and workbooks, making it an impractical workaround for a simple retention-extension need.

Anti-malware policy

Why wrong: Anti-malware policies in Defender for Office 365 scan email bodies and attachments for known malware signatures and heuristics, using engines like the Malware Engine. They do not inspect or rewrite URLs within the message, and they lack the click-time verdict capability that Safe Links provides. As a result, an email containing a malicious link would not be blocked by an anti-malware policy, because the policy never evaluates the link's target.

Anti-phishing policy

Why wrong: Anti-phishing policies are designed to detect phishing attempts through sender spoofing, user impersonation, and mailbox intelligence, but they do not perform link scanning or rewriting. They may flag a message as phishing based on its content and sender reputation, yet they lack the ability to analyze the URL at the moment of click. Therefore, while they provide complementary email security, they are not the technical solution for protecting users from clicking malicious links.

Safe Attachments policy

Why wrong: Safe Attachments protects against malware delivered via email attachments by detonating files in a high-fidelity sandbox and inspecting their behavior. It does not inspect Uniform Resource Locators (URLs) inside the email text, nor does it perform any click-time evaluation. Since the requirement is specifically about links and not attachments, this policy is an incorrect choice for the stated protection.

Azure Policy for security controls

Why wrong: Azure Policy is a governance service that evaluates and enforces rules for Azure resource configurations, such as requiring encryption, defining allowed regions, or adding tags. It is a control-plane compliance tool, not a security operations platform, and it cannot ingest security logs, correlate alerts, or manage incidents. Therefore, it is incorrect because it addresses preventive infrastructure compliance rather than the detection and response workflows needed to unify incidents in Sentinel.

Microsoft Purview Information Protection

Why wrong: Microsoft Purview Information Protection is focused on data classification, labeling, and encryption to safeguard sensitive information across files, emails, and other data stores. While it contributes to an organization's overall security posture, it does not provide detection, investigation, or response capabilities, nor does it integrate with Sentinel for incident correlation. It is wrong because it is a data governance and protection service, not a security operations platform for unified incident management.

Trust implicitly

Why wrong: Trusting implicitly is the opposite of Zero Trust because it assumes that a user, device, or network connection is safe based solely on a previous authentication or an internal network location. In modern identity attacks, such implicit trust enables lateral movement once a credential is phished, since attackers inherit the original session's privileges. Zero Trust explicitly rejects this model, requiring verification for each request rather than assuming an initial logon is sufficient.

Use a single authentication method

Why wrong: Relying on a single authentication method, such as a password alone, leaves identities vulnerable to phishing, password spraying, and replay attacks. Zero Trust encourages multiple layers of authentication, specifically MFA that combines two or more factors, and in Entra ID you can require phishing-resistant methods like FIDO2 or Windows Hello for Business. Using just one method means a single stolen factor grants instant access, violating the 'verify explicitly' and 'least privilege' principles.

File Integrity Monitoring (FIM)

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Device compliance policies

Why wrong: Device compliance policies evaluate the device's overall health (e.g., OS version, encryption, jailbreak status) and are enforced only after the device is enrolled and managed by Intune MDM. They do not secure individual apps or corporate data within apps; instead, they control device-level access to resources. For a bring-your-own-device (BYOD) scenario where you want to protect data in apps without full device enrollment, compliance policies are not the right tool, as they require device management and don't apply data-loss-prevention controls at the app layer.

Conditional Access for app control

Why wrong: Conditional Access with app control (e.g., 'Require approved client apps' or 'App protection policies') can restrict which apps clients can use to access Exchange Online or SharePoint. However, Conditional Access itself is a gatekeeping mechanism that enforces access conditions at authentication time, not a data-protection feature that encrypts, pins, or restricts copy/paste within an app on a personal device. It works alongside MAM policies, but alone it does not provide granular data-level safeguards such as preventing 'Save As' or restricting sharing between managed and unmanaged apps.

Windows Autopilot

Why wrong: Windows Autopilot is a device provisioning and deployment technology that automates the initial setup and configuration of new Windows devices, including enrolling them in Intune MDM and applying device configuration profiles. It has no role in protecting corporate data inside individual mobile apps or preventing data leakage from applications on personal devices. Autopilot is about getting the device ready for use, not about enforcing app-level data protection policies, so it is unrelated to the scenario described in the question.

Azure AD Connect

Why wrong: Azure AD 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 Azure AD; 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 wrong: 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 wrong: 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.

Identity Protection user risk policy

Why wrong: 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 Azure AD roles

Why wrong: Privileged Identity Management for Azure AD 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 Azure AD directory roles.

Azure RBAC roles

Why wrong: 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 Azure AD 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 Azure AD-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 wrong: 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 Azure AD 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 wrong: 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.

The query lacks a time filter

Why wrong: A missing time filter does not invalidate the query, because analytics rules in Microsoft Sentinel apply an implicit time range defined by the rule's query scheduling and lookback period, and KQL queries executed manually against a workspace default to a 24-hour or user-defined time span. While an explicit time filter is a best practice for performance and to avoid scanning irrelevant data, its absence does not cause the query to fail or miss detections that would otherwise occur within the evaluated window.

The 'IPAddress' field does not exist in SecurityEvent

Why wrong: The assertion that IPAddress does not exist in SecurityEvent is false; the SecurityEvent table does contain an IP address column (often referenced as IpAddress or IPAddress) that stores the source IP address, and it is commonly used in KQL queries for security analytics. Even if there are case-sensitivity nuances in KQL column references, the field itself is a valid part of the schema, so this is not a reason the query would be incorrect.

The 'count()' aggregation is incorrect

Why wrong: The count() aggregation is a standard KQL aggregation function that returns the number of rows per group when used with summarize, so it is not incorrect. There is no requirement to use count_distinct or other functions unless counting unique values, and the query's use of count() after a where clause and summarize group is syntactically and semantically valid. Therefore, this option does not represent a flaw in the detection query.

No, because 'minimumTlsVersion' should be 'TLS1_0'

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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

Why wrong: An Azure AD/Entra ID Conditional Access policy is an access-control engine, not a data-cleansing tool; it evaluates risk, device compliance, and location to allow or block sign-in sessions. Blocking an unhealthy or out-of-compliance device temporarily prevents it from reaching corporate resources, but it leaves every byte of corporate data already on the device untouched and the device remains enrolled and managed.

Full wipe

Why wrong: Intune's full wipe (factory reset) resets the device to its out-of-box state, erasing the OS partitions, all user apps, personal photos, contacts, and the MDM enrollment itself. This is reserved for lost/stolen devices or corporate-owned devices being recycled, since it destroys personal and corporate data indiscriminately rather than isolating and removing only company data.

Device compliance policy

Why wrong: A compliance policy defines the expectations a device must meet, such as a minimum OS build, BitLocker enforcement, or being non-rooted, to be considered trustworthy for resource access. When a device falls out of compliance, Intune simply flags it and access is blocked via Conditional Access; compliance evaluation never invokes a wipe or data-deletion operation on the enrolled device.

Conditional Access policy requiring multi-factor authentication

Why wrong: 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 wrong: 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 wrong: 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 sign-in is blocked only if sign-in risk is also high

Why wrong: This option incorrectly assumes that user risk and sign-in risk must both be High to trigger the block. In the exhibit, the sign-in risk condition is not configured at all, leaving it empty and therefore unevaluated. The user risk condition is set to High and mapped directly to the block grant control, so the sign-in is blocked based solely on user risk, not on a combination of both risk types.

The sign-in is allowed because sign-in risk is not high

Why wrong: This option misreads the policy's risk handling by suggesting that a non-High sign-in risk would allow the sign-in. Since the sign-in risk condition is not configured, the policy does not evaluate sign-in risk in any capacity; it treats the condition as not applied. The user risk condition, set to High with a block action, is the decisive factor and forcibly blocks the sign-in regardless of sign-in risk status.

The user is prompted for multi-factor authentication

Why wrong: No multi-factor authentication (MFA) grant control exists in the conditional access policy shown in the exhibit; the only access control configured is 'Block access' when user risk is High. Grant controls in Conditional Access define what must be satisfied to allow access, and since none are listed, MFA is not prompted. Instead, the policy's block action overrides any potential grant behavior, producing a hard denial of the session.

Multiple successful logons for the same account

Why wrong: This option is incorrect because the analytics rule queries SecurityEvent where EventID == 4625, which is the event ID for failed logon attempts. Successful logons are recorded under EventID 4624 and are not part of the rule's dataset. Since the rule counts only failed logons per account, multiple successful logons would never meet the alert condition and do not indicate a brute-force attack.

Multiple failed logons from the same source IP address

Why wrong: This option is incorrect because the rule does not group or aggregate by the source IP address. Even if many failed logons originate from a single IP, the query only counts failed logons per Account using the Account field, so the rule would not alert unless that same account individually exceeds 10 failures. An attack from one IP across many different accounts would therefore remain undetected because the rule lacks an IP-based grouping dimension.

Overall number of failed logons across all accounts

Why wrong: This option is incorrect because the rule uses a per-account threshold, not a global workspace-wide total. The query groups failed logon events by Account and applies the 'greater than 10' condition to each account group independently. Thus, a total of 100 failed logons spread across 100 different accounts would not trigger the alert, since no single account reaches the threshold—highlighting that the rule detects concentrated attempts on one identity rather than overall failed logon volume.

The email is encrypted but can be forwarded

Why wrong: 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 wrong: 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 wrong: 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.

Reduce the retention period for all logs to 30 days

Why wrong: 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 wrong: 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 wrong: 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.