Health checks in Nginx - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Nginx active health check status output

You have configured an active health check in Nginx for your backend servers. Which command output snippet correctly shows that the backend server is healthy?

Nginx

curl -s http://localhost/nginx_status | grep 'upstream server'

A upstream server backend1 is UP

B upstream server backend1 is DOWN

C upstream server backend1 is UNKNOWN

D upstream server backend1 is TIMEOUT

💡 Hint

Look for the status that indicates the server is responding correctly.

The active health check reports the backend server status. 'UP' means the server is healthy and responding.

❓ Configuration

intermediate

Correct Nginx passive health check directive

Which Nginx configuration snippet correctly enables passive health checks for an upstream named app_servers?

A

upstream app_servers {
    server 192.168.1.10;
    server 192.168.1.11;
    health_check;
}

B

upstream app_servers {
    server 192.168.1.10 max_fails=3 fail_timeout=30s;
    server 192.168.1.11 max_fails=3 fail_timeout=30s;
}

C

upstream app_servers {
    server 192.168.1.10;
    server 192.168.1.11;
    passive_check;
}

D

upstream app_servers {
    server 192.168.1.10;
    server 192.168.1.11;
    passive_health_check on;
}

💡 Hint

Passive health checks use max_fails and fail_timeout parameters.

Passive health checks in Nginx are controlled by max_fails and fail_timeout on server directives. The health_check directive enables active checks, not passive.

❓ Troubleshoot

advanced

Diagnosing failed active health checks in Nginx

You configured active health checks in Nginx but all backend servers show as DOWN. Which of the following is the most likely cause?

A The health check URI path is incorrect or returns a non-200 status

B The upstream servers are overloaded but still respond with 200 OK

C The passive health check parameters max_fails and fail_timeout are missing

D The Nginx worker_processes is set to 1

💡 Hint

Active health checks depend on a correct URI and response status.

Active health checks send requests to a specific URI. If the URI is wrong or the server returns an error status, Nginx marks the server as DOWN.

🔀 Workflow

advanced

Order of steps to enable active health checks in Nginx

Arrange the steps in the correct order to enable active health checks for an upstream in Nginx.

A 2,1,4,3

B 4,1,2,3

C 1,2,4,3

D 1,4,2,3

💡 Hint

You must define servers before adding health checks and reload last.

First define servers, then configure health check details, add the directive, and finally reload Nginx.

✅ Best Practice

expert

Best practice for health check intervals in production

What is the best practice for setting the interval of active health checks in a high-traffic production Nginx environment?

A Set a very long interval (5 minutes) to reduce load on backend servers

B Disable active health checks and rely only on passive checks

C Set a moderate interval (10-30 seconds) balancing detection speed and load

D Set a very short interval (1 second) to detect failures immediately

💡 Hint

Consider backend load and failure detection speed.

Too frequent checks increase load; too infrequent delay failure detection. A moderate interval balances both.

Practice

1. What is the main purpose of a health check in an nginx setup?

easy

A. To increase the server's CPU speed

B. To verify if a server is ready to handle requests

C. To change the server's IP address automatically

D. To backup server files regularly

Solution

1. Step 1: Understand health check concept

   Health checks are used to confirm if a server is ready and able to serve requests.

2. Step 2: Identify the purpose in nginx context

   In nginx, health checks help route traffic only to servers that respond correctly, ensuring reliability.

3. Final Answer:

   To verify if a server is ready to handle requests -> Option B

4. Quick Check:

   Health check purpose = Verify readiness [OK]

Hint: Health checks confirm server readiness to serve requests [OK]

Common Mistakes:

• Thinking health checks speed up the server
• Confusing health checks with backups
• Assuming health checks change server IP

2. Which of the following is the correct way to define a simple health check endpoint in nginx configuration?

easy

A. location /healthcheck { return 200 "OK"; }

B. location /healthcheck { proxy_pass http://backend; }

C. location /healthcheck { error_page 404 /404.html; }

D. location /healthcheck { deny all; }

Solution

1. Step 1: Review nginx location syntax for health check

   A simple health check returns a 200 status with a message like 'OK'.

2. Step 2: Identify correct return directive

   location /healthcheck { return 200 "OK"; } uses return 200 "OK"; which correctly sends a success response for health checks.

3. Final Answer:

   location /healthcheck { return 200 "OK"; } -> Option A

4. Quick Check:

   Simple health check = return 200 [OK]

Hint: Health check returns 200 with OK message [OK]

Common Mistakes:

• Using proxy_pass instead of return for simple checks
• Setting error_page instead of success response
• Denying access blocks health check

3. Given this nginx config snippet, what will be the HTTP status code when accessing /health?

location /health {
  return 204;
}

medium

A. 204

B. 404

C. 500

D. 200

Solution

1. Step 1: Understand the return directive in nginx

   The return 204; sends an HTTP status code 204 (No Content) response.

2. Step 2: Match the status code with the request

   Accessing /health triggers this location and returns 204 as configured.

3. Final Answer:

   204 -> Option A

4. Quick Check:

   return 204 sends status 204 [OK]

Hint: return 204 sends HTTP 204 No Content status [OK]

Common Mistakes:

• Assuming default 200 status without checking return
• Confusing 204 with 404 or 500 errors
• Ignoring the explicit return directive

4. You configured this health check in nginx:

location /healthcheck {
  return 200 "OK"
}

But the health check fails with a syntax error. What is the problem?

medium

A. The return directive cannot include a message string

B. The return code 200 is invalid

C. The location block is missing a semicolon after return

D. The location path must be /health, not /healthcheck

Solution

1. Step 1: Check nginx configuration syntax

   All nginx directives must end with a semicolon (;).

2. Step 2: Locate the error in the snippet

   The return 200 "OK" line is missing the trailing semicolon, causing a syntax error.

3. Final Answer:

   The location block is missing a semicolon after return -> Option C

4. Quick Check:

   nginx directives require semicolon [OK]

Hint: Every nginx directive must end with a semicolon [OK]

Common Mistakes:

• Adding message string directly after return
• Missing semicolon causing syntax error
• Using wrong location path for health check

5. You want to configure nginx to perform active health checks on backend servers and mark them unhealthy if they fail. Which directive and module combination should you use?

hard

A. Use proxy_pass with proxy_next_upstream and enable ngx_http_healthcheck_module

B. Use deny all in location to block unhealthy servers

C. Use return 200 in location block for backend health

D. Use check directive inside upstream block with ngx_http_upstream_check_module

Solution

1. Step 1: Identify active health check method in nginx

   Active health checks require special modules like ngx_http_upstream_check_module and directives like check inside upstream blocks.

2. Step 2: Match correct directive and module

   Use check directive inside upstream block with ngx_http_upstream_check_module correctly pairs check directive with ngx_http_upstream_check_module for active health checks.

3. Final Answer:

   Use check directive inside upstream block with ngx_http_upstream_check_module -> Option D

4. Quick Check:

   Active health checks = check + upstream_check_module [OK]

Hint: Active health checks need check directive and module [OK]

Common Mistakes:

• Confusing passive proxy_next_upstream with active health checks
• Using return 200 for backend health checks
• Blocking servers instead of checking health