Upstream blocks in Nginx - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define an upstream block named 'backend'.

Nginx

upstream [1] {
    server 192.168.1.10:80;
    server 192.168.1.11:80;
}

Drag options to blanks, or click blank then click option'

Abackend

Bproxy

Cserver_group

Dupstream_block

Attempts:

3 left

💡 Hint

Common Mistakes

Using reserved keywords as the name

Using spaces in the name

The upstream block name is 'backend' to group backend servers.

2fill in blank

medium

Complete the code to use the upstream block 'backend' in a server location.

Nginx

location /api/ {
    proxy_pass http://[1];
}

Drag options to blanks, or click blank then click option'

Aserver_group

Bproxy

Cbackend

Dupstream_block

Attempts:

3 left

💡 Hint

Common Mistakes

Using the wrong upstream name

Omitting the 'http://' prefix

The proxy_pass directive should point to the upstream block named 'backend'.

3fill in blank

hard

Fix the error in the upstream block by completing the missing directive.

Nginx

upstream backend {
    server 192.168.1.10:80;
    [1] 192.168.1.11:80;
}

Drag options to blanks, or click blank then click option'

Aserver

Blocation

Clisten

Dproxy_pass

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'proxy_pass' inside upstream

Omitting 'server' keyword

Each server in the upstream block must be declared with the 'server' directive.

4fill in blank

hard

Fill both blanks to configure load balancing with least connections and set max fails.

Nginx

upstream backend {
    [1] 192.168.1.10:80 max_fails=3 fail_timeout=30s;
    [2] 192.168.1.11:80 max_fails=3 fail_timeout=30s;
    least_conn;
}

Drag options to blanks, or click blank then click option'

Aserver

Blisten

Cproxy_pass

Dlocation

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'listen' or 'proxy_pass' instead of 'server'

Missing 'server' keyword on one line

Both backend servers must be declared with the 'server' directive to apply settings and load balancing.

5fill in blank

hard

Fill all three blanks to create an upstream block with weighted servers and health checks.

Nginx

upstream backend {
    [1] 192.168.1.10:80 weight=5 max_fails=2 fail_timeout=20s;
    [2] 192.168.1.11:80 weight=3 max_fails=2 fail_timeout=20s;
    [3] 192.168.1.12:80 weight=2 max_fails=2 fail_timeout=20s;
}

Drag options to blanks, or click blank then click option'

Aserver

Blisten

Cproxy_pass

Dlocation

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'listen' or 'proxy_pass' instead of 'server'

Mixing directives inside upstream block

All backend servers must be declared with the 'server' directive to set weights and health check parameters.

Practice

1. What is the main purpose of an upstream block in an nginx configuration?

easy

A. To set caching rules for static files

B. To group backend servers for load balancing

C. To define client request headers

D. To configure SSL certificates

Solution

1. Step 1: Understand the role of upstream blocks

   Upstream blocks in nginx are used to group backend servers together.

2. Step 2: Identify the purpose of grouping

   This grouping allows nginx to distribute incoming traffic among these servers, which is called load balancing.

3. Final Answer:

   To group backend servers for load balancing -> Option B

4. Quick Check:

   Upstream blocks = backend server groups [OK]

Hint: Upstream blocks group servers for load balancing [OK]

Common Mistakes:

• Confusing upstream with SSL or caching settings
• Thinking upstream defines client headers
• Assuming upstream is for static file rules

2. Which of the following is the correct syntax to define an upstream block named backend with two servers server1.example.com and server2.example.com?

easy

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

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

C. upstream backend { backend server1.example.com; backend server2.example.com; }

D. upstream backend { server: server1.example.com; server: server2.example.com; }

Solution

1. Step 1: Recall the upstream block syntax

   The correct syntax requires the keyword server before each backend server address inside curly braces.

2. Step 2: Match the syntax with options

   upstream backend { server server1.example.com; server server2.example.com; } correctly uses server server1.example.com; and server server2.example.com; inside the upstream block.

