Blue-green deployment routing in Nginx - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Blue-Green Deployment Routing

In a blue-green deployment, two identical environments (blue and green) run different versions of an application. What is the main purpose of routing traffic between these environments?

A To run both versions simultaneously and merge their databases

B To gradually shift user traffic from the old version to the new version without downtime

C To deploy the new version only after the old version is completely shut down

D To randomly distribute traffic between unrelated applications

💡 Hint

Think about how users experience updates without interruptions.

Blue-green deployment routing allows switching user traffic smoothly from the old (blue) environment to the new (green) environment, minimizing downtime and risk.

💻 Command Output

intermediate

Nginx Configuration Output for Blue-Green Routing

Given this simplified Nginx snippet for blue-green deployment routing, what will be the upstream server handling requests when the set $upstream variable is set to green?

Nginx

upstream blue {
    server 10.0.0.1:8080;
}

upstream green {
    server 10.0.0.2:8080;
}

server {
    listen 80;
    location / {
        set $upstream green;
        proxy_pass http://$upstream;
    }
}

A Requests are forwarded to 10.0.0.2:8080

B Nginx will throw a syntax error due to variable usage in proxy_pass

C Requests are forwarded to 10.0.0.1:8080

D Requests are load balanced between 10.0.0.1:8080 and 10.0.0.2:8080

💡 Hint

Check which upstream block matches the variable $upstream.

The variable $upstream is set to green, so proxy_pass sends requests to the green upstream, which is 10.0.0.2:8080.

❓ Configuration

advanced

Identify the Error in Blue-Green Nginx Routing Configuration

Review this Nginx configuration snippet intended for blue-green deployment routing. Which option correctly identifies the error that will prevent proper routing?

Nginx

upstream blue {
    server 10.0.0.1:8080;
}

upstream green {
    server 10.0.0.2:8080;
}

server {
    listen 80;
    location / {
        set $upstream blue;
        proxy_pass http://$upstream/;
    }
}

A The 'set' directive cannot be used inside location blocks

B The upstream blocks must be named with IP addresses, not 'blue' or 'green'

C The trailing slash in proxy_pass causes Nginx to ignore the variable and route incorrectly

D Nginx requires proxy_pass to use a fixed URL, variables are not allowed

💡 Hint

Consider how Nginx handles proxy_pass with variables and trailing slashes.

When proxy_pass uses a variable with a trailing slash, Nginx ignores the variable and uses the literal string, causing routing errors. The trailing slash should be removed.

🔀 Workflow

advanced

Blue-Green Deployment Switch Workflow Using Nginx

Which sequence of steps correctly describes switching traffic from the blue environment to the green environment using Nginx configuration?

A 3,1,2,4

B 1,3,2,4

C 3,2,1,4

D 2,1,3,4

💡 Hint

Think about the logical order: readiness, config change, reload, then monitor.

First verify the green environment is ready, then update the config, reload Nginx to apply, and finally monitor traffic for issues.

❓ Troubleshoot

expert

Diagnosing Nginx Routing Failure in Blue-Green Deployment

After switching Nginx upstream from blue to green, users report 502 Bad Gateway errors. Which is the most likely cause?

A The proxy_pass directive is missing the http:// prefix

B Nginx configuration syntax error prevents reload

C The blue upstream block is missing from the config

D The green backend server at 10.0.0.2:8080 is down or unreachable

💡 Hint

502 Bad Gateway usually means Nginx cannot connect to the backend server.

502 errors indicate Nginx cannot reach the backend. Since traffic was switched to green, the green server is likely down or unreachable.