Refer to the Exhibit Practice Questions

The query lacks a time filter

Why it fails: 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 it fails: 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 it fails: 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.

A list of computers with more than 5 failed logins from any account.

Why it fails: The query groups by user account, so its output lists accounts rather than computers. Grouping failures by computer is tempting because it exposes a single host receiving many failed attempts, and would be correct when investigating a machine targeted by brute-force activity from many usernames.

A list of user accounts with more than 5 failed logins across all computers.

Why it fails: The query summarises results per computer, not per user account, so it cannot return a user-based list. Aggregating failed logins by account is tempting because it identifies targeted usernames, and would be correct when the goal is finding accounts subjected to repeated authentication failures.

A list of user accounts with more than 5 successful logins in the last 24 hours.

Why it fails: The query filters failed sign-in attempts, so successful logins never appear in its output. Counting successful authentications is tempting because it can reveal password-spraying that eventually succeeds, and would be correct when hunting for accounts compromised after many valid logins.

List all accounts that have been locked out

Why it fails: This query, which filters on EventID 4625 (failed logon), cannot enumerate locked-out accounts because lockouts are reported under a separate EventID, 4740. Lockout status is a state triggered by exceeding an account policy threshold, not an instantaneous failed logon, and requires correlation with policy settings or Active Directory attributes like LockoutTime.

Identify successful logins from multiple IP addresses

Why it fails: The query uses EventID 4625, which specifically records failed logon attempts—not successful authentications. To identify successful logins from multiple IP addresses, you would need EventID 4624 (successful logons), and you would typically join with supplemental network events (e.g., 5156) to map each successful authentication to a source IP. Since 4625 events indicate failures, the query cannot plausibly return successful login activity.

Find users who logged in after hours

Why it fails: After-hours login identification requires successful logon events (EventID 4624) paired with a time-of-day filter to flag activity outside business hours. In contrast, EventID 4625 only records unavoidable failed attempts, which do not represent a user actually logging in, and by itself lacks any temporal condition such as 'before 8 AM or after 6 PM.' Even if the query did filter on time, it would still be examining failures rather than successful logins, so it cannot fulfill this goal.

The storage account was created using an older API version that does not support Azure Policy enforcement.

Why it fails: Azure Policy enforces resource configuration at the control plane via Azure Resource Manager (ARM) regardless of the API version used in the creation request. The policy engine evaluates the final state of the resource, reading current property values such as SupportsHttpsTrafficOnly, independent of how the resource was instantiated. Even legacy API versions submit the resource to ARM, which then exposes the resource's schema for policy evaluation. Therefore, an older API version cannot bypass a Deny effect.

The storage account was created in a region that does not support the premium tier.

Why it fails: The policy rule specifically targets the SupportsHttpsTrafficOnly property of the storage account, which controls whether HTTPS is required for REST API traffic. Premium tier and region are storage account SKU and location attributes that are unrelated to this property. Azure Policy does not inspect tier or region for this definition, and a storage account in a non-premium region can still have secure transfer enabled. Thus, a region lacking premium tier is not a plausible cause of non-compliance.

The storage account was assigned a network security group (NSG) that blocks inbound HTTPS traffic.

Why it fails: Network Security Groups (NSGs) operate at the network layer and filter traffic between subnets and NICs, but Azure Policy evaluates the desired configuration of Azure resources at the control plane. The SupportsHttpsTrafficOnly property is a service setting that determines whether the storage account accepts requests over HTTP; it is independent of inbound traffic rules. Even an NSG that blocks all HTTPS would not change the value of this property or satisfy a policy requiring it to be true. Hence a blocking NSG cannot explain the policy violation.

The sign-in is blocked only if sign-in risk is also high

Why it fails: 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 it fails: 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 it fails: 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.

It denies creation of virtual networks that are not using HTTPS.

