Refer to the Exhibit Practice Questions

Connection troubleshoot

Why wrong: Connection troubleshoot is wrong for this scenario because it performs an end-to-end connectivity test between a source VM and a target destination over a given protocol and port, reporting latency, path hops, and any failures. However, a failed connection can result from multiple causes—such as routing issues, DNS resolution, network virtual appliances, or workload misconfigurations—and the output does not specifically identify which NSG rule allowed or denied the traffic. It is useful for general connectivity problems, but it lacks the rule-level precision needed to determine whether an NSG permits a specific TCP flow.

Packet capture

Why wrong: Packet capture is incorrect here because it records raw network traffic at the virtual machine's network interface, capturing the actual packets that traverse the NIC for later analysis with packet inspection tools. While this can reveal whether packets were sent or received, it does not directly report which NSG rule matched or whether traffic was blocked before reaching the OS—because packets dropped by an NSG never appear in the capture. It requires extensive manual analysis and cannot provide the definitive 'allowed/denied' answer with the governing rule that IP flow verify delivers.

Next hop

Why wrong: Next hop is not the correct tool because it focuses exclusively on layer-3 routing: given a source VM and a destination IP, it returns the next hop type (e.g., internet, virtual network, virtual appliance, VPN gateway) and the next hop IP address. This indicates which route is used to forward traffic, but it completely ignores layer-4 protocol and port information and never evaluates NSG security rules. Therefore, it cannot determine whether an NSG would allow or deny a TCP flow—it only tells you the route the packet would take if it were allowed.

Assign a system-assigned managed identity to each VM.

Why wrong: A system-assigned identity is bound to one VM, so it cannot be shared cleanly across multiple machines.

Create a storage account access key and place it in each VM's application settings.

Why wrong: Sharing storage keys increases risk and does not satisfy the requirement to avoid secrets.

Create a separate SAS token for each VM and rotate it manually.

Why wrong: SAS tokens are limited-time secrets and do not provide the shared, identity-based access pattern requested.

Change the blob to the Cool access tier only, because Cool is always immediately readable.

Why wrong: Changing the blob to the Cool tier is not sufficient when the blob is already in the Archive tier. Archive is an offline tier, and any change to an online tier, including Cool, requires a rehydration process that moves the data from offline storage to an online state. Until that rehydration completes, the blob remains in a read-only, offline status; merely targeting Cool does not make it immediately readable. The rehydration delay and the need to wait still apply, so this action does not meet the report's urgent access requirement.

Create a snapshot of the archived blob and use the snapshot instead.

Why wrong: A blob snapshot captures the state of the blob at the time the snapshot is taken, but it does not bypass the archive tier. If the source blob is in the Archive tier, a snapshot is also stored in the Archive tier and remains offline until rehydrated. Creating a snapshot therefore does not provide immediate readability and is not a substitute for initiating a rehydration operation. You would still need to change the tier or use the rehydrate action before either the snapshot or the original becomes accessible.

Enable versioning on the storage account so the file becomes readable again.

Why wrong: Enabling versioning on the storage account affects how future writes create new versions, but it does not change the tier or availability of an existing archived blob. If the current version is already in the Archive tier, all versions, including prior ones, are stored under the same tiering constraints. Versioning also does not trigger any rehydration action; the archived blob remains offline and unreadable. Therefore, enabling versioning does not restore immediate access to the file for the report.

Change the hub VNet to use a smaller subnet mask.

Why wrong: Peering problems caused by overlapping ranges are not fixed by simply resizing the hub network. The overlap must be removed between the two VNet address spaces first.

Add a route table to the spoke VNet before creating peering.

Why wrong: Route tables control traffic flow after connectivity exists, but they do not solve CIDR overlap during peering creation. The error in the exhibit is about address space conflict, not routing.

Enable a service endpoint on both VNets.

Why wrong: Service endpoints extend access to supported Azure services, but they do not affect VNet-to-VNet address space validation. They cannot make overlapping peering ranges acceptable.

Remove the policy assignment from the subscription until the migration finishes.

Why wrong: Removing the assignment disables the control for all storage accounts, not just the legacy one. That creates a governance gap and allows any other storage account to become public. The requirement is to keep the policy active everywhere except one resource.

Change the policy effect from Deny to Audit.

Why wrong: Switching the effect from Deny to Audit would stop Azure Policy from blocking noncompliant storage accounts, meaning every storage account in the subscription—not just stlegacy01—would be allowed to become publicly accessible. The policy would then only log compliance data, which does not satisfy the requirement to enforce the control for other resources. An exemption targets a single scope and preserves the Deny effect everywhere else, whereas changing the effect weakens the entire policy baseline. This option is fundamentally a policy change, not a scoped exception, so it fails to maintain the intended security posture.

