Configure name resolution and load balancing

Oakhurst Learning operates a public Standard Load Balancer named LB-Portal with three backend VMs. The health probe is configured as HTTP on port 80 with request path /. After the web team enabled a site-wide redirect from HTTP to HTTPS on all three VMs, the load balancer's Health Probe Status metric dropped to 0 percent and users receive connection failures. Each VM still serves content correctly when accessed directly, and the NSG allows the AzureLoadBalancer service tag.

What is the most likely cause?

1. AThe probe path now returns an HTTP 301 redirect instead of HTTP 200, so the load balancer marks every instance unhealthy.An HTTP probe only treats an instance as healthy when the response is HTTP 200. A 301 or 302 redirect is a probe failure, so all three instances were removed from rotation at once.
2. BStandard Load Balancer requires at least one backend VM to have a public IP address.Backend VMs behind a public load balancer do not need their own public IPs; the frontend IP is the public entry point.
3. CThe probe interval is too short for the web server to respond.The probe interval did not change; the failure began exactly when the redirect was introduced.
4. DThe redirect caused the load balancer to lose its session persistence settings.Session persistence affects how clients are mapped to backends; it has nothing to do with probe results or backend health.

Ironvale Manufacturing has a private DNS zone named corp.ironvale.internal linked to VNet-Plant with auto-registration enabled, so every VM in VNet-Plant automatically gets an A record. A second virtual network, VNet-Office, is peered with VNet-Plant and its VMs use Azure-provided DNS. VMs in VNet-Office cannot resolve names such as plc-ctrl-01.corp.ironvale.internal, although they can ping the VM by IP address. The company wants VNet-Office VMs to resolve VNet-Plant names, but does not want VNet-Office VMs to be registered in the zone.

What should you do?

1. ACreate a virtual network link from corp.ironvale.internal to VNet-Office with auto-registration disabled.Private DNS zone resolution is scoped by virtual network links, not by peering. A resolution-only link lets VNet-Office query the zone without registering its own VMs.
2. BEnable the Allow forwarded traffic setting on both sides of the peering between VNet-Plant and VNet-Office.Peering settings govern packet forwarding. Private DNS zones are not propagated across peerings regardless of this setting.
3. CCreate a virtual network link from corp.ironvale.internal to VNet-Office with auto-registration enabled.This would allow resolution, but it also registers every VNet-Office VM in the zone, which the scenario explicitly does not want.
4. DChange the DNS servers setting on VNet-Office to the private IP address of a VM in VNet-Plant.Pointing DNS at an arbitrary VM does nothing unless that VM runs a DNS forwarder, and it adds an unnecessary dependency when a zone link solves the problem directly.

Meridian Ticketing is deploying a three-tier application in a virtual network named VNet-Tix. The web tier has four VMs that must receive HTTPS traffic from the internet. The API tier has three VMs on TCP 8443 that must be reachable only from the web tier at a single private IP address and must never be exposed to the internet. Each API VM exposes a /healthz endpoint over HTTP on port 8080 that returns 200 only when the API process is ready. All VMs are spread across availability zones.

Which two actions should you perform for the API tier? Each correct answer presents part of the solution.

1. ACreate an internal Standard Load Balancer with a frontend private IP address in a VNet-Tix subnet and add the three API VMs to its backend pool.An internal load balancer has only a private frontend, so it satisfies the single private IP and no-internet-exposure requirements, and the Standard SKU supports zone-redundant frontends and zonal backends.
2. BConfigure an HTTP health probe on port 8080 with request path /healthz and a load-balancing rule for TCP 8443 that uses that probe.An HTTP probe marks the instance healthy only on a 200 response, which maps exactly to the readiness semantics of /healthz, and the rule ties the probe to the 8443 traffic.
3. CCreate a public Standard Load Balancer with a Standard public IP and add the three API VMs to its backend pool.A public frontend exposes the API tier to the internet, which the scenario forbids.
4. DConfigure a TCP health probe on port 8443 and a load-balancing rule for TCP 8443.A TCP probe only checks that the port accepts a connection; it would report a VM healthy while the API process is still starting, which does not match the readiness requirement.
5. ECreate a Basic SKU internal load balancer to minimize cost.The Basic Load Balancer SKU is retired and does not support availability zones; new deployments must use Standard.

Coralview Travel hosts its public zone coralview-travel.example in Azure DNS. The website is served by a public Standard Load Balancer whose frontend uses a Standard public IP resource named pip-web. The company wants the zone apex (coralview-travel.example, with no host name) to resolve to the website, and wants the DNS record to update automatically if the public IP resource is ever replaced or its address changes.

Which record should you create in the zone?

1. AAn alias record set of type A at the apex that targets the pip-web public IP resource.Alias records can live at the zone apex and reference an Azure public IP resource directly, so the resolved address follows the resource automatically.
2. BA CNAME record at the apex that points to the DNS name label of pip-web.DNS standards do not allow a CNAME at the zone apex because it would conflict with the mandatory SOA and NS records.
3. CAn A record at the apex with the current IP address of pip-web and a TTL of 60 seconds.A static A record works today, but it does not track changes to the public IP resource; someone must update it manually if the address changes.
4. DAn NS record at the apex that delegates to the public IP resource.NS records delegate a subdomain to other name servers; they cannot point to an IP address or an Azure resource.