Skip to main content

Technical Lab: Configure health probes

Questions​

Question 1 — Multiple Choice​

A network engineer is configuring an Azure Load Balancer at the Standard tier to distribute HTTP traffic among three virtual machines. The backend pool has instances that respond on port 80. He creates a health probe with the following settings:

ParameterValue
ProtocolTCP
Port80
Interval5 seconds
Failure threshold2

After deployment, the engineer notices that one of the VMs is serving HTTP responses with status 503, but the Load Balancer continues to send traffic to it.

What is the most likely cause of this behavior?

A) The TCP protocol does not check the HTTP status code, so the probe considers the VM healthy as long as the TCP connection is established successfully.

B) The failure threshold configured as 2 is insufficient to detect intermittent failures in the HTTP protocol.

C) The 5-second interval is too short for the Load Balancer to update the instance state.

D) Azure Load Balancer Standard does not support health probes on port 80 when the protocol is TCP.

Question 2 — Technical Scenario​

A team configured an Application Gateway v2 with the following custom health probe definition snippet:

{
  "name": "custom-probe",
  "protocol": "Https",
  "host": "app.internal.corp",
  "path": "/health",
  "interval": 30,
  "timeout": 30,
  "unhealthyThreshold": 3,
  "pickHostNameFromBackendHttpSettings": false
}

The backend returns HTTP 200 on the /health route, but the Application Gateway marks all pool members as unhealthy. Certificates and network connectivity have been verified and are correct.

What is the most likely error in the probe configuration?

A) The timeout field cannot equal the interval field; the timeout must be smaller than the interval for the probe cycle to work correctly.

B) The path field must always start with the complete hostname, not just the relative path.

C) The host field is configured with a specific value, but pickHostNameFromBackendHttpSettings is set to false, which may cause incompatibility if the backend requires the correct Host header.

D) The unhealthyThreshold configured as 3 prevents the Application Gateway from marking members as unhealthy before three consecutive failures, generating an invalid intermediate state.

Question 3 — True or False​

Statement: In an Azure Load Balancer Standard, if all backend pool instances are marked as unhealthy by the health probe, the Load Balancer completely stops forwarding traffic and no requests are delivered to the pool.

True or False?

Question 4 — Technical Scenario​

An architect needs to configure health probes for an internal Azure Load Balancer that distributes traffic among instances of a service that does not expose any dedicated HTTP or TCP endpoint for health checking. The application can only be considered healthy if the main process is running, which is verified by a local agent on the VM.

Which approach solves this requirement most appropriately within the native capabilities of Azure Load Balancer health probes?

A) Create an HTTP health probe pointing to the main application port and interpret any response as a health signal, regardless of status code.

B) Create a dedicated HTTP endpoint on the VM, controlled by the local agent, that returns 200 only when the main process is healthy, and configure the probe for this endpoint.

C) Use a TCP health probe on the main process port, as Azure Load Balancer can inspect the process state from the established TCP connection.

D) Configure the health probe with HTTPS protocol pointing to the VM IP, dispensing with any additional endpoint, as the TLS handshake validates the service state.

Question 5 — Multiple Choice​

When comparing Azure Load Balancer health probes with Application Gateway health probes, which statement below correctly describes a behavioral difference between the two services?

A) Azure Load Balancer supports probes with HTTPS protocol, while Application Gateway supports only HTTP and TCP.

B) Application Gateway allows configuring the path field in HTTP/HTTPS probes, while Azure Load Balancer does not offer this level of granularity in path verification.

C) Azure Load Balancer sends probes from a fixed and documented IP, while Application Gateway sends probes from its infrastructure instance IP addresses in the 168.63.129.16 range.

D) Application Gateway ignores the HTTP status code returned by the backend and considers any response as a health indicator, unlike Azure Load Balancer.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: A

Explanation:

  • A TCP probe only checks if a TCP connection can be established on the specified port. It does not interpret HTTP response content or inspect status codes. If port 80 accepts connections, the VM is considered healthy by the Load Balancer, even if the application responds with 503.
  • Alternatives B and C represent misconceptions about tuning parameters: a threshold of 2 and a 5-second interval are valid and functional configurations. Alternative D is incorrect because Azure Load Balancer Standard fully supports TCP on port 80.
  • The practical consequence of choosing TCP when you need to validate the application layer is exactly this scenario: degraded instances continue receiving traffic. To detect 503, the probe must be configured with HTTP protocol, pointing to an appropriate path.

Answer Key — Question 2​

Answer: A

Explanation:

  • In Application Gateway, the timeout field defines how long the probe waits for a response before considering the attempt a failure. When timeout equals interval, the gateway has no time margin to start the next cycle after the previous one ends, generating invalid probe behavior that can result in all members being marked as unhealthy.
  • Alternative C describes a real and valid problem with the Host header, but the statement specifies that certificates and connectivity were verified, shifting the cause to the timeout/interval relationship.
  • Microsoft's documented best practice requires that timeout be strictly smaller than interval. Keeping them equal is a common configuration error that goes unnoticed until the environment is put into production.

Answer Key — Question 3​

Answer: False

Explanation:

  • Azure Load Balancer Standard implements a behavior called "probe down, all up": when all backend pool instances are marked as unhealthy, the Load Balancer resumes forwarding traffic to all of them, treating the pool as if all were healthy.
  • This behavior exists to avoid total service interruption in situations where the probe is misconfigured or the health endpoint failed, but the application can still serve requests.
  • The distinction is important: the behavior described in the statement would apply intuitively, but it's not what the service does. Ignoring this characteristic can lead to incorrect diagnostics during incidents.

Answer Key — Question 4​

Answer: B

Explanation:

  • Azure Load Balancer has no capability to inspect the internal state of operating system processes. It checks TCP connectivity or HTTP/HTTPS responses on a configured port and path. The correct solution is to instrument the VM with an HTTP endpoint controlled by the agent itself, which returns 200 only when the main process is running.
  • Alternative A is partially plausible, but the Load Balancer HTTP probe only considers status codes 200-399 as success. Any response outside this range marks the instance as unhealthy, so the premise of "ignoring the status code" is wrong.
  • Alternative C represents a frequent misconception: successful TCP connection indicates only that the port is listening, not that the underlying process is functional.
  • Alternative D is technically incoherent: the TLS handshake verifies certificate validity, not application state.

Answer Key — Question 5​

Answer: B

Explanation:

  • Application Gateway operates at layer 7 and its health probes support configuring a specific path (like /health or /status), allowing validation of a dedicated endpoint on the backend. Azure Load Balancer, due to its layer 4 nature (with HTTP/HTTPS probe support), does not allow specifying a path in HTTP probes; it only checks if the port responds with a success status code.
  • Alternative A reverses the facts: Azure Load Balancer does not support HTTPS in its probes; Application Gateway does.
  • Alternative C confuses probe origins: the address 168.63.129.16 is the source IP for Azure Load Balancer probes, not Application Gateway.
  • Alternative D is wrong because Application Gateway checks the HTTP status code and considers only responses within configurable ranges as health indicators.