Move the legacy storage account to a separate subscription and assign the policy there.

Why wrong: Moving the resource to another subscription is disruptive and does not directly address the governance need. It is also unnecessary when Azure Policy exemptions already support temporary, scoped exceptions. The question asks for the simplest correct governance action.

Deploy the VMs in the same availability zone.

Why wrong: Placing both VMs in the same availability zone ties them to the same independently powered and cooled datacenter facility within the region. A zone-level outage—such as a datacenter-wide power failure—would take both VMs offline, so this configuration still does not address host-level failures; moreover, VMs within a single zone can reside on the same physical host, making them vulnerable to the exact host maintenance and hardware issues the business wants to avoid. The requirement is about surviving planned maintenance and a specific hardware failure, not an entire datacenter failure, so using an availability zone is both overkill and insufficient. Proper zone-based high availability would require placing the VMs in separate zones.

Use a virtual machine scale set with autoscale only.

Why wrong: A virtual machine scale set with autoscale rules only adjusts the instance count based on metrics like CPU or memory usage; it does not inherently guarantee placement across fault domains or update domains unless you explicitly configure an availability zone or use multiple placement groups. Autoscaling is designed to handle load changes, not to provide host-level fault tolerance, and with only two instances, an underlying host failure could still affect both instances if they happen to share the same physical host. While scale sets can be part of a high-availability architecture, simply enabling autoscale fails to meet the specific requirement of keeping two VMs running through host maintenance and hardware failures.

Place both VMs on a dedicated host.

Why wrong: A dedicated host is a single physical server allocated exclusively to you, and all VMs placed on it share that same underlying hardware. If the host experiences a hardware failure or requires planned maintenance, every VM on that host fails or restarts simultaneously, creating a single point of failure. An availability set, by contrast, spreads VMs across different hosts in multiple fault domains and update domains, which directly protects against host-level outages. Therefore, a dedicated host does not meet the requirement for the two VMs to stay available during host-level events.

Assign Reader to RG-Web, because the group can then inherit access to resources in that resource group only.

Why wrong: Assigning Reader at the RG-Web scope limits access to only that resource group and the resources it currently contains; RG-Data, which also resides in the Sales subscription, would remain completely inaccessible to the auditors. Additionally, this scope does not cover any future resource groups created in the Sales subscription, so new resources would automatically be excluded. Because the requirement is to grant read access across all current and future resources in Sales, a single resource-group assignment is insufficient and far narrower than the required subscription-level scope.

Assign Reader to the Corp management group, because that is the only scope that can cover multiple subscriptions.

Why wrong: The Corp management group is the root management group that contains both the Sales and Research subscriptions, so a Reader assignment at this scope would inherit down to every subscription beneath it, granting auditors read access to Research, which is explicitly prohibited. Management group scope is not the only way to cover multiple subscriptions; you can assign the Reader role directly at the Sales subscription scope to achieve the desired coverage without spilling permissions. Using a management group when subscription scope suffices violates the principle of least privilege, because it expands the blast radius far beyond the stated requirement.

Assign Reader to each resource individually, because that avoids inheritance and limits visibility to selected items.

Why wrong: Assigning Reader individually to each resource requires enumerating every resource, and you must repeat this process for every resource created in the future, making it operationally burdensome and highly prone to omissions. This approach ignores Azure RBAC’s inheritance model, which is designed to propagate permissions from parent scopes to child resources. Even if you could track all resources today, any new resource group or resource deployed by a template would lack access until you manually add another role assignment, so it fails the requirement for full, ongoing coverage in the Sales subscription.

A Standard HDD managed OS disk.

Why wrong: A Standard HDD managed OS disk uses magnetic spinning media, resulting in significantly higher I/O latency and lower IOPS than an ephemeral OS disk, which is stored on high-speed local SSD or NVMe on the VM host. While Standard HDD is cheap and durable, it directly contradicts the requirement for the lowest practical latency for the OS disk. An ephemeral OS disk sacrifices persistence to achieve the best performance, which is exactly what a rebuildable development virtual machine requires.

A premium managed data disk used as the OS disk.

Why wrong: A premium managed data disk is a separate volume used for application data, not a valid boot disk for a VM. Although a premium managed disk can be used as an OS disk, the wording 'data disk' indicates it is not attached as the boot disk; and in this scenario, the requirement explicitly asks for the lowest practical latency for a rebuildable development VM. An ephemeral OS disk on local VM storage provides lower latency than any attached managed disk and avoids paying for durability that will never be used.

