JCF INFRA

AZURE NETWORKING / LAB-002

Application Gateway with two IIS backends

Adapting Bicep to an existing network, selecting a VM size and validating two web servers behind a single entry point.

AZ-700 · M528 September 2026Recovered historical evidence

Documented outcome: Both backends show Healthy with HTTP 200. Subsequent screenshots show responses from BackendVM1 and BackendVM2. No failure test was performed.

01 / Architecture and objective

The M5 lab resumed with ContosoVnet, its subnets and ContosoAppGateway already deployed. The objective was to add two IIS VMs without managing the existing network configuration again.

HTTP client → public frontend → ContosoAppGateway
ContosoVnet
  AGSubnet → Application Gateway → listener / rule → BackendPool
  BackendSubnet
    ├─ BackendVM1 · 10.0.1.4 · IIS :80
    └─ BackendVM2 · 10.0.1.5 · IIS :80

The client used one public Gateway IP. Private VM addresses were registered as backend targets. Diagram addresses belong to the historical lab; they are not current endpoints to test.

02 / Adaptations and decisions

Reference the network with existing

Originals were preserved and main.Juan-existing-network.bicep was created separately. The VNet and BackendSubnet use existing declarations, and NICs reference backendSubnet.id. The corrected file retains two VMs, two NICs and two IIS extensions; it does not declare a new Application Gateway.

Adapt the VM size to available constraints

The corrected parameter file uses Standard_D2s_v7, supported by the template, instead of D2s_v5. History records this choice in response to SKU/quota constraints. It does not establish a universal Free-account quota or current availability of that size.

Validate before deployment

History records compilation, Cloud Shell validation and a What-If with six creates and three ignored resources, without modifications or deletions. An approved incremental deployment was then recorded as successful. These are historical chat results, not new runs during this recovery.

Register backend targets explicitly

After VM creation, BackendPool still had no targets. Addresses 10.0.1.4 and 10.0.1.5 were added. Creating a VM in the VNet does not automatically register it in the pool.

Recovered excerpt from the corrected template

resource vnet 'Microsoft.Network/virtualNetworks@2020-06-01' existing = {
  name: virtualNetworkName
}
resource backendSubnet 'Microsoft.Network/virtualNetworks/subnets@2020-06-01' existing = {
  parent: vnet
  name: subnet2Name
}
// NIC subnet reference:
// id: backendSubnet.id

Illustrative excerpt checked against the local file. It is not a complete deployment template and contains no credentials.

03 / Validation and results

What each check establishes
CheckRecorded resultBoundary
Network referenceexisting VNet and subnetVerified in the local file; no current Azure-state query.
DeploymentSucceeded recorded in chat historyNot a fresh test or evidence that resources are still running.
Backend health2/2 Healthy; HTTP 200; port 80Original E01 screenshot establishes service response at that time.
Application accessBackendVM2 and BackendVM1E02/E03 show both names; not a 50/50 distribution or failover test.

04 / Original evidence

Screenshots supplied during the lab and recovered from local history. With permission, publication copies were cropped to exclude personal details and unrelated interface elements. No evidence was reconstructed or AI-generated. Originals and provenance records are retained. Screenshots keep their original language.

E01 · Two Healthy targets; both received status 200 over HTTP/80. Account header excluded.
E01 · Two Healthy targets; both received status 200 over HTTP/80. Account header excluded.
E02 · Historical BackendVM2 response. The crop retains the body; the original URL is outside the public copy.
E02 · Historical BackendVM2 response. The crop retains the body; the original URL is outside the public copy.
E03 · Historical BackendVM1 response. The shared frontend is documented in originals and chat, not independently shown by this crop.
E03 · Historical BackendVM1 response. The shared frontend is documented in originals and chat, not independently shown by this crop.

05 / Scope and lessons

  • This case used HTTP. HTTPS, certificates and WAF were not configured or validated.
  • IIS was not stopped and VM failure was not simulated: tested failover is not claimed.
  • Two different responses do not establish uniform distribution, zone-failure resilience or synchronized application data/sessions.
  • Resources are historical. No current-state query or redeployment was performed; the user stated that lab resources were cleaned up after exercises.

Practical lesson: Separate existing infrastructure from new resources, review the planned changes, and validate both probes and the user-facing response.

Provenance and references

Recovered from “Corrige el laboratorio M5 de AZ-700” and Juan’s retained M5 files. Guided work with AI assistance. Evidence dated 28 September; recovered and reviewed on 16 October 2026.