Microsoft AZ-700 Design, Implement, And Manage Azure ExpressRoute Practice Test

 

AZ-700 skill 2.3 | 46 original questions

This AZ-700 practice set focuses on design, implement, and manage azure expressroute through original scenario-based questions aligned to Microsoft skills measured as of July 27, 2026. The set is mapped to every official objective leaf assigned to this skill area. For broader exam preparation, review the Microsoft AZ-700 Exam Dumps page.

Instructions: Follow the selection count stated in each question. Review the rationale after answering. Every option includes a brief explanation of why it is or is not selected for the stated scenario.

Question 230

City Power & Light is reviewing a shared-services topology used by several application teams. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must select an ExpressRoute connectivity model; select an appropriate ExpressRoute SKU and tier; design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the hybrid connectivity team. Change window 1:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7230. Which THREE recommendations should be implemented together? Select THREE answers.

  1. Use Microsoft Defender for Cloud Secure Score recommendations to prioritize network hardening items by exposure, impact, and remediation value instead of treating every finding equally.
  2. Create a Public IP Prefix in the target region so deployments can consume a contiguous set of Azure public IP addresses from a reserved prefix.
  3. Choose the ExpressRoute SKU and bandwidth/tier that meet geographic reach, route-scale, FastPath/Direct requirements, and expected throughput without paying for unsupported features.
  4. Analyze flow-log tuples and traffic analytics to determine source/destination, ports, direction, allow/deny result, and traffic volume before changing NSG policy.
  5. Select the ExpressRoute connectivity model that matches the provider and physical topology: cloud exchange colocation, point-to-point Ethernet, any-to-any IPVPN, or ExpressRoute Direct.
  6. Use redundant ExpressRoute circuits/peerings and appropriately resilient gateways, with cross-region or disaster-recovery routing designed so a single circuit, provider edge, or region does not become a single point of failure.

Correct answers: C, E, F

Why: 2.3.1: This directly satisfies the requirement to select an ExpressRoute connectivity model. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.2: This directly satisfies the requirement to select an appropriate ExpressRoute SKU and tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.3: This directly satisfies the requirement to design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to evaluate network security recommendations identified by Microsoft Defender for Cloud Secure Score. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.4.5, but it does not directly satisfy the scenario requirement mapped to 2.3.1, 2.3.2, 2.3.3.

B: Not selected. This directly satisfies the requirement to create a Public IP Prefix. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.6, but it does not directly satisfy the scenario requirement mapped to 2.3.1, 2.3.2, 2.3.3.

C: Correct. This directly satisfies the requirement to select an appropriate ExpressRoute SKU and tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.2: Select an appropriate ExpressRoute SKU and tier.

D: Not selected. This directly satisfies the requirement to interpret virtual network flow logs. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.7, but it does not directly satisfy the scenario requirement mapped to 2.3.1, 2.3.2, 2.3.3.

E: Correct. This directly satisfies the requirement to select an ExpressRoute connectivity model. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.1: Select an ExpressRoute connectivity model.

F: Correct. This directly satisfies the requirement to design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.3: Design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery.

Learning point: AZ700-23-Q230: Select the ExpressRoute connectivity model that matches the provider and physical topology: cloud exchange colocation, point-to-point Ethernet, any-to-any IPVPN, or ExpressRoute Direct. | Choose the ExpressRoute SKU and bandwidth/tier that meet geographic reach, route-scale, FastPath/Direct requirements, and expected throughput without paying for unsupported features. | Use redundant ExpressRoute circuits/peerings and appropriately resilient gateways, with cross-region or disaster-recovery routing designed so a single circuit, provider edge, or region does not become a single point of failure.

Question 231

Northwind Health is reviewing a migration wave that must coexist with legacy routing for six months. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must select an appropriate ExpressRoute SKU and tier. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the application delivery team. Change window 4:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7231. Which recommendation most directly meets the requirement? Select one answer.

  1. Choose the ExpressRoute SKU and bandwidth/tier that meet geographic reach, route-scale, FastPath/Direct requirements, and expected throughput without paying for unsupported features.
  2. Attach a Front Door WAF policy with the required managed rule set and tuned custom rules to the relevant Front Door domains/routes, using exclusions only for well-understood false positives.
  3. Use Defender for Cloud attack path analysis to identify exploitable chains that reach high-value assets and remediate the choke points that reduce the greatest real attack exposure.
  4. Configure a custom health probe that targets a reliable application health endpoint with the right host, protocol, path, interval, timeout, and healthy-status criteria.
  5. Enable Front Door caching only for cacheable content, set query-string and compression behavior intentionally, and use cache-control/rules so personalized or sensitive responses are not cached.

Correct answer: A

Why: 2.3.2: This directly satisfies the requirement to select an appropriate ExpressRoute SKU and tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Correct. This directly satisfies the requirement to select an appropriate ExpressRoute SKU and tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.2: Select an appropriate ExpressRoute SKU and tier.

B: Not selected. This directly satisfies the requirement to configure rule sets for WAF on Azure Front Door. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.4, but it does not directly satisfy the scenario requirement mapped to 2.3.2.

C: Not selected. This directly satisfies the requirement to evaluate network security recommendations identified by Microsoft Defender for Cloud attack path analysis. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.4.6, but it does not directly satisfy the scenario requirement mapped to 2.3.2.

D: Not selected. This directly satisfies the requirement to configure health probes. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.5, but it does not directly satisfy the scenario requirement mapped to 2.3.2.

E: Not selected. This directly satisfies the requirement to configure caching. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.3.6, but it does not directly satisfy the scenario requirement mapped to 2.3.2.

Learning point: AZ700-23-Q231: Choose the ExpressRoute SKU and bandwidth/tier that meet geographic reach, route-scale, FastPath/Direct requirements, and expected throughput without paying for unsupported features.

Question 232

City Power & Light is reviewing a hybrid environment linked to two datacenters. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the security engineering lead. Change window 7:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7232. Which recommendation most directly meets the requirement? Select one answer.

  1. Choose Azure NAT Gateway when private-subnet workloads need scalable, predictable outbound SNAT and do not require unsolicited inbound connectivity.
  2. Use redundant ExpressRoute circuits/peerings and appropriately resilient gateways, with cross-region or disaster-recovery routing designed so a single circuit, provider edge, or region does not become a single point of failure.
  3. Apply a service endpoint policy to restrict supported service-endpoint traffic from the subnet to explicitly allowed Azure service resources instead of permitting every resource for that service.
  4. Create the VNet with the approved regional address space, define required subnets, and apply governance before attaching workloads.
  5. Select Firewall Basic, Standard, or Premium based on throughput and required features such as TLS inspection, IDPS, URL filtering, and advanced threat protection, not solely on cost.

Correct answer: B

Why: 2.3.3: This directly satisfies the requirement to design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to identify appropriate use cases for Azure NAT Gateway. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.9, but it does not directly satisfy the scenario requirement mapped to 2.3.3.

B: Correct. This directly satisfies the requirement to design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.3: Design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery.

C: Not selected. This directly satisfies the requirement to configure service endpoint policies. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.2.3, but it does not directly satisfy the scenario requirement mapped to 2.3.3.

D: Not selected. This directly satisfies the requirement to create a virtual network (VNet). The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.2, but it does not directly satisfy the scenario requirement mapped to 2.3.3.

E: Not selected. This directly satisfies the requirement to select an appropriate Azure Firewall SKU. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.2.2, but it does not directly satisfy the scenario requirement mapped to 2.3.3.

Learning point: AZ700-23-Q232: Use redundant ExpressRoute circuits/peerings and appropriately resilient gateways, with cross-region or disaster-recovery routing designed so a single circuit, provider edge, or region does not become a single point of failure.

Question 233

Northwind Health is reviewing a shared-services topology used by several application teams. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the cloud architecture board. Change window 10:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7233. Which recommendation most directly meets the requirement? Select one answer.

  1. Apply a service endpoint policy to restrict supported service-endpoint traffic from the subnet to explicitly allowed Azure service resources instead of permitting every resource for that service.
  2. Configure rule collection groups and network, application, or DNAT rules with least privilege, explicit priorities, and FQDN/service-tag use where appropriate, then validate logs for unintended denies.
  3. Use Global Reach for private site-to-site connectivity through Microsoft, FastPath to bypass the gateway data path where supported, and ExpressRoute Direct when dedicated Microsoft peering ports and very high bandwidth are required.
  4. Enable the required service endpoint on the client subnet and then configure the target PaaS resource network rules to permit that subnet.
  5. Create an ASG to represent an application role so NSG rules can reference logical workload groups instead of maintaining IP-address lists.

Correct answer: C

Why: 2.3.4: This directly satisfies the requirement to design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to configure service endpoint policies. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.2.3, but it does not directly satisfy the scenario requirement mapped to 2.3.4.

B: Not selected. This directly satisfies the requirement to configure Azure Firewall rules. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.2.5, but it does not directly satisfy the scenario requirement mapped to 2.3.4.

C: Correct. This directly satisfies the requirement to design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.4: Design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct.

D: Not selected. This directly satisfies the requirement to create service endpoints. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.2.2, but it does not directly satisfy the scenario requirement mapped to 2.3.4.

E: Not selected. This directly satisfies the requirement to create an application security group (ASG). The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.3, but it does not directly satisfy the scenario requirement mapped to 2.3.4.

Learning point: AZ700-23-Q233: Use Global Reach for private site-to-site connectivity through Microsoft, FastPath to bypass the gateway data path where supported, and ExpressRoute Direct when dedicated Microsoft peering ports and very high bandwidth are required.

Question 234

City Power & Light is reviewing a migration wave that must coexist with legacy routing for six months. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must choose between Azure private peering only, Microsoft peering only, or both. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the hybrid connectivity team. Change window 13:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7234. Which recommendation most directly meets the requirement? Select one answer.

  1. Use Application Gateway rewrite rule sets to modify supported request or response headers and URLs under explicit conditions instead of changing application code for simple gateway-layer transformations.
  2. Choose Azure-provided DNS, Azure Private DNS, or custom DNS based on the namespace and hybrid requirements, and ensure private names resolve to private addresses from every required VNet.
  3. Delegate the target subnet to the required Azure platform service and ensure the subnet meets that service’s delegation and coexistence constraints.
  4. Use Azure private peering for private VNet routes, Microsoft peering for supported Microsoft public services, or both when the requirements explicitly need both routing domains.
  5. Configure the load-balancing rule with the correct frontend, backend pool, protocol, ports, health probe, session persistence, and floating-IP settings for the workload.

Correct answer: D

Why: 2.3.5: This directly satisfies the requirement to choose between Azure private peering only, Microsoft peering only, or both. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to configure rewrite rule sets. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.10, but it does not directly satisfy the scenario requirement mapped to 2.3.5.

B: Not selected. This directly satisfies the requirement to design name resolution inside a VNet. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.2.1, but it does not directly satisfy the scenario requirement mapped to 2.3.5.

C: Not selected. This directly satisfies the requirement to plan and configure subnet delegation. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.4, but it does not directly satisfy the scenario requirement mapped to 2.3.5.

D: Correct. This directly satisfies the requirement to choose between Azure private peering only, Microsoft peering only, or both. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.5: Choose between Azure private peering only, Microsoft peering only, or both.

E: Not selected. This directly satisfies the requirement to implement a load balancing rule. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.9, but it does not directly satisfy the scenario requirement mapped to 2.3.5.

Learning point: AZ700-23-Q234: Use Azure private peering for private VNet routes, Microsoft peering for supported Microsoft public services, or both when the requirements explicitly need both routing domains.

Question 235

Northwind Health is reviewing a hybrid environment linked to two datacenters. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must configure Azure private peering; configure Microsoft peering. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the application delivery team. Change window 16:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7235. Which TWO recommendations should be implemented together? Select TWO answers.

  1. Configure Microsoft peering with validated public prefixes, BGP, route filters for the required service communities, and provider-side VLAN/IP settings that match the circuit.
  2. Use Network Watcher IP flow verify with the VM, NIC, direction, protocol, addresses, and ports to identify the effective allow/deny decision and the specific NSG rule responsible.
  3. Configure Azure private peering with the provider using unique VLAN and /30 addressing plus BGP ASNs, then verify advertised private prefixes before attaching VNets.
  4. Use nonoverlapping CIDR ranges, segment workloads by trust and function, reserve capacity for growth, and validate peering and hybrid address-space conflicts before deployment.
  5. Create a Public IP Prefix in the target region so deployments can consume a contiguous set of Azure public IP addresses from a reserved prefix.
  6. Add the relevant VM NIC IP configuration to the ASG so NSG rules that reference the ASG apply to that workload role.

Correct answers: A, C

Why: 2.3.6: This directly satisfies the requirement to configure Azure private peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.7: This directly satisfies the requirement to configure Microsoft peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Correct. This directly satisfies the requirement to configure Microsoft peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.7: Configure Microsoft peering.

B: Not selected. This directly satisfies the requirement to verify IP flow. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.8, but it does not directly satisfy the scenario requirement mapped to 2.3.6, 2.3.7.

C: Correct. This directly satisfies the requirement to configure Azure private peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.6: Configure Azure private peering.

