Microsoft Azure Administrator AZ-104 Exam Questions

Answer : B, D

A public IP address in Azure is never associated directly with a virtual machine resource --- Microsoft's official 'Associate a public IP address' documentation confirms that for VMs, the association point is the network interface's IP configuration, not the VM object itself, so VM1 (A) is not a directly associable target and the original answer key is corrected to NIC1 (B). A public IP is validly associated with a network interface's IP configuration (NIC1) for a standalone VM, and with a public Load Balancer's frontend IP configuration (LB1) to provide internet-facing access to backend pool VMs. A virtual network gateway (VPN1) does use a public IP, but its gateway IP configuration is fixed at gateway creation/resize time rather than being something you freely 'associate' a separate new IP resource to after the fact, and VNet1 (E) can never hold a public IP at all since address-space objects don't have IP configurations. The corrected two answers are NIC1 and LB1.

Official Reference

Associate a public IP address to a virtual machine / Manage public IP addresses --- https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/associate-public-ip-address-vm

Answer : B

Moving a VM to a different resource group (or subscription) is a Resource Manager metadata/management-group operation; it changes which resource group manages the VM but does not migrate the VM's compute allocation to a different physical host, and it does not interact with the Azure maintenance/health subsystem at all. To immediately move a VM off its current host in response to a planned-maintenance or degraded-host notification, you must use the VM's Redeploy action (Overview blade > Redeploy, or Restart-AzVM -PowerState/Set-AzVM redeploy equivalents), which shuts down the VM, moves it to a new physical node in the Azure fabric, and restarts it while keeping the same VM configuration and IP addresses (for most SKUs). Since a resource-group move does not achieve host relocation, the solution does not meet the goal.

Official Reference

Redeploy a VM to a new Azure node --- https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/redeploy-to-new-azure-node

Answer : B

Microsoft Learn's App Service resource-move documentation makes clear that a web app and its App Service plan are separate, independently movable resources --- moving only the WebApp1 resource to RG2 does not relocate its App Service plan, which stays exactly where it was (West Europe) unless the plan is explicitly included in the same move operation. A web app can validly reference a plan that sits in a completely different resource group or even subscription; region and resource-group membership of the plan are not tied to the web app's own resource-group metadata. Separately, Azure Policy assignments are evaluated based on a resource's current resource group: once WebApp1 is moved into RG2, RG2's assigned policy (Policy2) becomes the policy that applies to it going forward, and Policy1 (tied to RG1) no longer applies since WebApp1 has left that scope. Combining these two facts, the correct outcome is that the plan remains in West Europe while Policy2 now applies --- option B.

Official Reference

Move an App Service resource to a new resource group or subscription --- https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/move-limitations/app-service-move-limitations

Answer : C

Availability Zones are physically separate datacenters within a region, each with independent power, cooling, and networking, so a failure of one entire datacenter affects only the VM(s) in that zone. Placing each of the three VMs in a different Availability Zone ensures that even if one zone/datacenter fails entirely, the VMs in the other two zones remain available -- guaranteeing at least two of three VMs stay up. An Availability Set only protects against rack-level failures (power/network) within a SINGLE datacenter and provides no protection if that entire datacenter goes offline, so options B and D do not meet the requirement, and placing all VMs in one zone (A) offers no protection at all if that zone fails.

Official Reference

Availability options for Azure Virtual Machines --- Availability Zones --- https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview

Answer : C

Azure distributes the VMs in an availability set across its update domains in round-robin fashion. With 16 VMs spread across 5 update domains, the distribution is as even as possible: one update domain receives 4 VMs (16 = 4 + 3 + 3 + 3 + 3) and the remaining four update domains receive 3 VMs each. During planned maintenance (a platform update), Azure updates and reboots only one update domain at a time, so the worst-case number of VMs taken offline simultaneously equals the size of the largest update domain, which is 4. The minimum number of VMs that remain available during that maintenance window is therefore 16 - 4 = 12. Fault domains (which protect against simultaneous hardware/rack failure rather than planned maintenance) are not the limiting factor for this specific question about planned maintenance availability.

Official Reference

Availability sets overview --- https://learn.microsoft.com/en-us/azure/virtual-machines/availability-set-overview

Answer : C

VM1 and VM4 sit in two different virtual networks (VNET1 and VNET3 respectively), which by default cannot route traffic to one another at all --- VNets are isolated unless explicitly connected. Virtual network peering is the lowest-effort way to connect two VNets in the same region (or globally, with global peering): it is a simple, portal/CLI-configurable relationship that establishes low-latency, private connectivity over the Microsoft backbone without deploying any gateway, VPN device, or custom routing, and it is created in a couple of clicks/commands with no ongoing management overhead. A user-defined route (option A) requires a next hop -- typically a virtual appliance or gateway -- that does not exist here and does not, by itself, create reachability between unconnected VNets. Manually reassigning VM4's IP (option B) doesn't address the routing isolation and would likely conflict with VNET3's own address space. Creating and associating a new NSG (option D) only affects filtering, not reachability, and does not connect the two VNets. Peering (option C) is correct and unchanged.

Official Reference

Virtual network peering --- https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview

Answer : A, C, E

Azure Data Lake Storage Gen2 is not a separate product but a capability set unlocked on a standard Blob/general-purpose v2 account by enabling hierarchical namespace (option C) at account creation. Minimizing cost for infrequently accessed data is achieved with the Cool access tier (option A), which charges lower storage cost than Hot in exchange for a higher per-transaction/read cost, appropriate for data accessed less than once a month. Automatic replication to a secondary Azure region is provided only by geo-redundant storage options; zone-redundant storage (option D) replicates synchronously across availability zones within a single region and never leaves that region, so it does not satisfy 'secondary region' --- geo-redundant storage (option E) is required for that. The Hot tier (option B) is the opposite of cost-minimizing for infrequently accessed data. The three correct configuration choices are the Cool access tier, hierarchical namespace, and geo-redundant storage --- A, C, and E --- matching the given answer.

Official Reference

Introduction to Azure Data Lake Storage Gen2 / Hot, Cool, and Archive tiers --- https://learn.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-introduction