Refer to the Exhibit Practice Questions

The WAF policy is in prevention mode and detected a SQL injection.

Why it fails: The response is a block that originated from the custom rule's explicit action, not from a managed SQL injection rule. A SQL injection detection would require signature evidence such as SQL keywords or tautological expressions in the payload, and the WAF logs would reference the specific managed rule ID. Since the exhibit shows a custom rule matching private IP ranges, this explanation is incorrect even if the policy is in prevention mode.

The WAF policy is set to detection mode and logs the request.

Why it fails: Detection mode is a log-only operation: it records a request that matches a rule without stopping it, so a request that is actually blocked cannot be caused by a detection-mode policy. The custom rule in the exhibit is configured with an action of "Block" for IP address ranges, and a block action is enforced regardless of the policy's managed rule mode. Therefore, saying the policy is in detection mode and merely logs the request directly contradicts the observed blocked outcome.

The custom rule is disabled due to a syntax error.

Why it fails: The custom rule shown in the exhibit is well-formed JSON with valid condition syntax, so no syntax error is present. A disabled or invalid rule would not evaluate traffic at all, meaning the request would fall through to other rules instead of being blocked by this rule. If a custom rule had a syntax error, Azure would fail validation or omit it from evaluation, not silently disable it while still producing a block. Thus, this rationale cannot explain the blocked request.

Encryption is disabled for the storage account.

Why it fails: The template does not disable encryption; Azure Storage encryption is enforced at the service level and cannot be turned off. The encryption.services.blob.enabled and encryption.services.file.enabled properties are both set to true, meaning those services are explicitly encrypted. Therefore, the storage account has encryption enabled at rest, not disabled.

The storage account will use customer-managed keys from Azure Key Vault.

Why it fails: Because keySource is Microsoft.Storage, the key management delegation is to Microsoft platform-managed keys, not to a customer-controlled Azure Key Vault key. To request customer-managed keys, the template would need keySource: Microsoft.Keyvault, plus keyvault properties such as keyName, keyVersion, and the Key Vault resource ID. Those elements are not present, so the account does not use customer-managed keys.

Encryption is enabled only for blob storage.

Why it fails: The template sets both encryption.services.blob.enabled and encryption.services.file.enabled to true, so encryption is explicitly applied to blob storage and to Azure Files alike. Claiming that encryption is enabled only for blob storage reads the template incorrectly and ignores the file service property. Thus the correct scope of protection spans multiple storage services, not a single one.

The Azure Firewall is in a different region than the spoke VNet.

Why it fails: Azure Firewall is a managed service that is routable via a private IP; VNet peering, including global peering, enables connectivity between hub and spoke VNets in different regions. As long as the spoke subnet has a route table with a next-hop of the firewall's private IP, traffic will be forwarded to the firewall regardless of region. The absence of a regional match does not change routing behavior, so this cannot be the reason traffic bypasses the firewall.

The Azure Firewall does not have the correct network and application rules configured.

Why it fails: Even if rules are missing, traffic would attempt to route through the firewall but be dropped, not bypass it. The question is about traffic bypassing the firewall entirely, which indicates a routing issue, not a rule issue.

The spoke VNet has the 'Use remote virtual network gateways' setting disabled.

Why it fails: The 'Use remote virtual network gateways' peering setting is specifically for gateway transit scenarios, where a VPN or ExpressRoute gateway in the hub is shared with peers, not for Azure Firewall, which is not a virtual network gateway. Azure Firewall is exposed via a standard private IP, and traffic is redirected to it using UDRs with next-hop type 'Virtual appliance'. Disabling this setting has no effect on firewall routing, so it cannot be the reason traffic is bypassing the firewall.

The policy should use 'Require MFA' instead of 'Block'

Why it fails: The policy's assignment and conditions are appropriately targeting the risky sign-in scenario, and a Block control is a valid remediation. The core misconfiguration is not the control itself; a report-only policy does not enforce any access controls, whether Block or Require MFA, so switching to Require MFA would still only produce a report and fail to prevent access. Changing the control would not fix the lack of enforcement.

The policy does not include the correct client app types

Why it fails: The client apps configuration already includes Exchange ActiveSync and otherClients, which are exactly the categories used for legacy authentication protocols such as basic authentication for Exchange Online and other older clients. There is no missing client app type in this policy; the block would apply to both modern and legacy clients once the policy is actually enforced. The inability to block is caused by the policy being in report-only mode, not by a gap in the client app selection.

The policy should include 'mobileAppsAndDesktopClients' instead

Why it fails: This option misidentifies the relevant client app category: 'Mobile apps and desktop clients' is for clients using modern authentication, while the policy needs to cover legacy clients that use basic protocols, which are represented by 'Other clients' and Exchange ActiveSync. The policy already includes the correct client app types for the legacy authentication scenario, so replacing them with mobileAppsAndDesktopClients would not improve coverage. Even if the client app type were changed, the policy would remain non-enforcing because it is in report-only mode, so this is not the cause of the problem.