D: Not selected. This directly satisfies the requirement to plan and implement network segmentation and address spaces. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.1, but it does not directly satisfy the scenario requirement mapped to 2.3.6, 2.3.7.

E: Not selected. This directly satisfies the requirement to create a Public IP Prefix. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.6, but it does not directly satisfy the scenario requirement mapped to 2.3.6, 2.3.7.

F: Not selected. This directly satisfies the requirement to associate an ASG to a network interface. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.4, but it does not directly satisfy the scenario requirement mapped to 2.3.6, 2.3.7.

Learning point: AZ700-23-Q235: Configure Azure private peering with the provider using unique VLAN and /30 addressing plus BGP ASNs, then verify advertised private prefixes before attaching VNets. | Configure Microsoft peering with validated public prefixes, BGP, route filters for the required service communities, and provider-side VLAN/IP settings that match the circuit.

Question 236

City Power & Light is reviewing a shared-services topology used by several application teams. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must configure Microsoft peering. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the security engineering lead. Change window 19:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7236. Which recommendation most directly meets the requirement? Select one answer.

  1. Use a hub-and-spoke design with peering options such as forwarded traffic and gateway transit so spokes can consume shared gateways or NVAs without creating unsupported transitive peering assumptions.
  2. Choose Application Gateway when the application needs regional Layer 7 routing, TLS offload, cookie affinity, redirects/rewrites, or WAF close to Azure backends.
  3. Use autoscale for variable or unpredictable traffic and configure sensible minimum/maximum capacity; use fixed/manual capacity only when load is stable and explicitly controlled.
  4. Use Azure Firewall Manager to create hierarchical Firewall Policies with shared base policy and child policies so multiple firewalls receive centrally governed rules without duplicating configuration.
  5. Configure Microsoft peering with validated public prefixes, BGP, route filters for the required service communities, and provider-side VLAN/IP settings that match the circuit.

Correct answer: E

Why: 2.3.7: This directly satisfies the requirement to configure Microsoft peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to design service chaining, including gateway transit. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.1, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

B: Not selected. This directly satisfies the requirement to identify appropriate use cases for Azure Application Gateway. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.2, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

C: Not selected. This directly satisfies the requirement to choose between manual and autoscale. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.3, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

D: Not selected. This directly satisfies the requirement to create and implement Azure Firewall Manager policies. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.2.6, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

E: Correct. This directly satisfies the requirement to configure Microsoft peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.7: Configure Microsoft peering.

Learning point: AZ700-23-Q236: Configure Microsoft peering with validated public prefixes, BGP, route filters for the required service communities, and provider-side VLAN/IP settings that match the circuit.

Question 237

Northwind Health is reviewing a migration wave that must coexist with legacy routing for six months. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must create and configure an ExpressRoute gateway. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the cloud architecture board. Change window 22:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7237. Which recommendation most directly meets the requirement? Select one answer.

  1. Create the ExpressRoute virtual network gateway in GatewaySubnet with the SKU and resiliency model required for the circuit bandwidth and feature set.
  2. Analyze flow-log tuples and traffic analytics to determine source/destination, ports, direction, allow/deny result, and traffic volume before changing NSG policy.
  3. Associate the WAF policy to the correct Front Door security policy or Application Gateway scope and verify that requests traverse the protected listener/domain where the policy is enforced.
  4. Use Azure Private DNS zones for internal namespaces and private-endpoint records, planning VNet links so only the required networks can resolve those names.
  5. Use Cloud Security Explorer to query the cloud security graph for network resources and relationships, then pivot from the results into the relevant posture or exposure investigation.

Correct answer: A

Why: 2.3.8: This directly satisfies the requirement to create and configure an ExpressRoute gateway. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Correct. This directly satisfies the requirement to create and configure an ExpressRoute gateway. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.8: Create and configure an ExpressRoute gateway.

B: Not selected. This directly satisfies the requirement to interpret virtual network flow logs. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.7, but it does not directly satisfy the scenario requirement mapped to 2.3.8.

C: Not selected. This directly satisfies the requirement to associate a WAF policy. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.7, but it does not directly satisfy the scenario requirement mapped to 2.3.8.

D: Not selected. This directly satisfies the requirement to design private DNS zones. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.2.4, but it does not directly satisfy the scenario requirement mapped to 2.3.8.

E: Not selected. This directly satisfies the requirement to identify network resources by using Cloud Security Explorer in Microsoft Defender for Cloud. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.4.7, but it does not directly satisfy the scenario requirement mapped to 2.3.8.

Learning point: AZ700-23-Q237: Create the ExpressRoute virtual network gateway in GatewaySubnet with the SKU and resiliency model required for the circuit bandwidth and feature set.

Question 238

City Power & Light is reviewing a hybrid environment linked to two datacenters. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must connect a virtual network to an ExpressRoute circuit. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the hybrid connectivity team. Change window 2:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7238. Which recommendation most directly meets the requirement? Select one answer.

  1. Attach a Front Door WAF policy with the required managed rule set and tuned custom rules to the relevant Front Door domains/routes, using exclusions only for well-understood false positives.
  2. Create the VNet-to-ExpressRoute connection between the ExpressRoute gateway and the provisioned circuit, then validate learned and advertised routes.
  3. Use inbound NAT rules when specific frontend ports must map to individual backend instances for management or specialized per-instance access rather than load-balanced service traffic.
  4. Terminate or re-encrypt TLS on Application Gateway using certificates from the approved source, enforce the required TLS policy, and validate end-to-end certificate trust when HTTPS continues to the backend.
  5. Choose Application Gateway when the application needs regional Layer 7 routing, TLS offload, cookie affinity, redirects/rewrites, or WAF close to Azure backends.

Correct answer: B

Why: 2.3.9: This directly satisfies the requirement to connect a virtual network to an ExpressRoute circuit. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to configure rule sets for WAF on Azure Front Door. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.4, but it does not directly satisfy the scenario requirement mapped to 2.3.9.

B: Correct. This directly satisfies the requirement to connect a virtual network to an ExpressRoute circuit. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.9: Connect a virtual network to an ExpressRoute circuit.

C: Not selected. This directly satisfies the requirement to create and configure inbound NAT rules. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.10, but it does not directly satisfy the scenario requirement mapped to 2.3.9.

D: Not selected. This directly satisfies the requirement to configure Transport Layer Security (TLS). The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.9, but it does not directly satisfy the scenario requirement mapped to 2.3.9.

E: Not selected. This directly satisfies the requirement to identify appropriate use cases for Azure Application Gateway. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.2, but it does not directly satisfy the scenario requirement mapped to 2.3.9.

Learning point: AZ700-23-Q238: Create the VNet-to-ExpressRoute connection between the ExpressRoute gateway and the provisioned circuit, then validate learned and advertised routes.

Question 239

Northwind Health is reviewing a shared-services topology used by several application teams. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must recommend a route advertisement configuration; configure encryption over ExpressRoute; implement Bidirectional Forwarding Detection. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the application delivery team. Change window 5:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7239. Which THREE recommendations should be implemented together? Select THREE answers.

  1. Choose Azure NAT Gateway when private-subnet workloads need scalable, predictable outbound SNAT and do not require unsolicited inbound connectivity.
  2. Use supported IPsec over Microsoft peering or MACsec on ExpressRoute Direct, depending on the encryption boundary and circuit type, instead of assuming private peering is inherently encrypted.
  3. Use Azure Load Balancer for high-performance Layer 4 TCP/UDP distribution with health probes and frontend/backend rules, not for URL-path or host-header routing.
  4. Advertise only the intended, nonoverlapping prefixes through BGP, summarize where safe, and use route filters or communities on Microsoft peering rather than leaking unrelated routes.
  5. Use Network Watcher tools such as Connection troubleshoot, IP flow verify, next hop, packet capture, and Connection Monitor to isolate connectivity failures before changing security or routing.
  6. Enable BFD on supported ExpressRoute peering to detect path failures faster than standard BGP timers and accelerate convergence.

Correct answers: B, D, F

Why: 2.3.10: This directly satisfies the requirement to recommend a route advertisement configuration. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.11: This directly satisfies the requirement to configure encryption over ExpressRoute. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.12: This directly satisfies the requirement to implement Bidirectional Forwarding Detection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to identify appropriate use cases for Azure NAT Gateway. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.9, but it does not directly satisfy the scenario requirement mapped to 2.3.10, 2.3.11, 2.3.12.

B: Correct. This directly satisfies the requirement to configure encryption over ExpressRoute. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.11: Configure encryption over ExpressRoute.

C: Not selected. This directly satisfies the requirement to map requirements to features and capabilities of Azure Load Balancer. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.1, but it does not directly satisfy the scenario requirement mapped to 2.3.10, 2.3.11, 2.3.12.

D: Correct. This directly satisfies the requirement to recommend a route advertisement configuration. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.10: Recommend a route advertisement configuration.

E: Not selected. This directly satisfies the requirement to monitor and troubleshoot network health by using Azure Network Watcher. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.4.2, but it does not directly satisfy the scenario requirement mapped to 2.3.10, 2.3.11, 2.3.12.

F: Correct. This directly satisfies the requirement to implement Bidirectional Forwarding Detection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.12: Implement Bidirectional Forwarding Detection.

Learning point: AZ700-23-Q239: Advertise only the intended, nonoverlapping prefixes through BGP, summarize where safe, and use route filters or communities on Microsoft peering rather than leaking unrelated routes. | Use supported IPsec over Microsoft peering or MACsec on ExpressRoute Direct, depending on the encryption boundary and circuit type, instead of assuming private peering is inherently encrypted. | Enable BFD on supported ExpressRoute peering to detect path failures faster than standard BGP timers and accelerate convergence.

Question 240

City Power & Light is reviewing a migration wave that must coexist with legacy routing for six months. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must configure encryption over ExpressRoute; implement Bidirectional Forwarding Detection. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the security engineering lead. Change window 8:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7240. Which TWO recommendations should be implemented together? Select TWO answers.

  1. Enable the required service endpoint on the client subnet and then configure the target PaaS resource network rules to permit that subnet.
  2. Use supported IPsec over Microsoft peering or MACsec on ExpressRoute Direct, depending on the encryption boundary and circuit type, instead of assuming private peering is inherently encrypted.
  3. Create a Standard public IP address with the required allocation, zone, and routing preference settings, then protect and monitor the resource as part of the workload design.
  4. Use Microsoft Defender for Cloud Secure Score recommendations to prioritize network hardening items by exposure, impact, and remediation value instead of treating every finding equally.
  5. Enable BFD on supported ExpressRoute peering to detect path failures faster than standard BGP timers and accelerate convergence.
  6. Use a public frontend when clients arrive from the internet and an internal frontend when the service should be reachable only through private networking.

Correct answers: B, E

Why: 2.3.11: This directly satisfies the requirement to configure encryption over ExpressRoute. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.12: This directly satisfies the requirement to implement Bidirectional Forwarding Detection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to create service endpoints. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.2.2, but it does not directly satisfy the scenario requirement mapped to 2.3.11, 2.3.12.

B: Correct. This directly satisfies the requirement to configure encryption over ExpressRoute. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.11: Configure encryption over ExpressRoute.

C: Not selected. This directly satisfies the requirement to create a public IP address. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.9, but it does not directly satisfy the scenario requirement mapped to 2.3.11, 2.3.12.

D: Not selected. This directly satisfies the requirement to evaluate network security recommendations identified by Microsoft Defender for Cloud Secure Score. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.4.5, but it does not directly satisfy the scenario requirement mapped to 2.3.11, 2.3.12.

E: Correct. This directly satisfies the requirement to implement Bidirectional Forwarding Detection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.12: Implement Bidirectional Forwarding Detection.

F: Not selected. This directly satisfies the requirement to choose between public and internal load balancers. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.4, but it does not directly satisfy the scenario requirement mapped to 2.3.11, 2.3.12.

Learning point: AZ700-23-Q240: Use supported IPsec over Microsoft peering or MACsec on ExpressRoute Direct, depending on the encryption boundary and circuit type, instead of assuming private peering is inherently encrypted. | Enable BFD on supported ExpressRoute peering to detect path failures faster than standard BGP timers and accelerate convergence.

Question 241

Northwind Health is reviewing a hybrid environment linked to two datacenters. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must implement Bidirectional Forwarding Detection. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the cloud architecture board. Change window 11:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7241. Which recommendation most directly meets the requirement? Select one answer.

  1. Create the Front Door profile, endpoint, origin group, origins, health probes, and routes so host/path matching and origin priorities implement the required global traffic flow.
  2. Choose Azure Front Door when users need a global HTTP(S) entry point with edge acceleration and resilient multi-region routing rather than a region-bound Layer 7 gateway.
  3. Enable BFD on supported ExpressRoute peering to detect path failures faster than standard BGP timers and accelerate convergence.
  4. Choose Azure Load Balancer when the requirement is regional or cross-region Layer 4 load distribution for TCP/UDP services and application-layer inspection is unnecessary.
  5. Add the relevant VM NIC IP configuration to the ASG so NSG rules that reference the ASG apply to that workload role.

Correct answer: C

Why: 2.3.12: This directly satisfies the requirement to implement Bidirectional Forwarding Detection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to configure an Azure Front Door, including routing, origins, and endpoints. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.3.4, but it does not directly satisfy the scenario requirement mapped to 2.3.12.