Why it fails: This policy cannot affect virtual networks because its condition first checks that the evaluated resource is `Microsoft.Storage/storageAccounts`, so a VNet deployment is outside the policy scope. The property `supportsHttpsTrafficOnly` is a storage-account flag that controls whether secure transfer is required; virtual networks have no analogous HTTPS setting and are handled by different networking policies. Therefore, the policy leaves VNet creation entirely untouched.

It audits storage accounts to check if HTTPS traffic is enforced.

Why it fails: The policy's `then` block explicitly sets `effect: deny`, which instructs Azure Resource Manager to return a 403 and cancel the request when the storage account has `supportsHttpsTrafficOnly` disabled. An `audit` effect would still let the noncompliant storage account be created and simply write a compliance detail to the activity log. Since the effect is not `audit`, this option misreads the enforcement action and understates the policy's blocking behavior.

It denies creation of blob services that do not enforce HTTPS.

Why it fails: This option confuses the resource type being evaluated: the policy targets the parent `Microsoft.Storage/storageAccounts` resource, not the child `Microsoft.Storage/storageAccounts/blobServices` resource. Blob services do not expose a property named `supportsHttpsTrafficOnly`; secure transfer is configured on the storage account itself and applies to all service endpoints including blob, file, queue, and table. A policy that denied blob-service creation would need a different condition and would not use this property.

Multiple successful logons for the same account

Why it fails: 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 it fails: 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 it fails: 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.

Find alerts that were not investigated

Why it fails: Investigation status is stored in fields like IncidentId or custom investigation timestamps; this query does not filter or group by any of those fields. It focuses exclusively on alert severity and name, ignoring incident or case-management data. Consequently, it cannot distinguish investigated alerts from those that have not been triaged.

Analyze entities associated with alerts

Why it fails: The query contains no references to entity fields—such as Account, Host, IP, or URL—nor does it join with any entity tables or use entity-specific functions. Its operations are confined to selecting alert records and aggregating counts by severity and alert name, making entity analysis impossible. Without entity data, any attempt to analyze entities would require additional transformations not present in this KQL.

Correlate alerts by time and alert name

Why it fails: Correlation typically involves joining or grouping alerts based on time proximity, common entity identifiers, or kill-chain stages to reveal related activity. This query performs a simple aggregation and sort, with no temporal joins or pairwise linking; it merely counts events for each alert name. Thus, while it includes alert names, it does not correlate them over time.

The vulnerability assessment scan is automatically remediating findings for rule VA2108

Why it fails: Setting a baseline for a vulnerability assessment rule, as done in the PowerShell command, does not trigger any automatic remediation. The scan itself is read-only and never modifies database settings; a baseline only instructs the assessment engine to suppress that rule's result in future reports. To actually fix the issue, you would need to apply a separate configuration change, such as altering a database permission or enabling auditing.

Vulnerability assessment is disabled for this database

Why it fails: To retrieve a baseline for rule VA2108, the vulnerability assessment feature must already be enabled and have performed scans on the database. If VA were disabled, the PowerShell cmdlet would fail because no baseline configuration would exist to read. Moreover, the presence of a baseline indicates the assessment engine is running and storing results in the associated storage account.

The database has no vulnerability findings

Why it fails: A baseline for rule VA2108 only suppresses findings for that single rule; it has no bearing on the results of any other vulnerability assessment rules. The database may still have many unbaselined findings that are actively reported. Additionally, a baseline is usually set because the rule was flagged in a scan, so the database almost certainly has at least that one finding accepted.

The policy mode should be 'report-only'

Why it fails: Changing the policy mode to 'report-only' would not address the flaw because report-only mode only simulates policy outcomes and does not enforce any actions. The real issue lies in the conditional logic: both user risk and sign-in risk must be High for the 'Block access' control to trigger. Switching to report-only would actually make the policy less effective, since it would never block anything, even for users who meet all conditions.

The JSON syntax is invalid

