Round-robin (default) in Nginx - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the default load balancing method in NGINX?

NGINX uses a load balancing method to distribute client requests across multiple servers. What is the default method used if none is specified?

A Random

B Least connections

C Round-robin

D IP hash

💡 Hint

Think about the simplest way to distribute requests evenly without extra configuration.

The default load balancing method in NGINX is round-robin. It cycles through the servers in order, sending each new request to the next server.

❓ Configuration

intermediate

Identify the correct NGINX upstream block for round-robin load balancing

Which of the following NGINX upstream configurations correctly sets up round-robin load balancing for two backend servers?

A

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
}

B

upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

C

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

D

upstream backend {
    random;
    server backend1.example.com;
    server backend2.example.com;
}

💡 Hint

Round-robin is the default and requires no extra directive inside the upstream block.

In NGINX, round-robin is the default load balancing method. You just list the servers inside the upstream block without any extra keywords.

❓ Troubleshoot

advanced

Why might NGINX not distribute requests evenly in round-robin mode?

You configured NGINX with multiple backend servers using round-robin. However, one server receives significantly more requests than others. What could cause this behavior?

A One backend server is slower and NGINX retries requests on it more often.

B Round-robin requires explicit configuration; without it, NGINX uses least connections.

C NGINX caches DNS and resolves backend IPs only once, causing uneven distribution if IPs change.

D Client connections are kept alive and reused, so requests stick to the same backend server.

💡 Hint

Think about how persistent connections affect request distribution.

NGINX uses persistent connections by default. If clients reuse connections, requests go to the same backend server, causing uneven load despite round-robin.

✅ Best Practice

advanced

What is a recommended practice when using round-robin load balancing in NGINX?

When using round-robin load balancing in NGINX, which practice helps ensure better distribution and reliability?

A Enable health checks to remove unhealthy backend servers automatically.

B Use IP hash to guarantee the same client always hits the same server.

C Disable keepalive connections to force new connections for each request.

D Configure random load balancing to avoid predictable server selection.

💡 Hint

Think about how to avoid sending requests to servers that are down.

Health checks help NGINX detect and exclude unhealthy backend servers, improving reliability when using round-robin.

🧠 Conceptual

expert

How does NGINX implement round-robin load balancing internally?

Which statement best describes how NGINX distributes requests using round-robin load balancing by default?

A NGINX selects the backend server with the fewest active connections for each new request.

B NGINX cycles through the list of backend servers sequentially, sending each new request to the next server in order.

C NGINX hashes the client IP address to consistently route requests from the same client to the same server.

D NGINX randomly selects a backend server for each request to distribute load unpredictably.

💡 Hint

Round-robin means taking turns in a fixed order.

Round-robin load balancing means NGINX sends requests one by one to each backend server in the order they are listed, cycling back to the first after the last.

Practice

1. What does the default round-robin method in nginx do when balancing requests?

easy

A. It sends requests based on server load automatically.

B. It sends all requests to the first server until it fails.

C. It sends requests randomly to any server.

D. It sends each new request to the next server in the list, cycling through them.

Solution

1. Step 1: Understand round-robin behavior in nginx

   Round-robin means distributing requests evenly by cycling through servers one by one.

2. Step 2: Match behavior to options

   Only It sends each new request to the next server in the list, cycling through them. describes cycling through servers for each new request.

3. Final Answer:

   It sends each new request to the next server in the list, cycling through them. -> Option D

4. Quick Check:

   Round-robin = cycling requests evenly [OK]

Hint: Round-robin cycles through servers one by one [OK]

Common Mistakes:

• Thinking round-robin sends all requests to one server
• Confusing round-robin with random or load-based methods
• Assuming round-robin skips servers

2. Which of the following is the correct syntax to define a round-robin upstream block in nginx?

easy

A. upstream backend { round_robin; server server1; server server2; }

B. upstream backend { server server1.example.com; server server2.example.com; }