B: Not selected. This directly satisfies the requirement to identify appropriate use cases for Azure Front Door. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.3.2, but it does not directly satisfy the scenario requirement mapped to 2.3.12.

C: Correct. This directly satisfies the requirement to implement Bidirectional Forwarding Detection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.12: Implement Bidirectional Forwarding Detection.

D: Not selected. This directly satisfies the requirement to identify appropriate use cases for Azure Load Balancer. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.2, but it does not directly satisfy the scenario requirement mapped to 2.3.12.

E: Not selected. This directly satisfies the requirement to associate an ASG to a network interface. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.4, but it does not directly satisfy the scenario requirement mapped to 2.3.12.

Learning point: AZ700-23-Q241: Enable BFD on supported ExpressRoute peering to detect path failures faster than standard BGP timers and accelerate convergence.

Question 242

City Power & Light is reviewing a shared-services topology used by several application teams. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must diagnose and resolve ExpressRoute connection issues. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the hybrid connectivity team. Change window 14:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7242. Which recommendation most directly meets the requirement? Select one answer.

  1. Publish the producer service through a Private Link Service behind a Standard internal Load Balancer, configure NAT IPs and visibility/approval, and onboard consumer private endpoints.
  2. Enable virtual network flow logs for the required scope and send the records to the approved storage or analytics destination with retention that supports operations and investigations.
  3. Create a virtual network link from the Private DNS zone to the required VNet and enable auto-registration only when that VNet should register VM host records.
  4. Check circuit/provider provisioning, peering/BGP state, gateway health, route advertisements, FastPath eligibility, and effective routes to isolate the failing ExpressRoute segment.
  5. Create a Standard public IP address with the required allocation, zone, and routing preference settings, then protect and monitor the resource as part of the workload design.

Correct answer: D

Why: 2.3.13: This directly satisfies the requirement to diagnose and resolve ExpressRoute connection issues. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to create a Private Link service. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.1.4, but it does not directly satisfy the scenario requirement mapped to 2.3.13.

B: Not selected. This directly satisfies the requirement to implement virtual network flow logs. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.6, but it does not directly satisfy the scenario requirement mapped to 2.3.13.

C: Not selected. This directly satisfies the requirement to link a private DNS zone to a VNet. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.2.6, but it does not directly satisfy the scenario requirement mapped to 2.3.13.

D: Correct. This directly satisfies the requirement to diagnose and resolve ExpressRoute connection issues. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.13: Diagnose and resolve ExpressRoute connection issues.

E: Not selected. This directly satisfies the requirement to create a public IP address. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.9, but it does not directly satisfy the scenario requirement mapped to 2.3.13.

Learning point: AZ700-23-Q242: Check circuit/provider provisioning, peering/BGP state, gateway health, route advertisements, FastPath eligibility, and effective routes to isolate the failing ExpressRoute segment.

Question 243

Northwind Health is reviewing a migration wave that must coexist with legacy routing for six months. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must select an ExpressRoute connectivity model; select an appropriate ExpressRoute SKU and tier. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the application delivery team. Change window 17:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7243. Which TWO recommendations should be implemented together? Select TWO answers.

  1. Start or validate in Detection mode to observe matches and tune exclusions, then move to Prevention mode when the policy is ready to block malicious requests without unacceptable false positives.
  2. Create a private endpoint in the selected subnet for the specific service subresource, approve the connection where required, and validate the assigned private IP.
  3. Select the ExpressRoute connectivity model that matches the provider and physical topology: cloud exchange colocation, point-to-point Ethernet, any-to-any IPVPN, or ExpressRoute Direct.
  4. Create the NSG with a clear workload scope and policy ownership, then add only the required rules instead of duplicating default platform rules.
  5. Choose the ExpressRoute SKU and bandwidth/tier that meet geographic reach, route-scale, FastPath/Direct requirements, and expected throughput without paying for unsupported features.
  6. Attach a Front Door WAF policy with the required managed rule set and tuned custom rules to the relevant Front Door domains/routes, using exclusions only for well-understood false positives.

Correct answers: C, E

Why: 2.3.1: This directly satisfies the requirement to select an ExpressRoute connectivity model. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.2: This directly satisfies the requirement to select an appropriate ExpressRoute SKU and tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to configure detection or prevention mode. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.3, but it does not directly satisfy the scenario requirement mapped to 2.3.1, 2.3.2.

B: Not selected. This directly satisfies the requirement to create private endpoints. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.1.2, but it does not directly satisfy the scenario requirement mapped to 2.3.1, 2.3.2.

C: Correct. This directly satisfies the requirement to select an ExpressRoute connectivity model. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.1: Select an ExpressRoute connectivity model.

D: Not selected. This directly satisfies the requirement to create a network security group (NSG). The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.1, but it does not directly satisfy the scenario requirement mapped to 2.3.1, 2.3.2.

E: Correct. This directly satisfies the requirement to select an appropriate ExpressRoute SKU and tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.2: Select an appropriate ExpressRoute SKU and tier.

F: Not selected. This directly satisfies the requirement to configure rule sets for WAF on Azure Front Door. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.4, but it does not directly satisfy the scenario requirement mapped to 2.3.1, 2.3.2.

Learning point: AZ700-23-Q243: Select the ExpressRoute connectivity model that matches the provider and physical topology: cloud exchange colocation, point-to-point Ethernet, any-to-any IPVPN, or ExpressRoute Direct. | Choose the ExpressRoute SKU and bandwidth/tier that meet geographic reach, route-scale, FastPath/Direct requirements, and expected throughput without paying for unsupported features.

Question 244

City Power & Light is reviewing a hybrid environment linked to two datacenters. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must select an appropriate ExpressRoute SKU and tier. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the security engineering lead. Change window 20:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7244. Which recommendation most directly meets the requirement? Select one answer.

  1. Configure the VNet to use the intended Azure-provided or custom DNS servers and ensure clients renew their DHCP configuration so the new resolver settings take effect.
  2. Associate the WAF policy to the correct Front Door security policy or Application Gateway scope and verify that requests traverse the protected listener/domain where the policy is enforced.
  3. Place WAF on the Application Gateway or Front Door entry point that sees the protected HTTP(S) traffic, choose the appropriate policy scope, and plan exclusions and logging before enforcing blocks.
  4. Configure a custom health probe that targets a reliable application health endpoint with the right host, protocol, path, interval, timeout, and healthy-status criteria.
  5. Choose the ExpressRoute SKU and bandwidth/tier that meet geographic reach, route-scale, FastPath/Direct requirements, and expected throughput without paying for unsupported features.

Correct answer: E

Why: 2.3.2: This directly satisfies the requirement to select an appropriate ExpressRoute SKU and tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to configure DNS settings for a VNet. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.2.2, but it does not directly satisfy the scenario requirement mapped to 2.3.2.

B: Not selected. This directly satisfies the requirement to associate a WAF policy. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.7, but it does not directly satisfy the scenario requirement mapped to 2.3.2.

C: Not selected. This directly satisfies the requirement to design a WAF deployment. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.2, but it does not directly satisfy the scenario requirement mapped to 2.3.2.

D: Not selected. This directly satisfies the requirement to configure health probes. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.5, but it does not directly satisfy the scenario requirement mapped to 2.3.2.

E: Correct. This directly satisfies the requirement to select an appropriate ExpressRoute SKU and tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.2: Select an appropriate ExpressRoute SKU and tier.

Learning point: AZ700-23-Q244: Choose the ExpressRoute SKU and bandwidth/tier that meet geographic reach, route-scale, FastPath/Direct requirements, and expected throughput without paying for unsupported features.

Question 245

Northwind Health is reviewing a shared-services topology used by several application teams. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the cloud architecture board. Change window 23:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7245. Which recommendation most directly meets the requirement? Select one answer.

  1. Use redundant ExpressRoute circuits/peerings and appropriately resilient gateways, with cross-region or disaster-recovery routing designed so a single circuit, provider edge, or region does not become a single point of failure.
  2. Advertise or configure a default route toward the required NVA, VPN, or ExpressRoute path and verify return routing so internet-bound traffic is forced through the inspection point without asymmetry.
  3. Plan private endpoints per service and region, including subnet capacity, DNS zone integration, approval workflow, network policies, and the effect on existing public access.
  4. Associate the route table with the intended subnet so its UDRs participate in effective routing for resources in that subnet.
  5. Configure backend HTTP settings for protocol, port, host-name handling, cookie affinity, timeout, connection draining, and trusted backend certificates as required.

Correct answer: A

Why: 2.3.3: This directly satisfies the requirement to design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Correct. This directly satisfies the requirement to design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.3: Design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery.

B: Not selected. This directly satisfies the requirement to configure forced tunneling. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.6, but it does not directly satisfy the scenario requirement mapped to 2.3.3.

C: Not selected. This directly satisfies the requirement to plan private endpoints. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.1.1, but it does not directly satisfy the scenario requirement mapped to 2.3.3.

D: Not selected. This directly satisfies the requirement to associate a route table with a subnet. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.5, but it does not directly satisfy the scenario requirement mapped to 2.3.3.

E: Not selected. This directly satisfies the requirement to configure HTTP settings. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.8, but it does not directly satisfy the scenario requirement mapped to 2.3.3.

Learning point: AZ700-23-Q245: Use redundant ExpressRoute circuits/peerings and appropriately resilient gateways, with cross-region or disaster-recovery routing designed so a single circuit, provider edge, or region does not become a single point of failure.

Question 246

City Power & Light is reviewing a migration wave that must coexist with legacy routing for six months. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the hybrid connectivity team. Change window 3:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7246. Which recommendation most directly meets the requirement? Select one answer.

  1. Configure the VNet to use the intended Azure-provided or custom DNS servers and ensure clients renew their DHCP configuration so the new resolver settings take effect.
  2. Use Global Reach for private site-to-site connectivity through Microsoft, FastPath to bypass the gateway data path where supported, and ExpressRoute Direct when dedicated Microsoft peering ports and very high bandwidth are required.
  3. Use Network Watcher IP flow verify with the VM, NIC, direction, protocol, addresses, and ports to identify the effective allow/deny decision and the specific NSG rule responsible.
  4. Apply a service endpoint policy to restrict supported service-endpoint traffic from the subnet to explicitly allowed Azure service resources instead of permitting every resource for that service.
  5. Advertise or configure a default route toward the required NVA, VPN, or ExpressRoute path and verify return routing so internet-bound traffic is forced through the inspection point without asymmetry.

Correct answer: B

Why: 2.3.4: This directly satisfies the requirement to design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to configure DNS settings for a VNet. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.2.2, but it does not directly satisfy the scenario requirement mapped to 2.3.4.

B: Correct. This directly satisfies the requirement to design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.4: Design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct.

C: Not selected. This directly satisfies the requirement to verify IP flow. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.8, but it does not directly satisfy the scenario requirement mapped to 2.3.4.

D: Not selected. This directly satisfies the requirement to configure service endpoint policies. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.2.3, but it does not directly satisfy the scenario requirement mapped to 2.3.4.

E: Not selected. This directly satisfies the requirement to configure forced tunneling. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.6, but it does not directly satisfy the scenario requirement mapped to 2.3.4.

Learning point: AZ700-23-Q246: Use Global Reach for private site-to-site connectivity through Microsoft, FastPath to bypass the gateway data path where supported, and ExpressRoute Direct when dedicated Microsoft peering ports and very high bandwidth are required.

Question 247

Northwind Health is reviewing a hybrid environment linked to two datacenters. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must choose between Azure private peering only, Microsoft peering only, or both; configure Azure private peering. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the application delivery team. Change window 6:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7247. Which TWO recommendations should be implemented together? Select TWO answers.

  1. Associate the WAF policy to the correct Front Door security policy or Application Gateway scope and verify that requests traverse the protected listener/domain where the policy is enforced.
  2. Create a route table with UDRs for the required prefixes and next-hop types, avoid routes that cause loops or asymmetric paths, and validate the resulting effective routes.
  3. Use Azure private peering for private VNet routes, Microsoft peering for supported Microsoft public services, or both when the requirements explicitly need both routing domains.
  4. Protect the required VNets and public IP workloads with Azure DDoS Network Protection, configure monitoring and alerts, and integrate DDoS telemetry into incident response.
  5. Configure Azure private peering with the provider using unique VLAN and /30 addressing plus BGP ASNs, then verify advertised private prefixes before attaching VNets.
  6. Host the public authoritative zone in Azure DNS, delegate the domain from the registrar with the Azure DNS name servers, and manage public record sets there.

Correct answers: C, E

Why: 2.3.5: This directly satisfies the requirement to choose between Azure private peering only, Microsoft peering only, or both. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.6: This directly satisfies the requirement to configure Azure private peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to associate a WAF policy. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.7, but it does not directly satisfy the scenario requirement mapped to 2.3.5, 2.3.6.

B: Not selected. This directly satisfies the requirement to design and implement user-defined routes (UDRs). The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.4, but it does not directly satisfy the scenario requirement mapped to 2.3.5, 2.3.6.

C: Correct. This directly satisfies the requirement to choose between Azure private peering only, Microsoft peering only, or both. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.5: Choose between Azure private peering only, Microsoft peering only, or both.