Why it fails: The policy contains valid JSON; all quotes, colons, braces, brackets, and property names follow the correct syntax for Microsoft Graph's conditionalAccessPolicy resource. If the JSON were malformed, the policy creation or update request would be rejected, but the policy is present and being evaluated. The administrator's concern is not a parsing error but a design flaw in how the risk levels are logically combined.

The conditions are combined with 'Or' instead of 'And'

Why it fails: This option incorrectly reverses the actual logic: Conditional Access policies combine multiple conditions with an implicit AND, not OR. Because both user risk and sign-in risk must be High under the current AND semantics, a High user risk with Low sign-in risk bypasses the block. Switching to an OR operator would be the remedy, not the cause of the problem, so claiming the conditions are ORed is factually incorrect.

The AllowHTTP rule uses sourcePortRange '*' which conflicts with the DenyAll rule.

Why it fails: In an inbound NSG rule, sourcePortRange '*' is a valid wildcard meaning the rule applies to packets from any source port, which is standard for inbound web traffic because the client's ephemeral source port is unpredictable. Using '*' here does not create a conflict with the DenyAll rule; rule precedence is determined solely by the priority number, not by port range specifications. The only way AllowHTTP would 'conflict' with DenyAll is if their destination port ranges overlap and DenyAll has a better (lower) priority, so blaming sourcePortRange '*' is incorrect.

The NSG is not associated with the subnet or network interface where the web server is deployed.

Why it fails: If the NSG were not associated, the default Azure security rules would apply, which include a 'DenyAllInbound' rule that blocks internet HTTP traffic. However, the question assumes the NSG was created and associated, making rule priority a more direct cause.

The DenyAll rule uses protocol '*' which blocks all traffic including HTTP.

Why it fails: In Azure NSG rules, the protocol wildcard '*' matches all protocols, including TCP where HTTP runs, so it indeed matches HTTP traffic. However, the protocol specification alone does not cause the blocking; NSG evaluation is based on priority order, and a lower-priority AllowHTTP rule for destination port 80 would still permit traffic if its priority number were smaller. Because the DenyAll rule's action is what ultimately applies for the match, the blocking is primarily a result of priority ordering, not merely the use of the '*' protocol wildcard.

The 'existenceCondition' field path is incorrect; it should be 'Microsoft.Compute/virtualMachines/extensions/publisher'.

Why it fails: In an 'auditIfNotExists' policy, the 'existenceCondition' field paths are evaluated relative to the child resource type specified in 'details.type' (e.g., 'Microsoft.Compute/virtualMachines/extensions'), not relative to the parent virtual machine. Therefore, using just 'publisher' is the correct field reference—it directly accesses the extension resource's property. Pre-pending the full type path would be invalid because Azure Policy would attempt to resolve a non-existent property within the already-scoped extension resource.

The policy is assigned to a management group, but the VMs are in a subscription under a different management group.

Why it fails: A policy assigned at a management group scope automatically applies to every child management group and subscription within that hierarchy. If the VMs' subscription is a descendant of the management group where the policy is assigned, the assignment reaches those VMs regardless of how many other management groups exist above them. The only way this option would be valid is if the subscription were in a completely separate management group tree, which is not the case in the exhibit—so inheritance makes this a non-issue.

The policy effect should be 'Deny' instead of 'auditIfNotExists'.

Why it fails: The 'auditIfNotExists' effect is correct for a security audit because it evaluates existing VMs and flags them as noncompliant without disrupting current workloads. Changing to 'Deny' would only block the creation of future resources and would not provide any visibility into already-deployed VMs, defeating the purpose of an audit. Furthermore, the real problem is the overly restrictive 'if' condition, not the effect; switching effects would mask the underlying issue and could cause unintended deployment failures for legitimate resources.

Use Azure Policy Guest Configuration to enforce region and NSG rules. Assign policies at each subscription. Use Azure Automation runbooks for remediation.

