AZ-104 Which Command Should the Administrator Use Practice Questions

Explanation: Virtual network peering provides private connectivity between Azure virtual networks over the Microsoft backbone with low latency. VPN gateways are not required for this same-region scenario.

Explanation: These pairings reflect how Azure NSGs are actually processed. The lowest priority number is evaluated first, so a priority 100 rule takes precedence over priority 300 when both match. Inbound rules affect traffic entering the protected scope. A NIC NSG applies to one VM, while a subnet NSG applies to all resources in that subnet. Using '*' for source port range matches any source port, and TCP 443 specifically targets HTTPS traffic. Why others are wrong: Alternative pairings usually confuse priority order, traffic direction, or scope. A higher priority number does not win. Inbound rules do not govern outbound traffic. A NIC NSG is not the same as a subnet NSG, because one is per-VM and the other is broader. Limiting only the source port does not constrain the destination service, so it would not specifically represent HTTPS access.

Explanation: Service endpoints are the correct choice when you want to limit access to a subnet without moving the storage account to a private endpoint model. They keep the service on its public endpoint but let Azure recognize traffic from the specified subnet as allowed when the storage firewall is configured accordingly. This gives network restriction with less DNS complexity than private endpoints. Why others are wrong: Private endpoints are effective but explicitly excluded by the requirement. SAS tokens do not control subnet membership and cannot replace a network rule. Azure Policy can enforce settings, but it does not itself provide the subnet-to-storage connectivity needed for this scenario.

Explanation: A metric alert can evaluate the CPU metric against a threshold, and an action group can deliver the email notification.

Explanation: az deployment group what-if is the correct command because it performs a preview of the deployment outcome. It shows which resources will be created, updated, or deleted without actually applying the changes. That makes it very useful for safer administration, especially when you want to check the effect of a Bicep file before running the real deployment. Why others are wrong: az deployment group create performs the deployment instead of previewing it. az group delete is destructive and unrelated to deployment planning. az vm update only changes a VM resource and does not give you the full what-if analysis for an ARM or Bicep deployment.