D: Not selected. This directly satisfies the requirement to activate and monitor distributed denial-of-service (DDoS) protection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.4.4, but it does not directly satisfy the scenario requirement mapped to 2.3.5, 2.3.6.

E: Correct. This directly satisfies the requirement to configure Azure private peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.6: Configure Azure private peering.

F: Not selected. This directly satisfies the requirement to design public DNS zones. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.2.3, but it does not directly satisfy the scenario requirement mapped to 2.3.5, 2.3.6.

Learning point: AZ700-23-Q247: Use Azure private peering for private VNet routes, Microsoft peering for supported Microsoft public services, or both when the requirements explicitly need both routing domains. | Configure Azure private peering with the provider using unique VLAN and /30 addressing plus BGP ASNs, then verify advertised private prefixes before attaching VNets.

Question 248

City Power & Light is reviewing a shared-services topology used by several application teams. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must configure Azure private peering; configure Microsoft peering; create and configure an ExpressRoute gateway. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the security engineering lead. Change window 9:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7248. Which THREE recommendations should be implemented together? Select THREE answers.

  1. Use WAF to protect HTTP(S) applications against common application-layer attacks with managed and custom rules; do not treat it as a replacement for NSGs or a general network firewall.
  2. Analyze flow-log tuples and traffic analytics to determine source/destination, ports, direction, allow/deny result, and traffic volume before changing NSG policy.
  3. Configure Microsoft peering with validated public prefixes, BGP, route filters for the required service communities, and provider-side VLAN/IP settings that match the circuit.
  4. Create the ExpressRoute virtual network gateway in GatewaySubnet with the SKU and resiliency model required for the circuit bandwidth and feature set.
  5. Configure Azure private peering with the provider using unique VLAN and /30 addressing plus BGP ASNs, then verify advertised private prefixes before attaching VNets.
  6. Start or validate in Detection mode to observe matches and tune exclusions, then move to Prevention mode when the policy is ready to block malicious requests without unacceptable false positives.

Correct answers: C, D, E

Why: 2.3.6: This directly satisfies the requirement to configure Azure private peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.7: This directly satisfies the requirement to configure Microsoft peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.8: This directly satisfies the requirement to create and configure an ExpressRoute gateway. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to map requirements to features and capabilities of WAF. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.1, but it does not directly satisfy the scenario requirement mapped to 2.3.6, 2.3.7, 2.3.8.

B: Not selected. This directly satisfies the requirement to interpret virtual network flow logs. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.7, but it does not directly satisfy the scenario requirement mapped to 2.3.6, 2.3.7, 2.3.8.

C: Correct. This directly satisfies the requirement to configure Microsoft peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.7: Configure Microsoft peering.

D: Correct. This directly satisfies the requirement to create and configure an ExpressRoute gateway. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.8: Create and configure an ExpressRoute gateway.

E: Correct. This directly satisfies the requirement to configure Azure private peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.6: Configure Azure private peering.

F: Not selected. This directly satisfies the requirement to configure detection or prevention mode. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.3, but it does not directly satisfy the scenario requirement mapped to 2.3.6, 2.3.7, 2.3.8.

Learning point: AZ700-23-Q248: Configure Azure private peering with the provider using unique VLAN and /30 addressing plus BGP ASNs, then verify advertised private prefixes before attaching VNets. | Configure Microsoft peering with validated public prefixes, BGP, route filters for the required service communities, and provider-side VLAN/IP settings that match the circuit. | Create the ExpressRoute virtual network gateway in GatewaySubnet with the SKU and resiliency model required for the circuit bandwidth and feature set.

Question 249

Northwind Health is reviewing a migration wave that must coexist with legacy routing for six months. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must configure Microsoft peering. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the cloud architecture board. Change window 12:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7249. Which recommendation most directly meets the requirement? Select one answer.

  1. Use the Microsoft-recommended private DNS zone for the service, link it to consuming VNets, and ensure hybrid DNS forwards the private namespace so the public FQDN resolves to the private endpoint address for authorized clients.
  2. Place WAF on the Application Gateway or Front Door entry point that sees the protected HTTP(S) traffic, choose the appropriate policy scope, and plan exclusions and logging before enforcing blocks.
  3. Configure Microsoft peering with validated public prefixes, BGP, route filters for the required service communities, and provider-side VLAN/IP settings that match the circuit.
  4. Deploy Azure DNS Private Resolver with inbound and outbound endpoints and a forwarding ruleset so hybrid DNS queries can traverse between Azure private zones and on-premises DNS without custom DNS VMs.
  5. Use Azure Private DNS zones for internal namespaces and private-endpoint records, planning VNet links so only the required networks can resolve those names.

Correct answer: C

Why: 2.3.7: This directly satisfies the requirement to configure Microsoft peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to integrate Private Link and Private Endpoint with DNS. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.1.5, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

B: Not selected. This directly satisfies the requirement to design a WAF deployment. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.2, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

C: Correct. This directly satisfies the requirement to configure Microsoft peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.7: Configure Microsoft peering.

D: Not selected. This directly satisfies the requirement to design and implement Azure DNS Private Resolver. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.2.7, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

E: Not selected. This directly satisfies the requirement to design private DNS zones. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.2.4, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

Learning point: AZ700-23-Q249: Configure Microsoft peering with validated public prefixes, BGP, route filters for the required service communities, and provider-side VLAN/IP settings that match the circuit.

Question 250

City Power & Light is reviewing a hybrid environment linked to two datacenters. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must create and configure an ExpressRoute gateway. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the hybrid connectivity team. Change window 15:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7250. Which recommendation most directly meets the requirement? Select one answer.

  1. Use a Public IP Prefix when you need predictable contiguous Azure public addresses for scaling, partner allowlisting, or simplified public-IP lifecycle management.
  2. Use Defender for Cloud attack path analysis to identify exploitable chains that reach high-value assets and remediate the choke points that reduce the greatest real attack exposure.
  3. Associate the public IP to the supported frontend resource that actually needs internet reachability, such as a load balancer frontend, gateway, firewall, or NIC, instead of assigning public IPs broadly.
  4. Create the ExpressRoute virtual network gateway in GatewaySubnet with the SKU and resiliency model required for the circuit bandwidth and feature set.
  5. Use Azure Virtual Network Manager security admin configurations for centrally enforced baseline rules across network groups, while leaving NSGs for workload-specific controls.

Correct answer: D

Why: 2.3.8: This directly satisfies the requirement to create and configure an ExpressRoute gateway. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to choose when to use a public IP address prefix. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.7, but it does not directly satisfy the scenario requirement mapped to 2.3.8.

B: Not selected. This directly satisfies the requirement to evaluate network security recommendations identified by Microsoft Defender for Cloud attack path analysis. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.4.6, but it does not directly satisfy the scenario requirement mapped to 2.3.8.

C: Not selected. This directly satisfies the requirement to associate public IP addresses to resources. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.10, but it does not directly satisfy the scenario requirement mapped to 2.3.8.

D: Correct. This directly satisfies the requirement to create and configure an ExpressRoute gateway. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.8: Create and configure an ExpressRoute gateway.

E: Not selected. This directly satisfies the requirement to implement and manage virtual network security by using Azure Virtual Network Manager. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.10, but it does not directly satisfy the scenario requirement mapped to 2.3.8.

Learning point: AZ700-23-Q250: Create the ExpressRoute virtual network gateway in GatewaySubnet with the SKU and resiliency model required for the circuit bandwidth and feature set.

Question 251

Northwind Health is reviewing a shared-services topology used by several application teams. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must connect a virtual network to an ExpressRoute circuit; recommend a route advertisement configuration. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the application delivery team. Change window 18:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7251. Which TWO recommendations should be implemented together? Select TWO answers.

  1. Enable the required service endpoint on the client subnet and then configure the target PaaS resource network rules to permit that subnet.
  2. Advertise only the intended, nonoverlapping prefixes through BGP, summarize where safe, and use route filters or communities on Microsoft peering rather than leaking unrelated routes.
  3. Create the VNet-to-ExpressRoute connection between the ExpressRoute gateway and the provisioned circuit, then validate learned and advertised routes.
  4. Terminate or re-encrypt TLS on Application Gateway using certificates from the approved source, enforce the required TLS policy, and validate end-to-end certificate trust when HTTPS continues to the backend.
  5. Choose Azure Front Door when users need a global HTTP(S) entry point with edge acceleration and resilient multi-region routing rather than a region-bound Layer 7 gateway.
  6. Use Azure Traffic Manager for DNS-based global traffic distribution when endpoints can be public and the design needs priority, performance, weighted, geographic, or subnet routing.

Correct answers: B, C

Why: 2.3.9: This directly satisfies the requirement to connect a virtual network to an ExpressRoute circuit. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.10: This directly satisfies the requirement to recommend a route advertisement configuration. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to create service endpoints. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.2.2, but it does not directly satisfy the scenario requirement mapped to 2.3.9, 2.3.10.

B: Correct. This directly satisfies the requirement to recommend a route advertisement configuration. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.10: Recommend a route advertisement configuration.

C: Correct. This directly satisfies the requirement to connect a virtual network to an ExpressRoute circuit. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.9: Connect a virtual network to an ExpressRoute circuit.

D: Not selected. This directly satisfies the requirement to configure Transport Layer Security (TLS). The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.9, but it does not directly satisfy the scenario requirement mapped to 2.3.9, 2.3.10.

E: Not selected. This directly satisfies the requirement to identify appropriate use cases for Azure Front Door. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.3.2, but it does not directly satisfy the scenario requirement mapped to 2.3.9, 2.3.10.

F: Not selected. This directly satisfies the requirement to implement Azure Traffic Manager. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.7, but it does not directly satisfy the scenario requirement mapped to 2.3.9, 2.3.10.

Learning point: AZ700-23-Q251: Create the VNet-to-ExpressRoute connection between the ExpressRoute gateway and the provisioned circuit, then validate learned and advertised routes. | Advertise only the intended, nonoverlapping prefixes through BGP, summarize where safe, and use route filters or communities on Microsoft peering rather than leaking unrelated routes.

Question 252

City Power & Light is reviewing a migration wave that must coexist with legacy routing for six months. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must recommend a route advertisement configuration; configure encryption over ExpressRoute; implement Bidirectional Forwarding Detection. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the security engineering lead. Change window 21:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7252. Which THREE recommendations should be implemented together? Select THREE answers.

  1. Enable BFD on supported ExpressRoute peering to detect path failures faster than standard BGP timers and accelerate convergence.
  2. Use supported IPsec over Microsoft peering or MACsec on ExpressRoute Direct, depending on the encryption boundary and circuit type, instead of assuming private peering is inherently encrypted.
  3. Advertise only the intended, nonoverlapping prefixes through BGP, summarize where safe, and use route filters or communities on Microsoft peering rather than leaking unrelated routes.
  4. Use a hub-and-spoke design with peering options such as forwarded traffic and gateway transit so spokes can consume shared gateways or NVAs without creating unsupported transitive peering assumptions.
  5. Inspect effective routes and next-hop results in Network Watcher, then verify peering, BGP advertisements, UDR precedence, and return paths before changing the design.
  6. Use WAF to protect HTTP(S) applications against common application-layer attacks with managed and custom rules; do not treat it as a replacement for NSGs or a general network firewall.

Correct answers: A, B, C

Why: 2.3.10: This directly satisfies the requirement to recommend a route advertisement configuration. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.11: This directly satisfies the requirement to configure encryption over ExpressRoute. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.12: This directly satisfies the requirement to implement Bidirectional Forwarding Detection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Correct. This directly satisfies the requirement to implement Bidirectional Forwarding Detection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.12: Implement Bidirectional Forwarding Detection.

B: Correct. This directly satisfies the requirement to configure encryption over ExpressRoute. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.11: Configure encryption over ExpressRoute.

C: Correct. This directly satisfies the requirement to recommend a route advertisement configuration. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.10: Recommend a route advertisement configuration.

D: Not selected. This directly satisfies the requirement to design service chaining, including gateway transit. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.1, but it does not directly satisfy the scenario requirement mapped to 2.3.10, 2.3.11, 2.3.12.

E: Not selected. This directly satisfies the requirement to diagnose and resolve routing issues. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.7, but it does not directly satisfy the scenario requirement mapped to 2.3.10, 2.3.11, 2.3.12.

F: Not selected. This directly satisfies the requirement to map requirements to features and capabilities of WAF. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.1, but it does not directly satisfy the scenario requirement mapped to 2.3.10, 2.3.11, 2.3.12.

Learning point: AZ700-23-Q252: Advertise only the intended, nonoverlapping prefixes through BGP, summarize where safe, and use route filters or communities on Microsoft peering rather than leaking unrelated routes. | Use supported IPsec over Microsoft peering or MACsec on ExpressRoute Direct, depending on the encryption boundary and circuit type, instead of assuming private peering is inherently encrypted. | Enable BFD on supported ExpressRoute peering to detect path failures faster than standard BGP timers and accelerate convergence.

Question 253