It restricts inbound traffic to TCP only.

Why it fails: The NSG rule's protocol is set to 'Any', not specifically TCP. A protocol value of Any means the rule applies to TCP, UDP, ICMP, and every other IP protocol. Since there is no protocol filter limiting the rule to TCP, the statement that it restricts inbound traffic to TCP only is false.

It blocks all inbound traffic except HTTP.

Why it fails: The rule's action is 'Allow', not 'Deny', and its scope is not limited to HTTP traffic. The rule permits all inbound traffic regardless of protocol or port, so it cannot block any traffic. In contrast, a rule that blocks all traffic except HTTP would need an explicit 'Deny' action for other protocols and a specific 'Allow' for port 80/TCP.

It restricts inbound traffic to HTTP only.

Why it fails: The rule does not contain any port or protocol condition that would restrict traffic to HTTP. HTTP typically uses TCP port 80, but this rule has 'Port Range: Any' and 'Protocol: Any', meaning it allows HTTP as well as all other services such as HTTPS, RDP, SSH, and custom applications. There is no 'HTTP-only' filter present in the rule.

A default NSG is automatically associated with the subnet.

Why it fails: Azure does not automatically create or associate a default NSG with a subnet. Subnets have no built-in NSG unless one is explicitly attached, and Azure Policy will not inject a default resource to satisfy a deny effect. The policy evaluates the incoming virtual network deployment as-is, sees a subnet without an NSG, and blocks the entire request, so the premise of an auto-created default NSG is false.

The virtual network is created, but the subnet is denied.

Why it fails: The deny effect does not allow a virtual network to be created while only the offender subnet is skipped. Azure Policy treats the virtual network and its subnets as a single resource definition during evaluation, so if any subnet is non-compliant, the entire virtual network is denied. Partial deployment or a 'denied subnet' is not how policy enforcement works; the resource is all-or-nothing.

The virtual network is created, and a non-compliant alert is generated.

Why it fails: A deny effect does not create the resource and then generate a non-compliance alert; it blocks the deployment before any resource is provisioned. An alert or audit event only occurs with the 'audit' effect, which logs compliance status but does not prevent creation. Therefore, the virtual network would not exist at all, and there is no resource to report as non-compliant.

Next hop

Why it fails: Next hop diagnostics in Network Watcher determines the route and next hop IP address for traffic sent from a VM to a given destination. It only reveals the routing path (e.g., to Azure Firewall or a virtual appliance) and does not evaluate whether any security rules along that path allow or deny the packet. Even if the next hop is correctly set to Azure Firewall, the firewall may still drop the traffic, so this tool cannot confirm the specific firewall rule that blocked it.

Network Performance Monitor

Why it fails: Network Performance Monitor is a Network Watcher-based monitoring solution designed to measure latency, packet loss, and network availability between endpoints using monitoring agents. It provides aggregate performance metrics and alerts but does not simulate individual packets through security rule evaluation. As a result, it cannot determine whether Azure Firewall is denying a particular traffic flow or identify the specific rule responsible for the drop.

IP flow verify

Why it fails: IP flow verify in Azure Network Watcher is the correct tool because it simulates a packet with the exact source IP, destination IP, protocol, and port, then evaluates it against all effective security rules, including Azure Firewall rules and NSG rules. It returns a definitive 'Allowed' or 'Denied' result and lists the specific rule that caused the decision, enabling precise identification of the firewall rule blocking traffic. This targeted diagnostic makes it superior to the other options for troubleshooting a suspected Azure Firewall deny.

Allows outbound SSH traffic from 10.0.1.0/24 to 10.0.0.0/24.

Why it fails: This rule's direction is Inbound, so it is evaluated only for traffic entering the Azure network interface or subnet from the source prefix. The proposed statement describes an outbound flow, which would instead be matched against an outbound NSG rule with the source and destination reversed. Because this rule's action is Allow on an Inbound rule, it cannot permit or govern outbound SSH from 10.0.1.0/24 to 10.0.0.0/24.

Blocks inbound SSH traffic from 10.0.0.0/24 to 10.0.1.0/24.

Why it fails: The access value for this rule is 'Allow', not 'Deny', so it explicitly permits TCP port 22 traffic rather than rejecting it. An NSG rule prevents traffic only when the action is Deny; Allow rules are processed by priority and, if matched, the traffic is permitted before any lower-priority deny rule can be considered. Therefore the statement that it blocks inbound SSH is factually backwards—the rule is a positive permit for SSH from the specified source to destination.

Allows all inbound traffic from 10.0.0.0/24 to 10.0.1.0/24.

