Test your knowledge: Nginx Request Control

Question 1 of 6

`rewrite ^/api/(.*)$ /v1/$1 last;` — what does `last` do?

It re-enters the location search, internally.

Answer options A Applies the rewrite and continues matching further rewrite rules B Stops rewrite processing and re-runs location matching with the new URI — an internal redirect C Redirects the client to the new URI D Marks the rule as the final one in the file

last restarts location matching with the rewritten URI (internal, client-invisible). break applies within the current location. Without a flag, subsequent rewrites run; permanent/redirect send 301/302 to the client instead.

Review this lesson

Question 2 of 6

The famous 'if is evil' trap exists because `if` in rewrite context does what?

The trap is phase re-entry, not syntax.

Answer options A Evaluates per worker, so results disagree B Re-runs content-phase handlers inside the matched branch — directives like root applied there can be lost or duplicated (and try_files inside if is rejected outright by nginx -t) C It is parsed after proxies start D Nested if is syntactically invalid

When an if branch matches, NGINX re-runs the request in a nested location-like context — some directives (return, rewrite) are safe there, others (root, try_files inside the branch) produce the legendary 404 surprises. map avoids the phase entirely.

Review this lesson

Question 3 of 6

`auth_request /_auth;` protects a location how?

It is a gatekeeper subrequest.

Answer options A It requires the client to POST credentials to /_auth first B NGINX issues a subrequest to /_auth (say, a FastCGI app) before serving — 2xx allows, 401/403 denies, and the response can set variables for the main request C It basic-authenticates against a password file at /_auth D It checks the session cookie's signature

auth_request defers the decision to a subrequest: any 2xx passes the caller through, 401/403 propagate to the client, and auth_request_set copies values (like a user id) into main-request variables. One auth service guards every route that calls it.

Review this lesson

Question 4 of 6

`mirror /_shadow;` sends traffic to a test backend. What does the main request see of it?

Shadow traffic must be invisible to production behavior.

Answer options A Its response replaces the main one when faster B Nothing — the mirrored request is fire-and-forget; its response is discarded and it never delays the client C It is retried on the mirror when the main fails D The mirror sees only headers, never bodies

mirror duplicates the request (body included, via mirror_request_body) to a background location; the response is thrown away and the client's timing is untouched. It is the safe way to feed a new version real traffic.

Review this lesson

Question 5 of 6

`secure_link` URLs (signed download links) verify what?

The secret never travels; the derived MAC does.

Answer options A A TLS client certificate B A shared-secret MAC (keyed MD5) of the URI and expiry — a mismatched signature yields 403, a passed expiry yields 410 (secure_link_md5’s expires= tristate) C The Referer header against an allow list D A database session token

secure_link_md5 (or the secure_link_secret form) compares the MAC the app computed over the protected path and TTL. No round trip to an auth service: the signature itself carries and checks the policy.

Review this lesson

Question 6 of 6

The map cure for the if trap: what property makes `map` safe where `if` is not?

It is evaluation without execution.

Answer options A map runs at config parse time only B map computes a variable lazily at first use — no phase re-entry, no duplicated handlers, pure value computation C map results are shared across workers D map supports nested conditions natively

map never runs directives — it answers 'what value is this variable?' Branching collapses into data: the config consumes the variable (a proxy_pass target, a rate-limit key, a header) and behavior stays linear.

Review this lesson

Test your knowledge: Nginx Request Control