A shared disk attached to multiple VMs.

Why wrong: Azure shared disks are designed for clustered workloads such as SQL Server Failover Cluster Instances or Scale-Out File Server, where multiple VMs need concurrent read/write access to the same storage volume. An OS disk must be dedicated to a single VM and cannot be shared; each VM boots from its own unique OS disk, and shared disks are intended as data disks only. Choosing a shared disk would not satisfy the requirement for a single development VM and would introduce cluster complexity without improving OS disk latency.

ReadOnly lock, because it prevents all changes and keeps resources fully protected.

Why wrong: ReadOnly is too restrictive because it blocks write operations as well as deletions. The scenario says administrators must still be able to update settings, so a ReadOnly lock would prevent legitimate management tasks and break the requirement.

No lock is needed because Azure RBAC already prevents deletion by default.

Why wrong: Azure RBAC does not block deletion by default; it only grants or denies permissions based on assigned roles. A user holding a role such as Contributor or Owner has the authority to delete resources unless an explicit deny assignment is in place. Resource locks function as an authoritative restriction that overrides RBAC for all users, protecting the resource group from accidental deletion even when administrators need update permissions.

Management group lock, because all changes in the tenant must be blocked centrally.

Why wrong: Management groups are for organizing subscriptions and applying governance at a high level, but the question is about protecting one resource group. A management group lock is not the right concept here and would be far broader than required.

Delete the policy assignment from corp-root and recreate it later.

Why wrong: Deleting the assignment would remove enforcement for the entire management group, not just the requested resource group. That would create a governance gap and allow other noncompliant resources to slip through during the merger period.

Move rg-merger01 to a separate subscription so the policy no longer applies.

Why wrong: Moving the resource group is disruptive and unnecessary. It also does not solve the policy control problem in the simplest way. Azure Policy exemptions are specifically designed for temporary, scoped exceptions without restructuring the environment.

Change the policy effect to Audit so the resources can remain noncompliant.

Why wrong: Changing the policy effect to Audit would alter the enforcement behavior for every resource under the corp-root management group, not just rg-merger01. Audit mode only logs noncompliance without blocking or remediating, so it would silently allow all tag violations across the entire hierarchy, creating a broad governance gap. This is a disproportionate, global change when a scoped exemption is the intended mechanism for a temporary, single-resource-group exception.

Backup policy, because it shows the retention and schedule configuration.

Why wrong: The Backup policy blade defines the backup schedule and retention rules, such as when backups are taken and how long recovery points are kept. It does not store any runtime execution history or per-attempt error information, so it cannot indicate whether a specific backup job succeeded or failed. It is a configuration object, not an operational log, making it the wrong place to look for failure details.

Backup items, because it lists protected resources and recovery points.

Why wrong: The Backup items blade shows the protected resources within the vault and their associated recovery points. While it may show the latest backup status for each item, it does not provide the granular error details or job-level history of individual backup attempts. Its purpose is to manage and monitor the protection state of workloads, not to drill into the failure diagnostics of a specific job entry.

Properties, because it contains the general vault settings.

Why wrong: The Properties blade displays general vault-level settings such as the vault's subscription, resource group, ID, and encryption configuration. It contains no backup job activity, job history, or runtime errors, and it is not designed to surface operational health information. Because the exhibit shows a failed backup job, the Properties blade lacks any of the diagnostic data needed to investigate the failure.

Assign Reader to OpsGroup at the Corp management group.

Why wrong: The Corp management group is a higher-level scope that includes both Prod and Sandbox, so selecting it would inadvertently grant Reader access to Sandbox resources. Since RBAC assignments at a management group are inherited by all child subscriptions, resource groups, and resources, this assignment would exceed the stated security boundary. Scoping to Prod instead ensures Sandbox remains excluded while still covering all Prod subscriptions and future additions under Prod.

Assign Reader to OpsGroup at one application resource group in AppSub1.

Why wrong: Assigning Reader at the application resource group limits the permission boundary to only the resources within that single resource group. Resources in other resource groups within AppSub1, and every other subscription under Prod, would not receive Reader access, and future subscriptions added to Prod would not automatically inherit any permissions. This falls short of the requirement for uniform read-only access across all Prod subscriptions and their resources.

Assign Reader to OpsGroup at each subscription individually.