C. upstream backend { server server1; server server2; load_balance round_robin; }

D. upstream backend { server server1; server server2; balance round_robin; }

Solution

1. Step 1: Recall nginx upstream syntax

   The default round-robin method requires only listing servers inside an upstream block without extra keywords.

2. Step 2: Check each option for correctness

   upstream backend { server server1.example.com; server server2.example.com; } correctly lists servers simply. Options B, C, and D use invalid or unsupported directives.

3. Final Answer:

   upstream backend { server server1.example.com; server server2.example.com; } -> Option B

4. Quick Check:

   Default round-robin needs only server list [OK]

Hint: Round-robin needs only server list, no extra keywords [OK]

Common Mistakes:

• Adding unsupported directives like round_robin or balance
• Using incorrect keywords inside upstream block
• Forgetting semicolons after server lines

3. Given this nginx upstream configuration:

upstream backend {
  server server1.example.com;
  server server2.example.com;
  server server3.example.com;
}

What server will handle the 5th incoming request?

medium

A. server2.example.com

B. server1.example.com

C. server3.example.com

D. Depends on server load

Solution

1. Step 1: Understand round-robin cycling through servers

   Requests are sent in order: 1->server1, 2->server2, 3->server3, then cycle repeats.

2. Step 2: Calculate 5th request server

   Requests 4 and 5 cycle back: 4->server1, 5->server2.

3. Final Answer:

   server2.example.com -> Option A

4. Quick Check:

   5 mod 3 = 2, so server2 handles 5th request [OK]

Hint: Count requests modulo server count to find server [OK]

Common Mistakes:

• Assuming 5th request goes to server3
• Thinking load affects round-robin by default
• Starting count from zero instead of one

4. You configured nginx upstream with:

upstream backend {
  server server1.example.com;
  server server2.example.com;
  server server3.example.com down;
}

But requests are still sent to server3.example.com. What is the likely problem?

medium

A. The 'down' parameter is misspelled or misplaced.

B. Nginx does not support marking servers as down.

C. The 'down' parameter requires a reload, not just restart.

D. The 'down' parameter disables the server only if it is unreachable.

Solution

1. Step 1: Check correct usage of 'down' parameter

   The 'down' flag must be placed immediately after the server address without extra spaces or errors.

2. Step 2: Identify common syntax mistakes

   If 'down' is misspelled or misplaced, nginx ignores it and still sends requests to that server.

3. Step 3: Understand reload vs restart

   Nginx requires a reload (nginx -s reload) to apply config changes like 'down'; a restart may not apply changes immediately.

4. Final Answer:

   The 'down' parameter requires a reload, not just restart. -> Option C

5. Quick Check:

   Reload nginx to apply 'down' flag changes [OK]

Hint: Reload nginx after config changes to apply 'down' flag [OK]

Common Mistakes:

• Misspelling 'down' as 'dwon' or 'dnw'
• Placing 'down' on a separate line
• Not reloading nginx after config change

5. You want to ensure nginx sends requests evenly to three servers but skip one server temporarily without removing it from config. Which is the best way to do this using round-robin?

hard

A. Mark the server as 'down' in the upstream block to skip it.

B. Remove the server line from the upstream block temporarily.

C. Add 'weight=0' to the server to disable it.

D. Use 'max_fails=0' to prevent requests to that server.

Solution

1. Step 1: Understand how to skip a server temporarily

   Marking a server as 'down' tells nginx to skip it without removing it from config.

2. Step 2: Evaluate other options

   Removing the server line is permanent. 'weight=0' is invalid syntax. 'max_fails=0' disables failure detection but not requests.

3. Final Answer:

   Mark the server as 'down' in the upstream block to skip it. -> Option A

4. Quick Check:

   'down' flag skips server temporarily [OK]

Hint: Use 'down' flag to skip server without removing it [OK]

Common Mistakes:

• Removing server line instead of marking down
• Using invalid 'weight=0' syntax
• Confusing max_fails with disabling server