Why it fails: Azure Policy Guest Configuration is specifically designed for auditing and applying settings inside virtual machines (e.g., OS baseline, application config), not for enforcing resource-level attributes like allowed Azure regions, NSG rules on subnets/NICs, or storage HTTPS requirements. Furthermore, assigning policies per subscription scatters management and bypasses the centralized enforcement that a root management group assignment provides; Azure Automation runbooks would run only on a schedule or manually, offering reactive and inconsistent remediation rather than the continuous, event-driven repair that Azure Policy's DeployIfNotExists effect provides.

Use Azure Blueprints to define the environment. Include Azure Policy assignments in the blueprint. Assign blueprint to each management group. Remediate manually.

Why it fails: Azure Blueprints is deprecated in favor of Azure Policy, template specs, and other native tools; while blueprints could package policy assignments, they are no longer a supported long-term governance solution. Moreover, assigning a blueprint per management group is redundant and misses the simpler pattern of assigning the underlying policies directly at the root management group, from which inheritance flows. Finally, manual remediation after blueprint assignment is inefficient and does not provide the automated, ongoing enforcement and repair that DeployIfNotExists with remediation tasks delivers, leaving the environment exposed to configuration drift.

Create a custom script using Azure PowerShell to check compliance daily. Use Azure Logic Apps to send alerts for non-compliance. Have IT staff manually fix issues.

Why it fails: A custom PowerShell script run daily creates only a point-in-time compliance snapshot and cannot guarantee continuous enforcement or prevent non-compliant configurations from being created between runs. Logic Apps alerts merely notify staff; they do not implement any technical control, and having IT staff manually fix issues is error-prone and does not scale across a large enterprise. This approach misses Azure Policy's native capabilities: declarative rules, automatic evaluation on resource creation/change, and integrated remediation actions that provide real-time drift detection and correction.

Enforce HTTPS traffic only

Why it fails: This is implemented but not the only one; the question may have multiple correct? But we need one best. Actually, the template does enforce HTTPS, but also network default deny. I'll choose the network default deny as it's a strong security control.

Restrict network access by IP address

Why it fails: Restrict network access by IP address is incorrect because the ARM template's networkAcls object contains an empty ipRules array. That means no specific IPv4 or IPv6 CIDR ranges are allowlisted; the template does not use IP-based filtering at all. Instead, network security is achieved solely through the defaultAction property, so this option describes a control that is not present in the deployment.

Enable soft delete for blobs

Why it fails: Enable soft delete for blobs is incorrect because the template does not contain a deleteRetentionPolicy property under the blob service, nor any softDelete configuration. Soft delete is a data-protection feature that preserves deleted blobs for recovery, but it is unrelated to the network access controls being evaluated. Since this setting is absent from the ARM template, this option does not reflect any security control actually deployed.

The grant controls operator is set to 'OR' instead of 'AND'

Why it fails: The grant controls operator is set to 'OR' rather than 'AND', but this is not the problem. When only one grant control (for example, MFA) is configured, 'OR' is the correct and standard operator because there is only a single condition to satisfy. 'AND' would be necessary only if multiple controls had to be simultaneously required, such as requiring both MFA and device compliance. Therefore, the operator setting does not explain the unexpected MFA prompt.

The policy is in 'Report-only' mode

Why it fails: The policy is not in 'Report-only' mode; the JSON explicitly shows the state is 'Enabled'. In Report-only mode, the policy would be evaluated and results written to logs, but it would not enforce any controls or block access. Because the policy is enabled, it actively enforces the MFA grant control, which is consistent with users being challenged for MFA. Thus, the mode is not the root cause of the issue.

The policy applies to all cloud apps, not just Azure management

Why it fails: The policy does not apply to all cloud apps; the JSON shows the includeApplications condition contains the specific application ID for Microsoft Azure Management. If the policy applied to all cloud apps, it would affect sign-ins to every integrated application, which could produce broader unexpected prompts. However, the actual policy is scoped narrowly to Azure management, so this is not the cause of the MFA challenge. The problem is related to the location condition, not the app scope.