Why advanced patterns solve complex requirements in Nginx - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use advanced NGINX patterns for complex routing?

Which reason best explains why advanced NGINX configuration patterns are used for complex routing requirements?

A They reduce server memory usage by disabling modules.

B They allow combining multiple conditions and variables to control request flow precisely.

C They automatically update NGINX without manual reloads.

D They simplify the configuration by removing all conditional checks.

💡 Hint

Think about how complex rules need precise control over requests.

Advanced patterns let you combine conditions and variables to direct traffic exactly as needed, which is essential for complex routing.

💻 Command Output

intermediate

Output of NGINX config test with complex if conditions

What is the output when running nginx -t on this configuration snippet?

server {
  listen 80;
  if ($request_method = POST) {
    return 405;
  }
}

A nginx: configuration file /etc/nginx/nginx.conf test is successful

B nginx: [error] invalid parameter "POST" in if condition

C nginx: [emerg] "if" directive is not allowed here in /etc/nginx/nginx.conf:3

D nginx: [warn] unknown directive "if" in /etc/nginx/nginx.conf:3

💡 Hint

Check if the if directive is valid inside server block.

The if directive is allowed inside server blocks, so the configuration test passes successfully.

❓ Configuration

advanced

Correct advanced NGINX pattern for conditional proxy pass

Which configuration snippet correctly proxies requests to http://backend1 if the URI starts with /api/, otherwise to http://backend2?

A

location / {
  if ($uri ~ ^/api/) {
    proxy_pass http://backend1;
  }
  proxy_pass http://backend2;
}

B

location /api/ {
  proxy_pass http://backend1;
}
location / {
  proxy_pass http://backend2;
}

C

location / {
  set $target backend2;
  if ($uri ~ ^/api/) {
    set $target backend1;
  }
  proxy_pass http://$target;
}

D

location / {
  proxy_pass http://backend2;
  if ($uri ~ ^/api/) {
    proxy_pass http://backend1;
  }
}

💡 Hint

Consider how to use variables and conditions to choose proxy target in one location block.

Option C uses a variable $target set conditionally, then proxies to it. This is the correct advanced pattern for conditional proxying in one location.

❓ Troubleshoot

advanced

Troubleshooting NGINX rewrite loop with advanced patterns

Given this snippet, what is the cause of the rewrite loop?

location /app/ {
  rewrite ^/app/(.*)$ /$1 break;
  proxy_pass http://backend;
}

A The rewrite changes URI but does not stop processing, causing repeated rewrites.

B The proxy_pass directive is missing a trailing slash causing loop.

C The rewrite uses 'break' which prevents further processing and causes loop.

D The location block is missing 'last' flag in rewrite causing loop.

💡 Hint

Think about how rewrite flags affect URI processing and loops.

The 'break' flag stops internal redirects but the rewritten URI still matches the location, causing repeated rewrites and a loop.

🔀 Workflow

expert

Order of directives for advanced NGINX caching with conditional bypass

What is the correct order of directives to implement caching that bypasses cache for logged-in users using the $cookie_logged_in variable?

A 4,2,1,3

B 2,1,4,3

C 1,2,3,4

D 2,4,1,3

💡 Hint

Consider the order NGINX expects cache setup and bypass directives before proxying.

First enable cache with proxy_cache, then set cache validity, then conditionally bypass cache, and finally proxy the request.