Northwind Health is reviewing a hybrid environment linked to two datacenters. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must configure encryption over ExpressRoute; implement Bidirectional Forwarding Detection; diagnose and resolve ExpressRoute connection issues. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the cloud architecture board. Change window 1:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7253. Which THREE recommendations should be implemented together? Select THREE answers.

  1. Check circuit/provider provisioning, peering/BGP state, gateway health, route advertisements, FastPath eligibility, and effective routes to isolate the failing ExpressRoute segment.
  2. Enable BFD on supported ExpressRoute peering to detect path failures faster than standard BGP timers and accelerate convergence.
  3. Create an ASG to represent an application role so NSG rules can reference logical workload groups instead of maintaining IP-address lists.
  4. Associate the NSG at the subnet for consistent workload policy, at the NIC for justified host-specific policy, or at both only when the combined effective rules are intentionally understood.
  5. Use supported IPsec over Microsoft peering or MACsec on ExpressRoute Direct, depending on the encryption boundary and circuit type, instead of assuming private peering is inherently encrypted.
  6. Add the relevant VM NIC IP configuration to the ASG so NSG rules that reference the ASG apply to that workload role.

Correct answers: A, B, E

Why: 2.3.11: This directly satisfies the requirement to configure encryption over ExpressRoute. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.12: This directly satisfies the requirement to implement Bidirectional Forwarding Detection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.13: This directly satisfies the requirement to diagnose and resolve ExpressRoute connection issues. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Correct. This directly satisfies the requirement to diagnose and resolve ExpressRoute connection issues. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.13: Diagnose and resolve ExpressRoute connection issues.

B: Correct. This directly satisfies the requirement to implement Bidirectional Forwarding Detection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.12: Implement Bidirectional Forwarding Detection.

C: Not selected. This directly satisfies the requirement to create an application security group (ASG). The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.3, but it does not directly satisfy the scenario requirement mapped to 2.3.11, 2.3.12, 2.3.13.

D: Not selected. This directly satisfies the requirement to associate a NSG to a subnet or network interface. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.2, but it does not directly satisfy the scenario requirement mapped to 2.3.11, 2.3.12, 2.3.13.

E: Correct. This directly satisfies the requirement to configure encryption over ExpressRoute. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.11: Configure encryption over ExpressRoute.

F: Not selected. This directly satisfies the requirement to associate an ASG to a network interface. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.4, but it does not directly satisfy the scenario requirement mapped to 2.3.11, 2.3.12, 2.3.13.

Learning point: AZ700-23-Q253: Use supported IPsec over Microsoft peering or MACsec on ExpressRoute Direct, depending on the encryption boundary and circuit type, instead of assuming private peering is inherently encrypted. | Enable BFD on supported ExpressRoute peering to detect path failures faster than standard BGP timers and accelerate convergence. | Check circuit/provider provisioning, peering/BGP state, gateway health, route advertisements, FastPath eligibility, and effective routes to isolate the failing ExpressRoute segment.

Question 254

City Power & Light is reviewing a shared-services topology used by several application teams. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must implement Bidirectional Forwarding Detection. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the hybrid connectivity team. Change window 4:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7254. Which recommendation most directly meets the requirement? Select one answer.

  1. Configure explicit outbound rules or, preferably where appropriate, a NAT Gateway so SNAT capacity and outbound public addresses are deterministic rather than relying on implicit behavior.
  2. Select the supported Standard SKU/tier and regional or global design based on zone resiliency, scale, cross-region requirements, and backend resource compatibility.
  3. Use a hub-and-spoke design with peering options such as forwarded traffic and gateway transit so spokes can consume shared gateways or NVAs without creating unsupported transitive peering assumptions.
  4. Use dedicated subnets when a service requires delegation, special routing, or isolation; share only where supported and where policy and scale requirements are compatible.
  5. Enable BFD on supported ExpressRoute peering to detect path failures faster than standard BGP timers and accelerate convergence.

Correct answer: E

Why: 2.3.12: This directly satisfies the requirement to implement Bidirectional Forwarding Detection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to create and configure explicit outbound rules, including source network address translation (SNAT). The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.11, but it does not directly satisfy the scenario requirement mapped to 2.3.12.

B: Not selected. This directly satisfies the requirement to choose an Azure Load Balancer SKU and tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.3, but it does not directly satisfy the scenario requirement mapped to 2.3.12.

C: Not selected. This directly satisfies the requirement to design service chaining, including gateway transit. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.1, but it does not directly satisfy the scenario requirement mapped to 2.3.12.

D: Not selected. This directly satisfies the requirement to plan and configure shared or dedicated subnets. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.5, but it does not directly satisfy the scenario requirement mapped to 2.3.12.

E: Correct. This directly satisfies the requirement to implement Bidirectional Forwarding Detection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.12: Implement Bidirectional Forwarding Detection.

Learning point: AZ700-23-Q254: Enable BFD on supported ExpressRoute peering to detect path failures faster than standard BGP timers and accelerate convergence.

Question 255

Northwind Health is reviewing a migration wave that must coexist with legacy routing for six months. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must diagnose and resolve ExpressRoute connection issues. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the application delivery team. Change window 7:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7255. Which recommendation most directly meets the requirement? Select one answer.

  1. Check circuit/provider provisioning, peering/BGP state, gateway health, route advertisements, FastPath eligibility, and effective routes to isolate the failing ExpressRoute segment.
  2. Apply a service endpoint policy to restrict supported service-endpoint traffic from the subnet to explicitly allowed Azure service resources instead of permitting every resource for that service.
  3. Attach a Front Door WAF policy with the required managed rule set and tuned custom rules to the relevant Front Door domains/routes, using exclusions only for well-understood false positives.
  4. Use a hub-and-spoke design with peering options such as forwarded traffic and gateway transit so spokes can consume shared gateways or NVAs without creating unsupported transitive peering assumptions.
  5. Create the NSG with a clear workload scope and policy ownership, then add only the required rules instead of duplicating default platform rules.

Correct answer: A

Why: 2.3.13: This directly satisfies the requirement to diagnose and resolve ExpressRoute connection issues. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Correct. This directly satisfies the requirement to diagnose and resolve ExpressRoute connection issues. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.13: Diagnose and resolve ExpressRoute connection issues.

B: Not selected. This directly satisfies the requirement to configure service endpoint policies. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.2.3, but it does not directly satisfy the scenario requirement mapped to 2.3.13.

C: Not selected. This directly satisfies the requirement to configure rule sets for WAF on Azure Front Door. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.4, but it does not directly satisfy the scenario requirement mapped to 2.3.13.

D: Not selected. This directly satisfies the requirement to design service chaining, including gateway transit. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.1, but it does not directly satisfy the scenario requirement mapped to 2.3.13.

E: Not selected. This directly satisfies the requirement to create a network security group (NSG). The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.1, but it does not directly satisfy the scenario requirement mapped to 2.3.13.

Learning point: AZ700-23-Q255: Check circuit/provider provisioning, peering/BGP state, gateway health, route advertisements, FastPath eligibility, and effective routes to isolate the failing ExpressRoute segment.

Question 256

City Power & Light is reviewing a hybrid environment linked to two datacenters. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must select an ExpressRoute connectivity model. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the security engineering lead. Change window 10:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7256. Which recommendation most directly meets the requirement? Select one answer.

  1. Enable Front Door caching only for cacheable content, set query-string and compression behavior intentionally, and use cache-control/rules so personalized or sensitive responses are not cached.
  2. Select the ExpressRoute connectivity model that matches the provider and physical topology: cloud exchange colocation, point-to-point Ethernet, any-to-any IPVPN, or ExpressRoute Direct.
  3. Use a regional load balancer for backends in one Azure region and a cross-region load balancer when a global Layer 4 entry point must distribute to regional load balancers.
  4. Create a Standard public IP address with the required allocation, zone, and routing preference settings, then protect and monitor the resource as part of the workload design.
  5. Deploy Azure DNS Private Resolver with inbound and outbound endpoints and a forwarding ruleset so hybrid DNS queries can traverse between Azure private zones and on-premises DNS without custom DNS VMs.

Correct answer: B

Why: 2.3.1: This directly satisfies the requirement to select an ExpressRoute connectivity model. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to configure caching. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.3.6, but it does not directly satisfy the scenario requirement mapped to 2.3.1.

B: Correct. This directly satisfies the requirement to select an ExpressRoute connectivity model. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.1: Select an ExpressRoute connectivity model.

C: Not selected. This directly satisfies the requirement to choose between regional and cross-region load balancers. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.5, but it does not directly satisfy the scenario requirement mapped to 2.3.1.

D: Not selected. This directly satisfies the requirement to create a public IP address. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.9, but it does not directly satisfy the scenario requirement mapped to 2.3.1.

E: Not selected. This directly satisfies the requirement to design and implement Azure DNS Private Resolver. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.2.7, but it does not directly satisfy the scenario requirement mapped to 2.3.1.

Learning point: AZ700-23-Q256: Select the ExpressRoute connectivity model that matches the provider and physical topology: cloud exchange colocation, point-to-point Ethernet, any-to-any IPVPN, or ExpressRoute Direct.

Question 257

Northwind Health is reviewing a shared-services topology used by several application teams. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must select an appropriate ExpressRoute SKU and tier; design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the cloud architecture board. Change window 13:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7257. Which TWO recommendations should be implemented together? Select TWO answers.

  1. Choose the ExpressRoute SKU and bandwidth/tier that meet geographic reach, route-scale, FastPath/Direct requirements, and expected throughput without paying for unsupported features.
  2. Create a Public IP Prefix in the target region so deployments can consume a contiguous set of Azure public IP addresses from a reserved prefix.
  3. Associate the route table with the intended subnet so its UDRs participate in effective routing for resources in that subnet.
  4. Create a backend pool containing the intended IPs, FQDNs, VMSS, or supported targets, keeping host-name and DNS behavior consistent with backend HTTP settings.
  5. Publish the producer service through a Private Link Service behind a Standard internal Load Balancer, configure NAT IPs and visibility/approval, and onboard consumer private endpoints.
  6. Use redundant ExpressRoute circuits/peerings and appropriately resilient gateways, with cross-region or disaster-recovery routing designed so a single circuit, provider edge, or region does not become a single point of failure.

Correct answers: A, F

Why: 2.3.2: This directly satisfies the requirement to select an appropriate ExpressRoute SKU and tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.3: This directly satisfies the requirement to design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Correct. This directly satisfies the requirement to select an appropriate ExpressRoute SKU and tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.2: Select an appropriate ExpressRoute SKU and tier.

B: Not selected. This directly satisfies the requirement to create a Public IP Prefix. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.6, but it does not directly satisfy the scenario requirement mapped to 2.3.2, 2.3.3.

C: Not selected. This directly satisfies the requirement to associate a route table with a subnet. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.5, but it does not directly satisfy the scenario requirement mapped to 2.3.2, 2.3.3.

D: Not selected. This directly satisfies the requirement to create a backend pool. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.4, but it does not directly satisfy the scenario requirement mapped to 2.3.2, 2.3.3.

E: Not selected. This directly satisfies the requirement to create a Private Link service. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.1.4, but it does not directly satisfy the scenario requirement mapped to 2.3.2, 2.3.3.

F: Correct. This directly satisfies the requirement to design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.3: Design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery.

Learning point: AZ700-23-Q257: Choose the ExpressRoute SKU and bandwidth/tier that meet geographic reach, route-scale, FastPath/Direct requirements, and expected throughput without paying for unsupported features. | Use redundant ExpressRoute circuits/peerings and appropriately resilient gateways, with cross-region or disaster-recovery routing designed so a single circuit, provider edge, or region does not become a single point of failure.

Question 258

City Power & Light is reviewing a migration wave that must coexist with legacy routing for six months. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery; design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the hybrid connectivity team. Change window 16:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7258. Which TWO recommendations should be implemented together? Select TWO answers.

  1. Use redundant ExpressRoute circuits/peerings and appropriately resilient gateways, with cross-region or disaster-recovery routing designed so a single circuit, provider edge, or region does not become a single point of failure.
  2. Configure rule collection groups and network, application, or DNAT rules with least privilege, explicit priorities, and FQDN/service-tag use where appropriate, then validate logs for unintended denies.
  3. Choose Azure Front Door when users need a global HTTP(S) entry point with edge acceleration and resilient multi-region routing rather than a region-bound Layer 7 gateway.
  4. Apply a service endpoint policy to restrict supported service-endpoint traffic from the subnet to explicitly allowed Azure service resources instead of permitting every resource for that service.
  5. Use Global Reach for private site-to-site connectivity through Microsoft, FastPath to bypass the gateway data path where supported, and ExpressRoute Direct when dedicated Microsoft peering ports and very high bandwidth are required.
  6. Enable the required service endpoint on the client subnet and then configure the target PaaS resource network rules to permit that subnet.

Correct answers: A, E

Why: 2.3.3: This directly satisfies the requirement to design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.4: This directly satisfies the requirement to design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Correct. This directly satisfies the requirement to design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.3: Design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery.

B: Not selected. This directly satisfies the requirement to configure Azure Firewall rules. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.2.5, but it does not directly satisfy the scenario requirement mapped to 2.3.3, 2.3.4.

C: Not selected. This directly satisfies the requirement to identify appropriate use cases for Azure Front Door. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.3.2, but it does not directly satisfy the scenario requirement mapped to 2.3.3, 2.3.4.