Why wrong: Assigning Reader to each subscription individually is administratively redundant and hard to scale, as every new subscription added under Prod would require a separate assignment to maintain the same access. This approach also creates a risk of inconsistency, where some subscriptions might be missed during onboarding, leaving teams without the necessary read access. Management group scoping is the preferred method because a single assignment applies uniformly to all current and future child subscriptions under Prod.

Increase the deny rule priority number from 200 to 300.

Why wrong: Increasing the deny rule's priority number from 200 to 300 lowers its precedence, meaning it will be evaluated later in the rule sequence. However, the admin allow rule still has a higher numeric priority (e.g., 400), so it is evaluated after the deny rule and will never be matched. The correct fix is to make the allow rule's numeric priority lower than 200 so that it is evaluated before the deny rule; simply renumbering the deny rule does not guarantee the allow rule is reached.

Change Allow-HTTPS-Admin to use protocol Any.

Why wrong: Changing the protocol to Any would only broaden the rule's matching criteria; it does not change the order in which NSG rules are evaluated. Because the deny rule at priority 200 is processed first, any subsequent allow rule, regardless of protocol, will never be reached. It also weakens security by permitting all protocols for that rule while leaving the precedence issue unresolved.

Assign a public IP address to the VM.

Why wrong: Assigning a public IP address to the VM only provides a routable inbound endpoint; it has no effect on NSG rule evaluation. NSG filters are applied at the subnet or network interface level before traffic reaches the guest OS, so the deny rule still applies exactly the same. The VM's own public IP does not change the source IP of the request, nor does it cause the NSG to skip the deny rule.

A network security group attached to GatewaySubnet.

Why wrong: An NSG attached to GatewaySubnet is not a deployment requirement and is actually unsupported for VPN gateways because it can interfere with the control-plane traffic that Azure must send to the gateway instances. The exhibit already has GatewaySubnet, but the actual missing resource is a public IP address that gives the on-premises VPN device a routable endpoint to terminate the encrypted tunnel. Filtering traffic on this subnet would not create that public endpoint and could prevent the gateway from provisioning or operating correctly.

A route table with a default route to the on-premises network.

Why wrong: A route table with a default route to the on-premises network is a user-defined route (UDR) that would only be relevant after a site-to-site tunnel is established, and it would cause outbound Internet traffic to be force-tunneled through the VPN device. It does not supply the public IP address resource that the VPN gateway must be associated with during its deployment, because the gateway's external endpoint is essential for the initial IPsec handshake. Moreover, applying such a route to GatewaySubnet is unsupported and can break gateway connectivity.

A private endpoint for the on-premises VPN device.

Why wrong: A private endpoint is designed to provide an Azure PaaS service with a private IP address inside your virtual network, enabling inbound access over a private connection rather than through the public Internet. An on-premises VPN device cannot use a private endpoint to terminate a site-to-site IPsec tunnel, because the VPN gateway itself must expose a public IP address as the tunnel endpoint. This option fails to address the actual missing resource and would not allow the VPN gateway to be deployed.

A NAT gateway on the GatewaySubnet to translate tunnel traffic.

Why wrong: A NAT gateway on GatewaySubnet is an outbound internet translation mechanism for VMs and workloads; it does not provide a globally routable ingress endpoint for VPN tunnels. A site-to-site VPN gateway receives inbound IPsec connections on its associated public IP, and a NAT gateway cannot supply that public IP resource or act as the tunnel endpoint. Even if a NAT gateway were deployed, the validation failure for a missing gateway public IP address would remain unresolved.

A private endpoint in the GatewaySubnet for tunnel termination.

Why wrong: Private endpoints are designed to provide private, inbound connectivity to PaaS services using VNet IP addresses; they are not VPN termination points. Site-to-site tunnels terminate on the VPN gateway, which must have a public IP address to be reachable from the on-premises device. A private endpoint has no public IP and cannot accept IPsec or IKE traffic, and placing one on GatewaySubnet would not address the missing gateway public IP resource that is causing the validation failure.

A network security group that allows inbound TCP 443 to the subnet.

Why wrong: An NSG allowing inbound TCP 443 is irrelevant to site-to-site VPN tunnel establishment. IPsec IKE and ESP traffic uses UDP 500 (IKE), UDP 4500 (IPsec NAT traversal), and ESP protocol 50, not TCP 443. Moreover, Azure VPN gateways require a dedicated public IP resource to be attached to the GatewaySubnet; the validation error is about that missing public IP, not about a missing inbound permission. NSGs on GatewaySubnet also have specific required rules, and adding unrelated rules does not satisfy gateway creation prerequisites.