Test your knowledge: Nginx Dynamic Upstreams

The resolver, runtime re-resolution, and service discovery without reloads.

Stuck? Each question has an optional hint.

Skip a hard question and review it before your results.

Questions and answer options can shuffle between attempts.

You can retake this quiz whenever you like.

Question 1 of 5

Why does a `resolver` directive make upstreams dynamic?

Static names resolve once at config load; variables resolve forever.

Answer options A It replaces the OS hosts file B With a resolver and a variable in proxy_pass, NGINX re-resolves the name at runtime (valid= schedule, TTL by default) — no reload to pick up a changed address C It queries Consul on every request D It enables DNS-based load balancing by default

A literal proxy_pass http://backend.example.com is pinned at startup. Put the name in a variable with a resolver declared, and each TTL expiry re-queries DNS — the address can change underneath a running NGINX.

Review this lesson

Question 2 of 5

`resolver 127.0.0.53 valid=30s;` — what does `valid` override?

It puts you in charge of freshness.

Answer options A How long DNS failures are cached B The re-resolution interval, ignoring the record's own TTL — you decide the staleness budget C The timeout of the DNS query itself D How many resolver addresses are tried

valid= forces re-resolution on your schedule regardless of the record's TTL — long-TTL service records in a fast-moving cluster become as fresh as you need. resolver_timeout bounds each query.

Review this lesson

Question 3 of 5

DNS SRV records add what over A records for upstream discovery?

A records answer 'where'; SRV answers 'where, on which port, and in what order.'

Answer options A Encryption of the address list B Port and priority/weight per endpoint — NGINX (with the service= parameter) gets the full placement, not just IPs C Health status of each server D Cross-zone routing rules

SRV carries port, priority, and weight alongside the name — the extra dimensions schedulers and service meshes publish. Upstream blocks that resolve SRV inherit the placement the registry intends.

Review this lesson

Question 4 of 5

The live DNS failover demo proves what about reloads?

The whole point of the resolver path.

Answer options A Reloads are free when a resolver is configured B A backend's address change is picked up by the valid= re-resolution window alone — zero reloads, zero dropped connections, workers untouched C NGINX queues requests during re-resolution D The master re-executes the config for changed upstreams only

Re-resolution happens inside the worker's normal event loop: the new address is used for new connections while old ones drain naturally. The config file never changes, so the master never intervenes.

Review this lesson

Question 5 of 5

`set $backend api.internal; proxy_pass http://$backend;` — what does this enable that a literal name does not?

One set line flips the resolution model.

Answer options A HTTP/2 to the upstream B Runtime resolution: the variable forces the resolver path, so the name can be re-resolved — and even swapped per request by a map C Automatic retries on DNS failure D TLS for the upstream leg

Variables in proxy_pass are resolved at request time through the configured resolver — the hook for per-request routing (map feeding $backend) and runtime re-resolution. Literal names are load-time constants.

Review this lesson

Test your knowledge: Nginx Dynamic Upstreams