D: Not selected. This directly satisfies the requirement to configure service endpoint policies. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.2.3, but it does not directly satisfy the scenario requirement mapped to 2.3.3, 2.3.4.

E: Correct. This directly satisfies the requirement to design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.4: Design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct.

F: Not selected. This directly satisfies the requirement to create service endpoints. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.2.2, but it does not directly satisfy the scenario requirement mapped to 2.3.3, 2.3.4.

Learning point: AZ700-23-Q258: Use redundant ExpressRoute circuits/peerings and appropriately resilient gateways, with cross-region or disaster-recovery routing designed so a single circuit, provider edge, or region does not become a single point of failure. | Use Global Reach for private site-to-site connectivity through Microsoft, FastPath to bypass the gateway data path where supported, and ExpressRoute Direct when dedicated Microsoft peering ports and very high bandwidth are required.

Question 259

Northwind Health is reviewing a hybrid environment linked to two datacenters. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct; choose between Azure private peering only, Microsoft peering only, or both. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the application delivery team. Change window 19:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7259. Which TWO recommendations should be implemented together? Select TWO answers.

  1. Configure the VNet to use the intended Azure-provided or custom DNS servers and ensure clients renew their DHCP configuration so the new resolver settings take effect.
  2. Enable virtual network flow logs for the required scope and send the records to the approved storage or analytics destination with retention that supports operations and investigations.
  3. Use Global Reach for private site-to-site connectivity through Microsoft, FastPath to bypass the gateway data path where supported, and ExpressRoute Direct when dedicated Microsoft peering ports and very high bandwidth are required.
  4. Create the VNet with the approved regional address space, define required subnets, and apply governance before attaching workloads.
  5. Use Azure private peering for private VNet routes, Microsoft peering for supported Microsoft public services, or both when the requirements explicitly need both routing domains.
  6. Associate the route table with the intended subnet so its UDRs participate in effective routing for resources in that subnet.

Correct answers: C, E

Why: 2.3.4: This directly satisfies the requirement to design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.5: This directly satisfies the requirement to choose between Azure private peering only, Microsoft peering only, or both. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to configure DNS settings for a VNet. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.2.2, but it does not directly satisfy the scenario requirement mapped to 2.3.4, 2.3.5.

B: Not selected. This directly satisfies the requirement to implement virtual network flow logs. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.6, but it does not directly satisfy the scenario requirement mapped to 2.3.4, 2.3.5.

C: Correct. This directly satisfies the requirement to design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.4: Design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct.

D: Not selected. This directly satisfies the requirement to create a virtual network (VNet). The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.2, but it does not directly satisfy the scenario requirement mapped to 2.3.4, 2.3.5.

E: Correct. This directly satisfies the requirement to choose between Azure private peering only, Microsoft peering only, or both. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.5: Choose between Azure private peering only, Microsoft peering only, or both.

F: Not selected. This directly satisfies the requirement to associate a route table with a subnet. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.5, but it does not directly satisfy the scenario requirement mapped to 2.3.4, 2.3.5.

Learning point: AZ700-23-Q259: Use Global Reach for private site-to-site connectivity through Microsoft, FastPath to bypass the gateway data path where supported, and ExpressRoute Direct when dedicated Microsoft peering ports and very high bandwidth are required. | Use Azure private peering for private VNet routes, Microsoft peering for supported Microsoft public services, or both when the requirements explicitly need both routing domains.

Question 260

City Power & Light is reviewing a shared-services topology used by several application teams. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must choose between Azure private peering only, Microsoft peering only, or both. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the security engineering lead. Change window 22:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7260. Which recommendation most directly meets the requirement? Select one answer.

  1. Protect the required VNets and public IP workloads with Azure DDoS Network Protection, configure monitoring and alerts, and integrate DDoS telemetry into incident response.
  2. Terminate TLS at the Front Door edge with the managed or customer certificate and use HTTPS to origins with valid certificates when end-to-end encryption is required.
  3. Use Azure private peering for private VNet routes, Microsoft peering for supported Microsoft public services, or both when the requirements explicitly need both routing domains.
  4. Create a WAF policy with the intended managed rules, custom rules, exclusions, mode, and logging configuration so protection is versioned and reusable instead of embedded ad hoc in a gateway.
  5. Apply a service endpoint policy to restrict supported service-endpoint traffic from the subnet to explicitly allowed Azure service resources instead of permitting every resource for that service.

Correct answer: C

Why: 2.3.5: This directly satisfies the requirement to choose between Azure private peering only, Microsoft peering only, or both. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to activate and monitor distributed denial-of-service (DDoS) protection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.4.4, but it does not directly satisfy the scenario requirement mapped to 2.3.5.

B: Not selected. This directly satisfies the requirement to configure TLS termination and end-to-end TLS encryption. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.3.5, but it does not directly satisfy the scenario requirement mapped to 2.3.5.

C: Correct. This directly satisfies the requirement to choose between Azure private peering only, Microsoft peering only, or both. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.5: Choose between Azure private peering only, Microsoft peering only, or both.

D: Not selected. This directly satisfies the requirement to implement a WAF policy. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.6, but it does not directly satisfy the scenario requirement mapped to 2.3.5.

E: Not selected. This directly satisfies the requirement to configure service endpoint policies. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.2.3, but it does not directly satisfy the scenario requirement mapped to 2.3.5.

Learning point: AZ700-23-Q260: Use Azure private peering for private VNet routes, Microsoft peering for supported Microsoft public services, or both when the requirements explicitly need both routing domains.

Question 261

Northwind Health is reviewing a migration wave that must coexist with legacy routing for six months. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must configure Azure private peering. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the cloud architecture board. Change window 2:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7261. Which recommendation most directly meets the requirement? Select one answer.

  1. Analyze flow-log tuples and traffic analytics to determine source/destination, ports, direction, allow/deny result, and traffic volume before changing NSG policy.
  2. Create a Public IP Prefix in the target region so deployments can consume a contiguous set of Azure public IP addresses from a reserved prefix.
  3. Enable the required service endpoint on the client subnet and then configure the target PaaS resource network rules to permit that subnet.
  4. Configure Azure private peering with the provider using unique VLAN and /30 addressing plus BGP ASNs, then verify advertised private prefixes before attaching VNets.
  5. Place WAF on the Application Gateway or Front Door entry point that sees the protected HTTP(S) traffic, choose the appropriate policy scope, and plan exclusions and logging before enforcing blocks.

Correct answer: D

Why: 2.3.6: This directly satisfies the requirement to configure Azure private peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to interpret virtual network flow logs. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.7, but it does not directly satisfy the scenario requirement mapped to 2.3.6.

B: Not selected. This directly satisfies the requirement to create a Public IP Prefix. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.6, but it does not directly satisfy the scenario requirement mapped to 2.3.6.

C: Not selected. This directly satisfies the requirement to create service endpoints. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.2.2, but it does not directly satisfy the scenario requirement mapped to 2.3.6.

D: Correct. This directly satisfies the requirement to configure Azure private peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.6: Configure Azure private peering.

E: Not selected. This directly satisfies the requirement to design a WAF deployment. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.2, but it does not directly satisfy the scenario requirement mapped to 2.3.6.

Learning point: AZ700-23-Q261: Configure Azure private peering with the provider using unique VLAN and /30 addressing plus BGP ASNs, then verify advertised private prefixes before attaching VNets.

Question 262

City Power & Light is reviewing a hybrid environment linked to two datacenters. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must configure Microsoft peering. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the hybrid connectivity team. Change window 5:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7262. Which recommendation most directly meets the requirement? Select one answer.

  1. Use autoscale for variable or unpredictable traffic and configure sensible minimum/maximum capacity; use fixed/manual capacity only when load is stable and explicitly controlled.
  2. Create a route table with UDRs for the required prefixes and next-hop types, avoid routes that cause loops or asymmetric paths, and validate the resulting effective routes.
  3. Associate the WAF policy to the correct Front Door security policy or Application Gateway scope and verify that requests traverse the protected listener/domain where the policy is enforced.
  4. Use a service endpoint when a supported Azure PaaS resource can remain on its public endpoint but must recognize and restrict access to selected VNet subnets; use Private Link when a private IP endpoint is required.
  5. Configure Microsoft peering with validated public prefixes, BGP, route filters for the required service communities, and provider-side VLAN/IP settings that match the circuit.

Correct answer: E

Why: 2.3.7: This directly satisfies the requirement to configure Microsoft peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to choose between manual and autoscale. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.3, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

B: Not selected. This directly satisfies the requirement to design and implement user-defined routes (UDRs). The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.4, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

C: Not selected. This directly satisfies the requirement to associate a WAF policy. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.7, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

D: Not selected. This directly satisfies the requirement to choose when to use a service endpoint. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.2.1, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

E: Correct. This directly satisfies the requirement to configure Microsoft peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.7: Configure Microsoft peering.

Learning point: AZ700-23-Q262: Configure Microsoft peering with validated public prefixes, BGP, route filters for the required service communities, and provider-side VLAN/IP settings that match the circuit.

Question 263

Northwind Health is reviewing a shared-services topology used by several application teams. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must create and configure an ExpressRoute gateway; connect a virtual network to an ExpressRoute circuit. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the application delivery team. Change window 8:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7263. Which TWO recommendations should be implemented together? Select TWO answers.

  1. Use Microsoft Defender for Cloud Secure Score recommendations to prioritize network hardening items by exposure, impact, and remediation value instead of treating every finding equally.
  2. Choose Azure Front Door when users need a global HTTP(S) entry point with edge acceleration and resilient multi-region routing rather than a region-bound Layer 7 gateway.
  3. Create the VNet-to-ExpressRoute connection between the ExpressRoute gateway and the provisioned circuit, then validate learned and advertised routes.
  4. Create a route table with UDRs for the required prefixes and next-hop types, avoid routes that cause loops or asymmetric paths, and validate the resulting effective routes.
  5. Plan private endpoints per service and region, including subnet capacity, DNS zone integration, approval workflow, network policies, and the effect on existing public access.
  6. Create the ExpressRoute virtual network gateway in GatewaySubnet with the SKU and resiliency model required for the circuit bandwidth and feature set.

Correct answers: C, F

Why: 2.3.8: This directly satisfies the requirement to create and configure an ExpressRoute gateway. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.9: This directly satisfies the requirement to connect a virtual network to an ExpressRoute circuit. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to evaluate network security recommendations identified by Microsoft Defender for Cloud Secure Score. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.4.5, but it does not directly satisfy the scenario requirement mapped to 2.3.8, 2.3.9.

B: Not selected. This directly satisfies the requirement to identify appropriate use cases for Azure Front Door. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.3.2, but it does not directly satisfy the scenario requirement mapped to 2.3.8, 2.3.9.

C: Correct. This directly satisfies the requirement to connect a virtual network to an ExpressRoute circuit. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.9: Connect a virtual network to an ExpressRoute circuit.

D: Not selected. This directly satisfies the requirement to design and implement user-defined routes (UDRs). The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.4, but it does not directly satisfy the scenario requirement mapped to 2.3.8, 2.3.9.

E: Not selected. This directly satisfies the requirement to plan private endpoints. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.1.1, but it does not directly satisfy the scenario requirement mapped to 2.3.8, 2.3.9.

F: Correct. This directly satisfies the requirement to create and configure an ExpressRoute gateway. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.8: Create and configure an ExpressRoute gateway.

Learning point: AZ700-23-Q263: Create the ExpressRoute virtual network gateway in GatewaySubnet with the SKU and resiliency model required for the circuit bandwidth and feature set. | Create the VNet-to-ExpressRoute connection between the ExpressRoute gateway and the provisioned circuit, then validate learned and advertised routes.

Question 264

City Power & Light is reviewing a migration wave that must coexist with legacy routing for six months. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must connect a virtual network to an ExpressRoute circuit. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the security engineering lead. Change window 11:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7264. Which recommendation most directly meets the requirement? Select one answer.

  1. Create the VNet-to-ExpressRoute connection between the ExpressRoute gateway and the provisioned circuit, then validate learned and advertised routes.
  2. Host the public authoritative zone in Azure DNS, delegate the domain from the registrar with the Azure DNS name servers, and manage public record sets there.
  3. Use Gateway Load Balancer to insert and scale compatible NVAs transparently in the traffic path through service chaining with a consumer frontend.
  4. Use Network Watcher IP flow verify with the VM, NIC, direction, protocol, addresses, and ports to identify the effective allow/deny decision and the specific NSG rule responsible.
  5. Peer VNets with nonoverlapping address spaces, configure forwarded-traffic and gateway options only as required, and validate effective routes on both sides.

Correct answer: A

Why: 2.3.9: This directly satisfies the requirement to connect a virtual network to an ExpressRoute circuit. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Correct. This directly satisfies the requirement to connect a virtual network to an ExpressRoute circuit. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.9: Connect a virtual network to an ExpressRoute circuit.

B: Not selected. This directly satisfies the requirement to design public DNS zones. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.2.3, but it does not directly satisfy the scenario requirement mapped to 2.3.9.

C: Not selected. This directly satisfies the requirement to implement Gateway Load Balancer. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.8, but it does not directly satisfy the scenario requirement mapped to 2.3.9.

