Test your knowledge: Nginx Production Architectures

Question 1 of 5

The 'edge tier' in a multi-tier NGINX topology is characterized by what?

Outermost, shared by everything, deliberately generic.

Answer options A It holds the business logic B It owns TLS termination, routing, rate limiting, and caching — the outermost, most-shared layer, kept thin and stateless C It is the only tier allowed to talk to databases D It replaces the CDN entirely

The edge concentrates cross-cutting concerns: certificate management, routing maps, limits, caches. Keeping it stateless and thin lets the inner tiers (app-specific gateways) carry the peculiar business routing.

Review this lesson

Question 2 of 5

NGINX as a container works best following which contract?

Twelve-factor instincts: inject, stream, signal.

Answer options A Bake the full config into the image at build time, never change it B One concern per container, config injected at runtime (mounted or templated), logs to stdout/stderr, signals unblocked so reloads work C Run many virtual hosts per container with shared disk config D Use host networking to avoid port mapping

The container contract: config arrives at runtime (envsubst templates or mounts), logs stream to stdout/stderr for the platform, and PID 1 execs nginx directly so SIGHUP reloads survive. Violations are why 'docker restart' becomes the only reload.

Review this lesson

Question 3 of 5

In Kubernetes, what does an Ingress actually provide?

The resource is the intent; the controller is the translator.

Answer options A A service mesh with mTLS B L7 routing rules (host/path to service) plus TLS termination at the cluster edge — realized by a controller that programs a data plane like NGINX C Container image builds D Pod-level network policies

An Ingress object declares routing intent; an ingress controller watches those objects and programs a real proxy — classically NGINX — with server blocks, locations, and certificates. The mini ingress controller in Lesson 14.4 builds exactly this loop.

Review this lesson

Question 4 of 5

A minimal NGINX ingress controller is which loop?

Observe, render, validate, reload — repeat.

Answer options A Tail the access log and alert on 5xx B Watch Ingress/Service objects, render an nginx.conf from templates, validate it ( nginx -t), and reload — continuously reconciling declared vs. running state C Poll endpoints with curl and rewrite DNS D Sync certificates to a git repository

The controller is a reconciliation loop: watch the API's declared state, template it into config, prove it with nginx -t, apply it with a reload. Validate-before-apply is what makes the loop safe to run forever.

Review this lesson

Question 5 of 5

The honest first question when choosing an ingress implementation is what?

Same engine, different operations.

Answer options A Which one benchmarks fastest B What your team can operate: config model, upgrade path, observability, and blast radius — the deltas between implementations are operational, not throughput C Which has the most GitHub stars D Whether it reuses your existing load balancer's config language

Most ingress implementations program the same NGINX core — the difference is the config abstraction, upgrade story, and debugging surface. Choose the one your on-call engineers can reason about at 3 AM.

Review this lesson

Test your knowledge: Nginx Production Architectures