Skip to main content

Technical Lab: Configure health probes

Questions​

Question 1 — Multiple Choice​

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

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 sending traffic to it.

What is the most likely cause of this behavior?

A) The TCP protocol doesn't check HTTP status codes, so the probe considers the VM healthy as long as the TCP connection is successfully established.

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 status.

D) Azure Load Balancer Standard doesn't 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; timeout must be smaller than 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 instances in the backend pool 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 across instances of a service that doesn't 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 best solves this requirement 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, since 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, since the TLS handshake validates the service state.

Question 5 — Multiple Choice​

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

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

B) Application Gateway allows configuring the path field in HTTP/HTTPS probes, while Azure Load Balancer doesn't 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 doesn't 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: the threshold of 2 and interval of 5 seconds 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 application layer validation is needed 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 as failed. 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 situation 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 timeout to be strictly smaller than interval. Keeping both 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 instances in the backend pool 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 diagnoses during incidents.

Answer Key — Question 4​

Answer: B

Explanation:

  • Azure Load Balancer doesn't have the 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 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 status code" is wrong.
  • Alternative C represents a frequent misconception: successful TCP connection only indicates 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), doesn't 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 HTTP status codes and only considers responses within configurable ranges as health indicators.