3. Final Answer:

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

4. Quick Check:

   Each backend needs 'server' keyword [OK]

Hint: Each server line starts with 'server' keyword [OK]

Common Mistakes:

• Omitting 'server' keyword before addresses
• Using colons instead of spaces
• Adding extra keywords like 'backend' inside block

3. Given this nginx upstream block:

upstream backend {
    server 192.168.1.10 weight=3;
    server 192.168.1.11;
}

What does the weight=3 mean for 192.168.1.10?

medium

A. It receives three times more requests than 192.168.1.11

B. It is a backup server and only used if 192.168.1.11 fails

C. It limits connections to 3 simultaneous clients

D. It will be ignored because weight is invalid here

Solution

1. Step 1: Understand weight in upstream servers

   The weight parameter assigns relative load share to a server. A higher weight means more requests.

2. Step 2: Interpret the weight=3 for 192.168.1.10

   Since 192.168.1.10 has weight=3 and 192.168.1.11 has default weight=1, the first server gets 3 times more requests.

3. Final Answer:

   It receives three times more requests than 192.168.1.11 -> Option A

4. Quick Check:

   Weight controls request distribution [OK]

Hint: Weight multiplies request share for that server [OK]

Common Mistakes:

• Confusing weight with backup role
• Thinking weight limits connections
• Assuming weight is ignored if not 1

4. Identify the error in this upstream block configuration:

upstream backend {
    server 10.0.0.1;
    server 10.0.0.2 backup;
    server 10.0.0.3 weight=two;
}

medium

A. Upstream block cannot have more than two servers

B. Backup server must be listed first

C. Missing semicolon after server 10.0.0.1

D. The weight value 'two' is invalid; it must be a number

Solution

1. Step 1: Check syntax of weight parameter

   The weight parameter must be a numeric value. 'two' is a string and invalid.

2. Step 2: Verify other parts of the block

   Semicolons are present, backup server can be anywhere, and multiple servers are allowed.

3. Final Answer:

   The weight value 'two' is invalid; it must be a number -> Option D

4. Quick Check:

   Weight must be numeric [OK]

Hint: Weight values must be numbers, not words [OK]

Common Mistakes:

• Placing backup server only first
• Forgetting semicolons
• Limiting number of servers incorrectly

5. You want to configure an upstream block named app_servers with three servers: 10.1.1.1 (weight 5), 10.1.1.2 (weight 1), and 10.1.1.3 as a backup. Which configuration is correct?

hard

A. upstream app_servers { server 10.1.1.1 weight=5; server 10.1.1.2; server 10.1.1.3 backup=1; }

B. upstream app_servers { server 10.1.1.1 weight=5; server 10.1.1.2 weight=1 backup; server 10.1.1.3; }

C. upstream app_servers { server 10.1.1.1 weight=5; server 10.1.1.2 weight=1; server 10.1.1.3 backup; }

D. upstream app_servers { server 10.1.1.1; server 10.1.1.2 weight=1; server 10.1.1.3 backup weight=5; }

Solution

1. Step 1: Assign weights correctly

   Servers 10.1.1.1 and 10.1.1.2 must have weights 5 and 1 respectively, using weight=.

2. Step 2: Mark backup server properly

   Server 10.1.1.3 should be marked with the backup keyword without weight.

3. Step 3: Validate options

   upstream app_servers { server 10.1.1.1 weight=5; server 10.1.1.2 weight=1; server 10.1.1.3 backup; } correctly assigns weights and backup keyword. Others misuse backup or weight syntax.

4. Final Answer:

   upstream app_servers { server 10.1.1.1 weight=5; server 10.1.1.2 weight=1; server 10.1.1.3 backup; } -> Option C

5. Quick Check:

   Weight and backup keywords used correctly [OK]

Hint: Use 'weight=' for load, 'backup' alone for backup server [OK]

Common Mistakes:

• Using 'backup=1' instead of 'backup'
• Combining weight and backup on same server
• Omitting weight for weighted servers