Why it fails: The rule's protocol is restricted to TCP and its destination port is set to 22 (SSH), so it does not apply to UDP, ICMP, or any other TCP port. To allow all inbound traffic, the protocol would need to be set to '*' and the destination port range to '*', which this configuration does not do. Thus, while the rule does allow inbound SSH, it is incorrect to characterize it as allowing all inbound traffic from 10.0.0.0/24 to 10.0.1.0/24.

Deploy Azure Firewall in the hub.

Why it fails: Azure Firewall is a fully managed, platform-as-a-service firewall, not a network virtual appliance that you deploy and operate as a VM. The requirement is to use an NVA, and Azure Firewall cannot act as that NVA because it has no VM image, no custom routing software, and you don't control its underlying routing. Even if you placed Azure Firewall in the hub, you would still need UDRs pointing to its private IP for inspection, but that still doesn't satisfy the explicit 'NVA' requirement. It is wrong because it replaces the NVA with a different service, not because it can't inspect traffic.

Configure VNet peering between all spokes.

Why it fails: VNet peering is non-transitive and creates a direct, layer-3 connection between the peered VNets. If you peer all spokes together, traffic from one spoke to another flows directly across that peering, completely bypassing the hub and any NVA firewall deployed there. In a hub-spoke design you should only peer each spoke to the hub, then force inter-spoke traffic through the hub NVA using UDRs. Direct spoke-to-spoke peering defeats the security inspection requirement and therefore does not meet the design goal.

Use a VPN gateway to route traffic through the hub.

Why it fails: A VPN gateway in the hub is designed for encrypted IPsec tunnel termination between Azure and on-premises networks or between VNets; it forwards packets based on its routing table and does not perform stateful inspection or content filtering like an NVA. Placing a VPN gateway in the hub does not by itself route spoke-to-spoke traffic through it because peered spokes use the Azure backbone directly, not the gateway. To actually force traffic through an NVA you need UDRs with the NVA IP as the next hop; a VPN gateway cannot serve as that next hop for inspection traffic. It is wrong because it provides connectivity, not inspection.

Change the effect to 'audit' instead of 'deny'.

Why it fails: The `audit` effect in Azure Policy only logs a non-compliance event to the activity log after a resource is created or updated; it does not intercept the request, so an NSG rule change would still succeed. The scenario requires blocking NSG rule modifications, which means the `deny` effect must remain in place to prevent the operation in Resource Manager. An audit-only approach would fulfill reporting and alerting needs but fails the explicit security requirement.

Add an exemption for the virtual network resource group.

Why it fails: Creating a policy exemption for the virtual network resource group would exclude all resources in that group from the policy assignment's evaluation, including both subnets and network security groups. This means NSG rule changes would no longer be blocked, which undermines the requirement that such changes be denied. Exemptions are meant for temporary or justifiable compliance exceptions, not for redesigning a policy's intended effect, and they would leave the security gap open.

Remove the policy assignment and create a custom role to block subnet creation.

Why it fails: Removing the policy assignment entirely eliminates the deny effect that blocks NSG rule changes, and a custom RBAC role that denies subnet writes only applies to principals assigned that role. It would not stop an Owner, service principal, or delegated administrator with broader permissions from creating subnets, and it leaves NSG rule changes completely unprotected without any compensating control. This approach is a fragmented, role-based workaround that introduces additional management complexity and fails to address the policy rule misconfiguration at its source.

Email notifications are sent only to admin@contoso.com.

Why it fails: It claims notifications are sent only to admin@contoso.com, but the emailAccountAdmins property is true. That flag ensures the Azure account administrators (subscription/service admins) are also added to the notification list. Therefore, the recipient set includes account admins in addition to admin@contoso.com, so it is not the sole recipient.

Alerts are not retained because retentionDays is set to 30.

Why it fails: This option misinterprets retentionDays. A value of 30 indicates that alerts are retained for 30 days before they expire or are purged, not that alerts are not retained at all. Alert retention is separate from alert generation; state is Enabled here, and the retention period merely governs how long alert records are kept. Hence, alerts are still generated and stored for the configured duration.

All alerts are disabled because disabledAlerts is empty.

Why it fails: This option incorrectly assumes that an empty disabledAlerts array means all alerts are disabled. In reality, the disabledAlerts array specifies which alert types are turned off; an empty array means no alert types are disabled, so all alert types remain enabled. Since the policy state is Enabled and disabledAlerts is empty, all alerts are active, not disabled.

Auditing of database queries is not configured.

Why it fails: Azure SQL Database auditing records query and event logs for compliance and forensic analysis, while Advanced Threat Protection (ATP) is an independent security service that uses anomaly detection to identify threats. The PowerShell cmdlet in the exhibit returns only the ATP configuration state, not auditing settings, so the absence of auditing cannot be concluded from this output. Even if auditing were enabled, it would not provide the real-time anomalous-activity detection that ATP offers, making this option an incorrect explanation for why the database is vulnerable.

