Test your knowledge: Nginx Foundations

The NGINX process model, the C10K problem, installation anatomy, and zero-downtime 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 6

Which of these does the NGINX master process never do?

Think about privilege separation: the master is the control plane, workers are the data plane.

Answer options A Read and validate the configuration B Bind the listening sockets on privileged ports C Parse an HTTP request D Spawn and reap worker processes

The master never parses HTTP — not a single request. Parsing, routing, and proxying are worker work. The master reads config, binds sockets, manages workers, and handles signals.

Review this lesson

Question 2 of 6

The C10K problem that motivated NGINX was fundamentally about what?

The problem was architectural, not a tuning issue.

Answer options A Servers running out of disk IOPS at 10,000 requests B One-process-per-connection models spending CPU on scheduling themselves at 10,000 concurrent connections C TLS handshakes being too slow beyond 10,000 per day D IPv4 address exhaustion around the year 2000

Apache's process-per-connection model meant 10,000 mostly-idle connections burned CPU on context switches, lock contention, and memory for idle stacks. NGINX's answer was a fixed worker pool, each juggling thousands of connections in an event loop.

Review this lesson

Question 3 of 6

Which command validates the configuration as a dry run without touching the running instance?

It is the master's own authority on 'what is the config', exposed as a flag.

Answer options A nginx -s reload B nginx -t C nginx -V D nginx -q

nginx -t (optionally -T to dump the full merged config) parses and validates everything — including includes — without starting or reloading anything. -V prints build info, -s reload sends the signal.

Review this lesson

Question 4 of 6

What makes a config reload ( `nginx -s reload`) zero-downtime?

The master keeps the listening sockets open across config generations.

Answer options A Old workers finish in-flight requests while new workers already serve new ones on the same sockets B The master restarts the whole process family atomically C NGINX queues requests in shared memory during the swap D Workers are reused without being restarted, so nothing changes

The master validates the new config, spawns a new generation of workers, and hands them the same listening file descriptors. Old workers drain in-flight requests then exit — clients never see a closed socket.

Review this lesson

Question 5 of 6

`worker_processes auto;` sets the worker count to what?

One worker per CPU core is the design default.

Answer options A The number of CPU cores B Double the CPU cores C A fixed count of 8 D The value of ulimit -n divided by 1024

Each worker pins to a core and runs a single event loop — one worker per core keeps scheduling cheap and cache-hot. auto reads the core count at startup.

Review this lesson

Question 6 of 6

What does NGINX Plus actually buy you over open source NGINX?

The honest one-liner: 'Plus buys operations, not speed.'

Answer options A A faster event loop implementation B Operational features like active health checks, a dynamic upstream API, and vendor support C Exclusive HTTP/3 support D Larger worker_connections limits

Performance is the same engine. Plus adds operational tooling — active health checks, the dynamic reconfiguration API, session persistence, and support — which matter at scale, not for throughput.

Review this lesson

Test your knowledge: Nginx Foundations