D: Not selected. This directly satisfies the requirement to verify IP flow. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.8, but it does not directly satisfy the scenario requirement mapped to 2.3.9.

E: Not selected. This directly satisfies the requirement to implement VNet peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.2, but it does not directly satisfy the scenario requirement mapped to 2.3.9.

Learning point: AZ700-23-Q264: Create the VNet-to-ExpressRoute connection between the ExpressRoute gateway and the provisioned circuit, then validate learned and advertised routes.

Question 265

Northwind Health is reviewing a hybrid environment linked to two datacenters. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must recommend a route advertisement configuration; configure encryption over ExpressRoute. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the cloud architecture board. Change window 14:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7265. Which TWO recommendations should be implemented together? Select TWO answers.

  1. Peer VNets with nonoverlapping address spaces, configure forwarded-traffic and gateway options only as required, and validate effective routes on both sides.
  2. Use Azure Traffic Manager for DNS-based global traffic distribution when endpoints can be public and the design needs priority, performance, weighted, geographic, or subnet routing.
  3. Use a public frontend when clients arrive from the internet and an internal frontend when the service should be reachable only through private networking.
  4. Advertise only the intended, nonoverlapping prefixes through BGP, summarize where safe, and use route filters or communities on Microsoft peering rather than leaking unrelated routes.
  5. Use supported IPsec over Microsoft peering or MACsec on ExpressRoute Direct, depending on the encryption boundary and circuit type, instead of assuming private peering is inherently encrypted.
  6. Choose Azure Load Balancer when the requirement is regional or cross-region Layer 4 load distribution for TCP/UDP services and application-layer inspection is unnecessary.

Correct answers: D, E

Why: 2.3.10: This directly satisfies the requirement to recommend a route advertisement configuration. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.11: This directly satisfies the requirement to configure encryption over ExpressRoute. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to implement VNet peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.2, but it does not directly satisfy the scenario requirement mapped to 2.3.10, 2.3.11.

B: Not selected. This directly satisfies the requirement to implement Azure Traffic Manager. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.7, but it does not directly satisfy the scenario requirement mapped to 2.3.10, 2.3.11.

C: Not selected. This directly satisfies the requirement to choose between public and internal load balancers. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.4, but it does not directly satisfy the scenario requirement mapped to 2.3.10, 2.3.11.

D: Correct. This directly satisfies the requirement to recommend a route advertisement configuration. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.10: Recommend a route advertisement configuration.

E: Correct. This directly satisfies the requirement to configure encryption over ExpressRoute. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.11: Configure encryption over ExpressRoute.

F: Not selected. This directly satisfies the requirement to identify appropriate use cases for Azure Load Balancer. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.2, but it does not directly satisfy the scenario requirement mapped to 2.3.10, 2.3.11.

Learning point: AZ700-23-Q265: Advertise only the intended, nonoverlapping prefixes through BGP, summarize where safe, and use route filters or communities on Microsoft peering rather than leaking unrelated routes. | Use supported IPsec over Microsoft peering or MACsec on ExpressRoute Direct, depending on the encryption boundary and circuit type, instead of assuming private peering is inherently encrypted.

Question 266

City Power & Light is reviewing a shared-services topology used by several application teams. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must configure encryption over ExpressRoute. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the hybrid connectivity team. Change window 17:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7266. Which recommendation most directly meets the requirement? Select one answer.

  1. Use Network Watcher IP flow verify with the VM, NIC, direction, protocol, addresses, and ports to identify the effective allow/deny decision and the specific NSG rule responsible.
  2. Use supported IPsec over Microsoft peering or MACsec on ExpressRoute Direct, depending on the encryption boundary and circuit type, instead of assuming private peering is inherently encrypted.
  3. Use nonoverlapping CIDR ranges, segment workloads by trust and function, reserve capacity for growth, and validate peering and hybrid address-space conflicts before deployment.
  4. Use autoscale for variable or unpredictable traffic and configure sensible minimum/maximum capacity; use fixed/manual capacity only when load is stable and explicitly controlled.
  5. Create a Standard public IP address with the required allocation, zone, and routing preference settings, then protect and monitor the resource as part of the workload design.

Correct answer: B

Why: 2.3.11: This directly satisfies the requirement to configure encryption over ExpressRoute. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to verify IP flow. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.8, but it does not directly satisfy the scenario requirement mapped to 2.3.11.

B: Correct. This directly satisfies the requirement to configure encryption over ExpressRoute. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.11: Configure encryption over ExpressRoute.

C: Not selected. This directly satisfies the requirement to plan and implement network segmentation and address spaces. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.1, but it does not directly satisfy the scenario requirement mapped to 2.3.11.

D: Not selected. This directly satisfies the requirement to choose between manual and autoscale. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.3, but it does not directly satisfy the scenario requirement mapped to 2.3.11.

E: Not selected. This directly satisfies the requirement to create a public IP address. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.9, but it does not directly satisfy the scenario requirement mapped to 2.3.11.

Learning point: AZ700-23-Q266: Use supported IPsec over Microsoft peering or MACsec on ExpressRoute Direct, depending on the encryption boundary and circuit type, instead of assuming private peering is inherently encrypted.

Question 267

Northwind Health is reviewing a migration wave that must coexist with legacy routing for six months. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must implement Bidirectional Forwarding Detection. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the application delivery team. Change window 20:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7267. Which recommendation most directly meets the requirement? Select one answer.

  1. Terminate or re-encrypt TLS on Application Gateway using certificates from the approved source, enforce the required TLS policy, and validate end-to-end certificate trust when HTTPS continues to the backend.
  2. Implement the Azure networking capability named in the requirement using the supported Microsoft configuration, validate prerequisites and dependencies, and confirm the result with Azure-native diagnostics before production rollout.
  3. Enable BFD on supported ExpressRoute peering to detect path failures faster than standard BGP timers and accelerate convergence.
  4. Use Microsoft Defender for Cloud Secure Score recommendations to prioritize network hardening items by exposure, impact, and remediation value instead of treating every finding equally.
  5. Advertise or configure a default route toward the required NVA, VPN, or ExpressRoute path and verify return routing so internet-bound traffic is forced through the inspection point without asymmetry.

Correct answer: C

Why: 2.3.12: This directly satisfies the requirement to implement Bidirectional Forwarding Detection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to configure Transport Layer Security (TLS). The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.9, but it does not directly satisfy the scenario requirement mapped to 2.3.12.

B: Not selected. This directly satisfies the requirement to choose an appropriate tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.3.3, but it does not directly satisfy the scenario requirement mapped to 2.3.12.

C: Correct. This directly satisfies the requirement to implement Bidirectional Forwarding Detection. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.12: Implement Bidirectional Forwarding Detection.

D: Not selected. This directly satisfies the requirement to evaluate network security recommendations identified by Microsoft Defender for Cloud Secure Score. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.4.5, but it does not directly satisfy the scenario requirement mapped to 2.3.12.

E: Not selected. This directly satisfies the requirement to configure forced tunneling. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.6, but it does not directly satisfy the scenario requirement mapped to 2.3.12.

Learning point: AZ700-23-Q267: Enable BFD on supported ExpressRoute peering to detect path failures faster than standard BGP timers and accelerate convergence.

Question 268

City Power & Light is reviewing a hybrid environment linked to two datacenters. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must diagnose and resolve ExpressRoute connection issues. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the security engineering lead. Change window 23:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7268. Which recommendation most directly meets the requirement? Select one answer.

  1. Select Firewall Basic, Standard, or Premium based on throughput and required features such as TLS inspection, IDPS, URL filtering, and advanced threat protection, not solely on cost.
  2. Use Cloud Security Explorer to query the cloud security graph for network resources and relationships, then pivot from the results into the relevant posture or exposure investigation.
  3. Configure the Application Gateway WAF policy with the required managed OWASP rule set, custom rules, exclusions, and policy settings, then associate it at the intended gateway/listener/path scope.
  4. Check circuit/provider provisioning, peering/BGP state, gateway health, route advertisements, FastPath eligibility, and effective routes to isolate the failing ExpressRoute segment.
  5. Advertise or configure a default route toward the required NVA, VPN, or ExpressRoute path and verify return routing so internet-bound traffic is forced through the inspection point without asymmetry.

Correct answer: D

Why: 2.3.13: This directly satisfies the requirement to diagnose and resolve ExpressRoute connection issues. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to select an appropriate Azure Firewall SKU. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.2.2, but it does not directly satisfy the scenario requirement mapped to 2.3.13.

B: Not selected. This directly satisfies the requirement to identify network resources by using Cloud Security Explorer in Microsoft Defender for Cloud. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.4.7, but it does not directly satisfy the scenario requirement mapped to 2.3.13.

C: Not selected. This directly satisfies the requirement to configure rule sets for WAF on Application Gateway. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.5, but it does not directly satisfy the scenario requirement mapped to 2.3.13.

D: Correct. This directly satisfies the requirement to diagnose and resolve ExpressRoute connection issues. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.13: Diagnose and resolve ExpressRoute connection issues.

E: Not selected. This directly satisfies the requirement to configure forced tunneling. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.6, but it does not directly satisfy the scenario requirement mapped to 2.3.13.

Learning point: AZ700-23-Q268: Check circuit/provider provisioning, peering/BGP state, gateway health, route advertisements, FastPath eligibility, and effective routes to isolate the failing ExpressRoute segment.

Question 269

Northwind Health is reviewing a shared-services topology used by several application teams. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must select an ExpressRoute connectivity model; select an appropriate ExpressRoute SKU and tier. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the cloud architecture board. Change window 3:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7269. Which TWO recommendations should be implemented together? Select TWO answers.

  1. Create a Public IP Prefix in the target region so deployments can consume a contiguous set of Azure public IP addresses from a reserved prefix.
  2. Choose the ExpressRoute SKU and bandwidth/tier that meet geographic reach, route-scale, FastPath/Direct requirements, and expected throughput without paying for unsupported features.
  3. Use a service endpoint when a supported Azure PaaS resource can remain on its public endpoint but must recognize and restrict access to selected VNet subnets; use Private Link when a private IP endpoint is required.
  4. Configure a custom health probe that targets a reliable application health endpoint with the right host, protocol, path, interval, timeout, and healthy-status criteria.
  5. Select the ExpressRoute connectivity model that matches the provider and physical topology: cloud exchange colocation, point-to-point Ethernet, any-to-any IPVPN, or ExpressRoute Direct.
  6. Analyze flow-log tuples and traffic analytics to determine source/destination, ports, direction, allow/deny result, and traffic volume before changing NSG policy.

Correct answers: B, E

Why: 2.3.1: This directly satisfies the requirement to select an ExpressRoute connectivity model. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.2: This directly satisfies the requirement to select an appropriate ExpressRoute SKU and tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to create a Public IP Prefix. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.6, but it does not directly satisfy the scenario requirement mapped to 2.3.1, 2.3.2.

B: Correct. This directly satisfies the requirement to select an appropriate ExpressRoute SKU and tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.2: Select an appropriate ExpressRoute SKU and tier.

C: Not selected. This directly satisfies the requirement to choose when to use a service endpoint. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.2.1, but it does not directly satisfy the scenario requirement mapped to 2.3.1, 2.3.2.

D: Not selected. This directly satisfies the requirement to configure health probes. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.5, but it does not directly satisfy the scenario requirement mapped to 2.3.1, 2.3.2.

E: Correct. This directly satisfies the requirement to select an ExpressRoute connectivity model. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.1: Select an ExpressRoute connectivity model.

F: Not selected. This directly satisfies the requirement to interpret virtual network flow logs. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.7, but it does not directly satisfy the scenario requirement mapped to 2.3.1, 2.3.2.

Learning point: AZ700-23-Q269: Select the ExpressRoute connectivity model that matches the provider and physical topology: cloud exchange colocation, point-to-point Ethernet, any-to-any IPVPN, or ExpressRoute Direct. | Choose the ExpressRoute SKU and bandwidth/tier that meet geographic reach, route-scale, FastPath/Direct requirements, and expected throughput without paying for unsupported features.

Question 270

City Power & Light is reviewing a migration wave that must coexist with legacy routing for six months. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must select an appropriate ExpressRoute SKU and tier. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the hybrid connectivity team. Change window 6:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7270. Which recommendation most directly meets the requirement? Select one answer.

  1. Create a backend pool containing the intended IPs, FQDNs, VMSS, or supported targets, keeping host-name and DNS behavior consistent with backend HTTP settings.
  2. Use Defender for Cloud attack path analysis to identify exploitable chains that reach high-value assets and remediate the choke points that reduce the greatest real attack exposure.
  3. Configure the VNet to use the intended Azure-provided or custom DNS servers and ensure clients renew their DHCP configuration so the new resolver settings take effect.
  4. Create a private endpoint in the selected subnet for the specific service subresource, approve the connection where required, and validate the assigned private IP.
  5. Choose the ExpressRoute SKU and bandwidth/tier that meet geographic reach, route-scale, FastPath/Direct requirements, and expected throughput without paying for unsupported features.

Correct answer: E

Why: 2.3.2: This directly satisfies the requirement to select an appropriate ExpressRoute SKU and tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to create a backend pool. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.4, but it does not directly satisfy the scenario requirement mapped to 2.3.2.