The database firewall allows all public IP addresses.

Why it fails: Azure SQL Database firewall rules are configured separately from threat protection settings and control network access to the database, not detection of anomalous activities. The cmdlet shown in the exhibit reports only the ATP state, so it provides no information about firewall rules, and allowing all public IP addresses would be a network exposure issue, not an anomaly-detection gap. ATP and firewall settings are independent security controls; a permissive firewall does not disable or reflect ATP's protection status.

Transparent data encryption is not enabled.

Why it fails: Transparent Data Encryption (TDE) is a separate security feature that encrypts data at rest, whereas Advanced Threat Protection (ATP) detects suspicious behavioral patterns during database access. The cmdlet output displays ATP status, not TDE status, so you cannot infer from it that TDE is disabled. Even if TDE were disabled, that would represent a storage-encryption deficiency, not a failure to protect against anomalous activities, making this option unrelated to the ATP state shown in the exhibit.

The key vault URI is incorrect

Why it fails: The key vault URI is not the problem because the format shown is syntactically valid: Azure Key Vault URIs always use the pattern https://{vault-name}.vault.azure.net/{object-type}/{name}/{version}. A malformed URI would produce a validation error such as "Invalid URI" or "KeyVaultUrlFailed", not an authorization failure. The error you are seeing points to the storage account being denied access to the key, not to an issue with the URI's structure.

The key name or version is missing

Why it fails: The key name and version are indeed both present in the provided snippet, so this is not the cause. A missing key name or version would cause a clear validation error, often with a message like "The specified keyvault key name is invalid" or "Key version is required"—not an authorization or permission failure. Since the configuration already includes a specific version, the storage account can resolve the key's material; the remaining issue is access, not completeness of the key identifier.

The key vault is in a different region than the storage account

Why it fails: The key vault being in a different region than the storage account is not a valid reason for this error. Azure Storage supports customer-managed keys from key vaults in any Azure region; the storage service accesses the key vault over the network using the key's URI. Cross-region failures would typically manifest as network connectivity problems or DNS resolution errors, not as an authorization failure. The error you are seeing is an access-permissions issue, which is independent of the key vault's geographic location.

All Microsoft Defender plans are automatically enabled for new resources

Why it fails: Auto-provisioning in Microsoft Defender for Cloud only deploys the Log Analytics agent (or Azure Monitor Agent) to Azure VMs for data collection. It does not enable any Microsoft Defender plan, such as Defender for Servers or Defender for SQL. Defender plans must be explicitly enabled at the subscription level, and each plan has its own pricing and feature toggles. A new VM inherits the plan state of its subscription, but the plan itself is not automatically activated simply because auto-provisioning is on.

Security policies are automatically assigned to new resource groups

Why it fails: Auto-provisioning does not create or assign Azure Policy or security policy assignments to new resource groups. Security policies (initiatives) in Defender for Cloud are assigned at the management group or subscription scope, and that assignment applies to resources within those scopes. Creating a new resource group does not generate a new policy assignment; the existing scope-level assignments still govern any resources placed in that group. Auto-provisioning is limited to agent deployment and has no effect on policy assignment lifecycle.

Continuous export of security alerts is enabled

Why it fails: Continuous export is a separate feature in Defender for Cloud that streams security alerts and recommendations to an Event Hub or a Log Analytics workspace via diagnostic settings. Enabling auto-provisioning for the Log Analytics agent does not turn on continuous export, nor does it configure any export targets. You must explicitly enable and configure continuous export, choosing which data types and the destination. The exhibit's auto-provisioning setting is unrelated to this alert streaming capability.

To list all alerts with severity 'High' in the last 7 days.

Why it fails: The query does not apply a severity filter, so it cannot be limited to 'High' alerts. It summarizes all alert names and severities and returns the top 10 by count, which includes alerts of every severity level and produces aggregated counts rather than individual alerts. Thus, this statement incorrectly describes the query's filter and output format.

To list all alerts generated in the last 7 days.

Why it fails: The query does not enumerate every alert; it condenses raw records via summarize into aggregated groups and then limits the result to ten rows using top. Consequently, it returns only the highest-count alert-name/severity combinations, not a comprehensive list of all alerts generated during the last seven days. The output cardinality is 10, not all matching records.

To list the count of alerts per severity for the last 7 days.

Why it fails: The summarize clause groups by both AlertName and Severity, not by Severity alone, so the top 10 results are distinct name/severity pairs rather than severity-level totals. To count alerts per severity, the query would need to group by Severity only, and a top 10 limit would be unnecessary if the intent were simply to show all severity counts. This statement misidentifies the grouping key.