Microsoft AZ-104 Practice Test 78
Question 770
An engineer deletes the public IP resource and assumes the same global IP can be recreated later. What risk exists?
- Recognize the address may be released on resource deletion and cannot always be recovered.
- Use nonoverlapping VNet address prefixes and check peering conflicts.
- Use 10.2.2.0/25 and 10.2.2.128/25 as the two nonoverlapping child subnets.
- Associate a route table containing the desired user-defined routes with the subnet.
Explanation
Correct Answer
A:Releasing the address resource can return it to the pool. Retaining the IP resource is safer than relying on reacquisition. This matters here because an engineer deletes the public IP resource and assumes the same global IP can be recreated later. What risk exists.
Incorrect Answers
B:A VNet cannot contain conflicting address spaces in ways that undermine subnet allocation and routing. Peering also requires unique address planning. This matters here because an engineer deletes the public IP resource and assumes the same global IP can be recreated later. What risk exists.
C:Two /25 blocks partition the /24 address space exactly. Their network boundaries align with the prefix size. This matters here because an engineer deletes the public IP resource and assumes the same global IP can be recreated later. What risk exists.
D:User-defined routes can override applicable system routes by prefix specificity and source priority. An NSG rule does not choose next hops. This matters here because an engineer deletes the public IP resource and assumes the same global IP can be recreated later. What risk exists.
Question 771
A peered VNet must reach a third-party router VM behind the peer. Can peering automatically provide transit through that peer?
- Enable gateway transit on the hub peering and remote gateway use on the spoke peering where supported.
- Explicitly design forwarded traffic and routes because VNet peering is nontransitive by default.
- Create a route table with a user-defined route whose next hop is the virtual appliance IP.
- Longest-prefix match selects the most specific matching effective route.
Explanation
Correct Answer
B:VNet peering directly connects peers, but does not automatically turn a hub into a transit router for all spokes. This matters here because a peered VNet must reach a third-party router VM behind the peer. Can peering automatically provide transit through….
Incorrect Answers
A:Gateway transit permits a spoke to use a hub gateway under supported topology constraints. Peering alone does not automatically grant remote gateway use. This matters here because a peered VNet must reach a third-party router VM behind the peer. Can peering automatically provide transit through….
C:UDRs can direct matched destination prefixes to a network virtual appliance. The appliance must be reachable and configured for forwarding. This matters here because a peered VNet must reach a third-party router VM behind the peer. Can peering automatically provide transit through….
D:A /24 destination match is more particular than /16. Effective routing chooses the longest matching prefix before considering source tie-breaking.
Question 772
Spoke A cannot reach Spoke B despite both peering to a hub VNet. What topology fix is needed?
- Inspect hub Allow gateway transit and spoke Use remote gateways settings plus effective routes.
- Configure supported hub routing through an NVA or gateway with allow-forwarded-traffic and UDRs as appropriate.
- Enable gateway transit on the hub peering and remote gateway use on the spoke peering where supported.
- Review the source NIC's effective routes and the matching user-defined route.
Explanation
Correct Answer
B:Spoke-to-hub peering does not automatically create spoke-to-spoke transitive routing. A routing service or topology change is needed. This matters here because spoke A cannot reach Spoke B despite both peering to a hub VNet. What topology fix is needed.
Incorrect Answers
A:A spoke must opt into supported remote gateway use. Gateway advertisements and route tables also determine reachability. This matters here because spoke A cannot reach Spoke B despite both peering to a hub VNet. What topology fix is needed.
C:Gateway transit permits a spoke to use a hub gateway under supported topology constraints. Peering alone does not automatically grant remote gateway use. This matters here because spoke A cannot reach Spoke B despite both peering to a hub VNet. What topology fix is needed.
D:Effective routes show which prefix and next hop govern a destination. A VM's subnet attachment does not reveal overrides by itself. This matters here because spoke A cannot reach Spoke B despite both peering to a hub VNet. What topology fix is needed.
Question 773
An app subnet needs to resolve an on-premises private DNS zone through a centralized resolver. Which Azure managed option helps?
- Inspect effective NSG rules, user-defined routes and guest firewall on both ends.
- Check Private DNS virtual-network links and any resolver forwarding between networks.
- Use Azure DNS Private Resolver with an outbound endpoint and forwarding rule set.
- Provide a subnet NAT Gateway or another approved outbound path with suitable NSG rules.
Explanation
Correct Answer
C:Private Resolver can forward selected domain queries to reachable DNS servers without self-managed DNS VMs. This matters here because an app subnet needs to resolve an on-premises private DNS zone through a centralized resolver. Which Azure managed….
Incorrect Answers
A:Peering connectivity does not override security rules or guest firewalls. Connected peering is a network relationship, not authorization to every port. This matters here because an app subnet needs to resolve an on-premises private DNS zone through a centralized resolver. Which Azure managed….
B:Private zone records are visible through linked or appropriately forwarded resolution paths. VNet peering alone does not necessarily share zone links. This matters here because an app subnet needs to resolve an on-premises private DNS zone through a centralized resolver. Which Azure managed….
D:A private VM can reach public services through a managed outbound translation path without a directly attached public IP. This matters here because an app subnet needs to resolve an on-premises private DNS zone through a centralized resolver. Which Azure managed….
Question 774
Private Resolver forwarding rules are correct but a VNet's clients still query Azure default without forwarding. What should be checked?
- Review NSG and endpoint allow rules because Standard public IPs are secure by default.
- Select a subnet prefix within the VNet's declared 10.4.0.0/16 space.
- Check DNS forwarding ruleset links and resolver endpoint reachability for the client VNet.
- Check Private DNS virtual-network links and any resolver forwarding between networks.
Explanation
Correct Answer
C:Ruleset association determines which VNets use the forwarding configuration. Correct rules in an unlinked ruleset cannot affect clients. This matters here because private Resolver forwarding rules are correct but a VNet's clients still query Azure default without forwarding.
Incorrect Answers
A:A public address alone does not permit unsolicited traffic. Azure NSG and workload firewall permissions still govern ingress. This matters here because private Resolver forwarding rules are correct but a VNet's clients still query Azure default without forwarding.
B:A subnet must be fully contained within one of the VNet address prefixes. Private addressing alone does not make the prefix eligible. This matters here because private Resolver forwarding rules are correct but a VNet's clients still query Azure default without forwarding.
D:Private zone records are visible through linked or appropriately forwarded resolution paths. VNet peering alone does not necessarily share zone links. This matters here because private Resolver forwarding rules are correct but a VNet's clients still query Azure default without forwarding.
Question 775
An analyst needs to see TLS payload bytes but only flow records are available. What is the limitation?
- Check storage firewall network rules to permit the service-endpoint-enabled subnet.
- Recognize flow logs summarize network conversations and do not expose encrypted payload contents.
- Associate a suitable network security group with the subnet.
- Run Network Watcher IP flow verify for the VM and packet tuple.
Explanation
Correct Answer
B:Flow telemetry supports traffic-path analysis, not full packet inspection or decryption. Packet capture requires separately authorized diagnostics. This matters here because an analyst needs to see TLS payload bytes but only flow records are available. What is the limitation.
Incorrect Answers
A:Enabling a service endpoint alone does not authorize a subnet in every storage account. The service firewall must allow it. This matters here because an analyst needs to see TLS payload bytes but only flow records are available. What is the limitation.
C:Subnet-level NSGs apply to traffic entering or leaving its NICs, with any NIC NSGs also evaluated as applicable. This matters here because an analyst needs to see TLS payload bytes but only flow records are available. What is the limitation.
D:IP flow verify evaluates traffic against effective Azure security rules and reports an allow or deny rule. It is a diagnostic, not a rule mutation. This matters here because an analyst needs to see TLS payload bytes but only flow records are available. What is the limitation.
Question 776
An Azure firewall is configured as an NVA but traffic follows the regular Internet path. Which route control should be applied?
- Add a subnet NSG allow for TCP 443 and assume the Azure route table automatically forwards outbound traffic through an NVA.
- Create a targeted outbound NSG deny matching the malicious destination IP prefix.
- Associate a UDR directing the intended destination prefixes to the firewall appliance.
- Confirm the VM NIC's ASG membership and the NSG rules referencing that group.
Explanation
Correct Answer
C:User-defined routes can steer subnet traffic to a network appliance. Firewall existence alone does not insert it into the datapath. This matters here because an Azure firewall is configured as an NVA but traffic follows the regular Internet path. Which route control should….
Incorrect Answers
A:NSG access decisions do not select network next hops. Add a supported user-defined route to the firewall or virtual appliance for the intended destination prefixes.
B:A narrow deny can block only the disallowed destination while leaving approved paths intact. A whole-subnet default deny would have a wider effect. This matters here because an Azure firewall is configured as an NVA but traffic follows the regular Internet path. Which route control should….
D:ASG filtering depends on NIC membership and matching rule definitions. A VM resource tag alone does not assign it to an ASG. This matters here because an Azure firewall is configured as an NVA but traffic follows the regular Internet path. Which route control should….
Question 777
The appliance receives forwarded packets but cannot reach destinations after Azure peering. What must be checked?
- Inspect IP forwarding, appliance routing, peering flags and return-path routes.
- Enable Allow forwarded traffic on appropriate VNet peerings when the topology requires it.
- Use the service's supported DNS hostname resolving to the private endpoint rather than a fixed public IP.
- Review peering forwarded-traffic flags and UDRs across the transit path.
Explanation
Correct Answer
A:Traffic inspection requires symmetric or otherwise supported return routing. A one-way UDR cannot guarantee full connection success. This matters here because the appliance receives forwarded packets but cannot reach destinations after Azure peering.
Incorrect Answers
B:Forwarded-traffic peering settings permit traffic forwarded by NVAs under supported designs, alongside effective routes. This matters here because the appliance receives forwarded packets but cannot reach destinations after Azure peering.
C:Private Link depends on DNS-based service naming. Hardcoded public addresses bypass or break the intended private route. This matters here because the appliance receives forwarded packets but cannot reach destinations after Azure peering.
D:Spoke-to-spoke transit is not implicit. Both routing and peering permission for forwarded packets must align. This matters here because the appliance receives forwarded packets but cannot reach destinations after Azure peering.
Question 778
A VM has both NIC NSG and subnet NSG; a deny exists at either scope. Which decision model applies?
- Require traffic to be permitted by all applicable NSG filters before connection succeeds.
- The lower numerical priority 200 deny rule is evaluated first.
- Allow traffic whenever the NIC-level NSG permits it, even if the subnet NSG has a matching deny.
- Add a higher-priority narrow allow for HTTPS and retain the default deny.
Explanation
Correct Answer
A:A deny on an applicable NIC or subnet NSG can block traffic even if another NSG has an allow. Azure doesn't union permissions across independent filters. This matters here because a VM has both NIC NSG and subnet NSG; a deny exists at either scope. Which decision model applies.
Incorrect Answers
B:NSG priorities process lower numbers first; evaluation stops at the first matching rule. An allow at a later priority cannot override an earlier match. This matters here because a VM has both NIC NSG and subnet NSG; a deny exists at either scope. Which decision model applies.
C:A subnet-level deny still blocks traffic regardless of a NIC-level allow. Traffic must satisfy both applicable NSG evaluations, including their ordered rules.
D:A specific allow evaluated before the default deny admits only the intended port/source combination. Removing the default deny would widen exposure. This matters here because a VM has both NIC NSG and subnet NSG; a deny exists at either scope. Which decision model applies.
Question 779
A subnet NSG is removed, but inbound TCP remains blocked on one VM. What should be checked?
- Associate a suitable network security group with the subnet.
- Both subnet and NIC NSG evaluations must permit the connection; one allow cannot bypass another deny.
- Use the service's supported DNS hostname resolving to the private endpoint rather than a fixed public IP.
- Inspect any remaining NIC NSG and guest OS firewall policy.
Explanation
Correct Answer
D:Network filtering can occur at several layers. Deleting one NSG cannot override an independent NIC or guest firewall block. This matters here because a subnet NSG is removed, but inbound TCP remains blocked on one VM.
Incorrect Answers
A:Subnet-level NSGs apply to traffic entering or leaving its NICs, with any NIC NSGs also evaluated as applicable. This matters here because a subnet NSG is removed, but inbound TCP remains blocked on one VM.
B:NSG evaluation occurs at all applicable levels. The effective packet decision reflects combined constraints. This matters here because a subnet NSG is removed, but inbound TCP remains blocked on one VM.
C:Private Link depends on DNS-based service naming. Hardcoded public addresses bypass or break the intended private route. This matters here because a subnet NSG is removed, but inbound TCP remains blocked on one VM.
Question 780
An administrator wants to reduce public attack surface for PaaS while permitting clients from one private VNet. Which configuration should be prioritized?
- Use a public network service endpoint and assume its public PaaS service IP becomes an isolated Private Link address.
- Use a supported private endpoint and disable public network ingress to the PaaS resource.
- Require an Azure SQL private endpoint even when the PaaS workload is not an Azure SQL resource.
- ASG membership is a NIC configuration, not automatic matching from resource tags.
Explanation
Correct Answer
B:Private endpoint plus public access restriction narrows the service's exposed network paths. An NSG on the client subnet alone is not equivalent. This matters here because an administrator wants to reduce public attack surface for PaaS while permitting clients from one private VNet.….
Incorrect Answers
A:A service endpoint does not create a private endpoint IP. To eliminate public ingress, the service needs a supported private endpoint and private DNS path.
C:Private endpoints target the actual resource provider and subresource. An Azure SQL-specific endpoint cannot privately expose an unrelated PaaS service.
D:Azure resource tags and application security group membership are separate constructs. Tags cannot substitute for joining an ASG. This matters here because an administrator wants to reduce public attack surface for PaaS while permitting clients from one private VNet.….