B: Not selected. This directly satisfies the requirement to evaluate network security recommendations identified by Microsoft Defender for Cloud attack path analysis. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.4.6, but it does not directly satisfy the scenario requirement mapped to 2.3.2.

C: Not selected. This directly satisfies the requirement to configure DNS settings for a VNet. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.2.2, but it does not directly satisfy the scenario requirement mapped to 2.3.2.

D: Not selected. This directly satisfies the requirement to create private endpoints. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.1.2, but it does not directly satisfy the scenario requirement mapped to 2.3.2.

E: Correct. This directly satisfies the requirement to select an appropriate ExpressRoute SKU and tier. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.2: Select an appropriate ExpressRoute SKU and tier.

Learning point: AZ700-23-Q270: Choose the ExpressRoute SKU and bandwidth/tier that meet geographic reach, route-scale, FastPath/Direct requirements, and expected throughput without paying for unsupported features.

Question 271

Northwind Health is reviewing a hybrid environment linked to two datacenters. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The network engineer must design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery; design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the application delivery team. Change window 9:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7271. Which TWO recommendations should be implemented together? Select TWO answers.

  1. Choose Azure Load Balancer when the requirement is regional or cross-region Layer 4 load distribution for TCP/UDP services and application-layer inspection is unnecessary.
  2. Use redundant ExpressRoute circuits/peerings and appropriately resilient gateways, with cross-region or disaster-recovery routing designed so a single circuit, provider edge, or region does not become a single point of failure.
  3. Configure backend HTTP settings for protocol, port, host-name handling, cookie affinity, timeout, connection draining, and trusted backend certificates as required.
  4. Analyze flow-log tuples and traffic analytics to determine source/destination, ports, direction, allow/deny result, and traffic volume before changing NSG policy.
  5. Use Global Reach for private site-to-site connectivity through Microsoft, FastPath to bypass the gateway data path where supported, and ExpressRoute Direct when dedicated Microsoft peering ports and very high bandwidth are required.
  6. Select Firewall Basic, Standard, or Premium based on throughput and required features such as TLS inspection, IDPS, URL filtering, and advanced threat protection, not solely on cost.

Correct answers: B, E

Why: 2.3.3: This directly satisfies the requirement to design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.4: This directly satisfies the requirement to design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to identify appropriate use cases for Azure Load Balancer. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.2, but it does not directly satisfy the scenario requirement mapped to 2.3.3, 2.3.4.

B: Correct. This directly satisfies the requirement to design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.3: Design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery.

C: Not selected. This directly satisfies the requirement to configure HTTP settings. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.8, but it does not directly satisfy the scenario requirement mapped to 2.3.3, 2.3.4.

D: Not selected. This directly satisfies the requirement to interpret virtual network flow logs. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.7, but it does not directly satisfy the scenario requirement mapped to 2.3.3, 2.3.4.

E: Correct. This directly satisfies the requirement to design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.4: Design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct.

F: Not selected. This directly satisfies the requirement to select an appropriate Azure Firewall SKU. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.2.2, but it does not directly satisfy the scenario requirement mapped to 2.3.3, 2.3.4.

Learning point: AZ700-23-Q271: Use redundant ExpressRoute circuits/peerings and appropriately resilient gateways, with cross-region or disaster-recovery routing designed so a single circuit, provider edge, or region does not become a single point of failure. | Use Global Reach for private site-to-site connectivity through Microsoft, FastPath to bypass the gateway data path where supported, and ExpressRoute Direct when dedicated Microsoft peering ports and very high bandwidth are required.

Question 272

City Power & Light is reviewing a shared-services topology used by several application teams. Traffic reaches the destination on one path but returns on another, producing intermittent connectivity and inspection bypass. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct; choose between Azure private peering only, Microsoft peering only, or both; configure Azure private peering. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the security engineering lead. Change window 12:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7272. Which THREE recommendations should be implemented together? Select THREE answers.

  1. Use Application Gateway rewrite rule sets to modify supported request or response headers and URLs under explicit conditions instead of changing application code for simple gateway-layer transformations.
  2. Use Global Reach for private site-to-site connectivity through Microsoft, FastPath to bypass the gateway data path where supported, and ExpressRoute Direct when dedicated Microsoft peering ports and very high bandwidth are required.
  3. Configure Azure private peering with the provider using unique VLAN and /30 addressing plus BGP ASNs, then verify advertised private prefixes before attaching VNets.
  4. Associate the public IP to the supported frontend resource that actually needs internet reachability, such as a load balancer frontend, gateway, firewall, or NIC, instead of assigning public IPs broadly.
  5. Use Azure private peering for private VNet routes, Microsoft peering for supported Microsoft public services, or both when the requirements explicitly need both routing domains.
  6. Create the NSG with a clear workload scope and policy ownership, then add only the required rules instead of duplicating default platform rules.

Correct answers: B, C, E

Why: 2.3.4: This directly satisfies the requirement to design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.5: This directly satisfies the requirement to choose between Azure private peering only, Microsoft peering only, or both. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.6: This directly satisfies the requirement to configure Azure private peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to configure rewrite rule sets. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.2.10, but it does not directly satisfy the scenario requirement mapped to 2.3.4, 2.3.5, 2.3.6.

B: Correct. This directly satisfies the requirement to design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.4: Design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct.

C: Correct. This directly satisfies the requirement to configure Azure private peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.6: Configure Azure private peering.

D: Not selected. This directly satisfies the requirement to associate public IP addresses to resources. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.10, but it does not directly satisfy the scenario requirement mapped to 2.3.4, 2.3.5, 2.3.6.

E: Correct. This directly satisfies the requirement to choose between Azure private peering only, Microsoft peering only, or both. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.5: Choose between Azure private peering only, Microsoft peering only, or both.

F: Not selected. This directly satisfies the requirement to create a network security group (NSG). The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.1, but it does not directly satisfy the scenario requirement mapped to 2.3.4, 2.3.5, 2.3.6.

Learning point: AZ700-23-Q272: Use Global Reach for private site-to-site connectivity through Microsoft, FastPath to bypass the gateway data path where supported, and ExpressRoute Direct when dedicated Microsoft peering ports and very high bandwidth are required. | Use Azure private peering for private VNet routes, Microsoft peering for supported Microsoft public services, or both when the requirements explicitly need both routing domains. | Configure Azure private peering with the provider using unique VLAN and /30 addressing plus BGP ASNs, then verify advertised private prefixes before attaching VNets.

Question 273

Northwind Health is reviewing a migration wave that must coexist with legacy routing for six months. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must choose between Azure private peering only, Microsoft peering only, or both; configure Azure private peering. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the cloud architecture board. Change window 15:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7273. Which TWO recommendations should be implemented together? Select TWO answers.

  1. Use Azure private peering for private VNet routes, Microsoft peering for supported Microsoft public services, or both when the requirements explicitly need both routing domains.
  2. Configure Azure private peering with the provider using unique VLAN and /30 addressing plus BGP ASNs, then verify advertised private prefixes before attaching VNets.
  3. Analyze flow-log tuples and traffic analytics to determine source/destination, ports, direction, allow/deny result, and traffic volume before changing NSG policy.
  4. Enable virtual network flow logs for the required scope and send the records to the approved storage or analytics destination with retention that supports operations and investigations.
  5. Create the VNet with the approved regional address space, define required subnets, and apply governance before attaching workloads.
  6. Implement Front Door rules with explicit match conditions and actions for header changes, URL rewrites, or redirects, and verify rule-set ordering to avoid unexpected routing behavior.

Correct answers: A, B

Why: 2.3.5: This directly satisfies the requirement to choose between Azure private peering only, Microsoft peering only, or both. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. 2.3.6: This directly satisfies the requirement to configure Azure private peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Correct. This directly satisfies the requirement to choose between Azure private peering only, Microsoft peering only, or both. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.5: Choose between Azure private peering only, Microsoft peering only, or both.

B: Correct. This directly satisfies the requirement to configure Azure private peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.6: Configure Azure private peering.

C: Not selected. This directly satisfies the requirement to interpret virtual network flow logs. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.7, but it does not directly satisfy the scenario requirement mapped to 2.3.5, 2.3.6.

D: Not selected. This directly satisfies the requirement to implement virtual network flow logs. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.1.6, but it does not directly satisfy the scenario requirement mapped to 2.3.5, 2.3.6.

E: Not selected. This directly satisfies the requirement to create a virtual network (VNet). The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.1.2, but it does not directly satisfy the scenario requirement mapped to 2.3.5, 2.3.6.

F: Not selected. This directly satisfies the requirement to implement rules, URL rewrite, and URL redirect. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.3.8, but it does not directly satisfy the scenario requirement mapped to 2.3.5, 2.3.6.

Learning point: AZ700-23-Q273: Use Azure private peering for private VNet routes, Microsoft peering for supported Microsoft public services, or both when the requirements explicitly need both routing domains. | Configure Azure private peering with the provider using unique VLAN and /30 addressing plus BGP ASNs, then verify advertised private prefixes before attaching VNets.

Question 274

City Power & Light is reviewing a hybrid environment linked to two datacenters. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must configure Azure private peering. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the hybrid connectivity team. Change window 18:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7274. Which recommendation most directly meets the requirement? Select one answer.

  1. Configure Azure private peering with the provider using unique VLAN and /30 addressing plus BGP ASNs, then verify advertised private prefixes before attaching VNets.
  2. Associate the WAF policy to the correct Front Door security policy or Application Gateway scope and verify that requests traverse the protected listener/domain where the policy is enforced.
  3. Use Cloud Security Explorer to query the cloud security graph for network resources and relationships, then pivot from the results into the relevant posture or exposure investigation.
  4. Use a public frontend when clients arrive from the internet and an internal frontend when the service should be reachable only through private networking.
  5. Configure the load-balancing rule with the correct frontend, backend pool, protocol, ports, health probe, session persistence, and floating-IP settings for the workload.

Correct answer: A

Why: 2.3.6: This directly satisfies the requirement to configure Azure private peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Correct. This directly satisfies the requirement to configure Azure private peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.6: Configure Azure private peering.

B: Not selected. This directly satisfies the requirement to associate a WAF policy. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 5.3.7, but it does not directly satisfy the scenario requirement mapped to 2.3.6.

C: Not selected. This directly satisfies the requirement to identify network resources by using Cloud Security Explorer in Microsoft Defender for Cloud. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.4.7, but it does not directly satisfy the scenario requirement mapped to 2.3.6.

D: Not selected. This directly satisfies the requirement to choose between public and internal load balancers. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.4, but it does not directly satisfy the scenario requirement mapped to 2.3.6.

E: Not selected. This directly satisfies the requirement to implement a load balancing rule. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.9, but it does not directly satisfy the scenario requirement mapped to 2.3.6.

Learning point: AZ700-23-Q274: Configure Azure private peering with the provider using unique VLAN and /30 addressing plus BGP ASNs, then verify advertised private prefixes before attaching VNets.

Question 275

Northwind Health is reviewing a shared-services topology used by several application teams. The architecture review found that the current network implementation does not meet a documented availability, security, or operability requirement. The network engineer must configure Microsoft peering. The design must retain troubleshooting evidence for incident review, and the decision will be reviewed by the application delivery team. Change window 21:00 UTC; validation must include evidence from Azure-native diagnostics and ticket NET-7275. Which recommendation most directly meets the requirement? Select one answer.

  1. Use Gateway Load Balancer to insert and scale compatible NVAs transparently in the traffic path through service chaining with a consumer frontend.
  2. Configure Microsoft peering with validated public prefixes, BGP, route filters for the required service communities, and provider-side VLAN/IP settings that match the circuit.
  3. Publish the producer service through a Private Link Service behind a Standard internal Load Balancer, configure NAT IPs and visibility/approval, and onboard consumer private endpoints.
  4. Deploy Azure Route Server in its required dedicated subnet and establish BGP sessions with supported NVAs so dynamic routes are exchanged without maintaining large UDR sets.
  5. Choose Azure-provided DNS, Azure Private DNS, or custom DNS based on the namespace and hybrid requirements, and ensure private names resolve to private addresses from every required VNet.

Correct answer: B

Why: 2.3.7: This directly satisfies the requirement to configure Microsoft peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption.

Option review:

A: Not selected. This directly satisfies the requirement to implement Gateway Load Balancer. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 3.1.8, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

B: Correct. This directly satisfies the requirement to configure Microsoft peering. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. This is mapped to objective 2.3.7: Configure Microsoft peering.

C: Not selected. This directly satisfies the requirement to create a Private Link service. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 4.1.4, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

D: Not selected. This directly satisfies the requirement to design and implement Azure Route Server. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.3.8, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

E: Not selected. This directly satisfies the requirement to design name resolution inside a VNet. The recommended design uses the Azure capability in its supported role, accounts for its key dependencies, and validates the effective network behavior rather than relying on an assumption. That action is relevant to objective 1.2.1, but it does not directly satisfy the scenario requirement mapped to 2.3.7.

Learning point: AZ700-23-Q275: Configure Microsoft peering with validated public prefixes, BGP, route filters for the required service communities, and provider-side VLAN/IP settings that match the circuit.

img