Everything the adaptive question bank can teach and test in Hosting & Deployment, from foundations through advanced practice. Work through it in order, or start practising and let the questions find your level.
A. What "deployed" actually means — the request path
•
the browser must resolve the hostname to an IP address before a single HTTP byte is sent
•
connect, then the TLS handshake, then the HTTP request; a failure at each of the three looks completely different
•
the edge is the machine that answers the client; the origin is the machine that owns the content
•
a proxied hostname resolves to the platform's addresses and hides the origin; a DNS-only hostname hands the origin's IP straight to the client
•
putting the artifact on the servers and exposing its behavior to users are two separate events that can be days apart
•
a PaaS trades control for operational surface; moving toward VMs buys control and buys the on-call with it
•
a platform build turns a repo into a runnable artifact by detection or buildpack, with no Dockerfile written by you
•
gzip or Brotli on text responses cuts bytes on the wire without changing what the origin generated
•
preconnect pays the DNS, TCP and TLS cost early for an origin you know you are about to use
B. Domains, registrars and delegation
•
the company you rent the name from is not necessarily the one answering queries for it, and edits at the wrong one do nothing
•
the registry's NS records decide which servers are authoritative for the zone; that delegation is what a "nameserver change" moves
•
a full setup moves the whole zone's nameservers to the platform; a partial setup leaves them elsewhere and points one hostname in by CNAME
•
example.com is the zone apex; www.example.com is a child label that can be pointed somewhere else entirely
•
DNSSEC signs answers so forgery is detectable, and moving nameservers without updating the DS record at the registrar makes the whole zone fail validation
C. DNS record types
•
A maps a name to an IPv4 address and AAAA to IPv6; publishing both means the client picks, and a broken AAAA breaks half your users
•
a CNAME points a name at another *name*, and the resolver then has to resolve that one too
•
a name holding a CNAME may hold no other record, which is exactly why the apex normally cannot be a CNAME
•
CNAME flattening (also sold as ALIAS or ANAME) resolves the target server-side and answers the apex with a plain A record
•
mail routing lives in its own records, so repointing A/CNAME during a host migration must not drop the MX set
•
a CAA record names which certificate authorities may issue for the domain, and a stale one silently blocks renewal
•
the same name resolves differently inside and outside a network, which is deliberate and confusing
D. TTL, caching and "propagation"
•
the TTL is how many seconds a resolver may reuse the answer, not how long the change takes to save
•
nothing is pushed anywhere; "propagation delay" is only old cached answers timing out at their own pace
•
drop the TTL hours before a cutover and raise it after, because the *old* TTL governs the switch
•
an NXDOMAIN is cached too, bounded by the SOA minimum, so a record you just created can still look missing
•
DNS-level failover is bounded by TTL and by resolvers that overrule it, so it is a disaster-recovery tool, not a high-availability one
E. TLS certificates and issuance
•
a certificate is a CA's signed assertion that a public key belongs to a hostname; the client trusts the CA, not you
•
modern clients match the hostname against the Subject Alternative Name list and ignore the legacy Common Name entirely
•
*.example.com covers app.example.com but neither the bare apex nor a.b.example.com
•
HTTP-01 proves control of a path on port 80, DNS-01 proves control of the zone and is the only challenge that can issue a wildcard
•
certificates are short-lived by design, so the outage comes from a broken renewal job or a blocked challenge, never from the original issuance
•
the server must send the intermediate certificates; when a browser works and curl or a mobile client fails, suspect a missing intermediate
•
the client names the host in the handshake, which is how one IP address can present hundreds of different certificates
•
HSTS pins a browser to HTTPS for the whole max-age, so you cannot recover from a certificate mistake by falling back to plain HTTP
•
old TLS versions and cipher suites are disabled because their weaknesses are exploitable, not theoretical
F. Origin trust and the two TLS legs
•
proxied traffic is two independent encrypted connections, browser→edge and edge→origin, and either can be weaker than the other
•
terminating TLS at the edge and speaking plain HTTP to the origin shows a padlock while the second leg is cleartext
•
"full" encrypts to the origin but accepts any certificate including a self-signed one; only "strict" actually validates it
•
an origin that redirects HTTP→HTTPS while the edge is configured to call it over HTTP produces an infinite redirect
•
an origin still reachable by its raw IP bypasses the edge's cache and WAF, so it must accept only the proxy's addresses, a token, or a client certificate
G. CDN caching semantics
•
a miss fetches from the origin and populates that edge location; only the *second* request there is fast
•
max-age instructs the browser, s-maxage instructs the shared cache, and where both are present the shared cache obeys the latter
•
no-store forbids keeping any copy; no-cache permits keeping it but requires revalidation before every reuse
•
private means only the end user's own browser may store the response, and it is what keeps per-user HTML out of a CDN
•
serve the expired copy immediately and refresh it in the background, so a slow origin never blocks a user
•
keep serving the expired copy while the origin returns 5xx, converting an origin outage into merely stale content
•
revalidation sends If-None-Match, and a 304 response carries headers but no body
•
content-hashed filenames can be cached for a year safely, because any change produces a different URL rather than a stale one
•
a range request fetches part of an object, which is what makes seeking and resuming possible
•
a signed, expiring URL grants time-boxed access to private content without an auth round trip
H. Cache keys, purging and invalidation
•
two requests share a cached object only when their cache keys are identical; host, path and query string are in the key by default
•
Vary splits the stored object once per distinct value of the named header, so varying on a high-cardinality header destroys the hit rate
•
tracking parameters mint a separate cache entry per visitor unless the key is configured to ignore them
•
purging by URL requires reproducing the exact key, while tag or prefix purge invalidates a whole related set in one call
•
a purge is a distributed invalidation with no completion guarantee, so a deploy should rely on versioned URLs rather than a synchronous flush
•
a Set-Cookie on a response the shared cache stored will hand one user's session to the next requester
I. Reverse proxies and load balancers
•
the reverse proxy terminates the client's connection and opens its own to a backend, which is what lets it cache, route and shield
•
an L4 balancer forwards a byte stream and cannot see the URL; an L7 balancer parses HTTP and can route on path, header or cookie
•
round robin ignores how busy a backend is, least-connections follows it, and slow requests are what expose the difference
•
cookie affinity keeps a user pinned to one backend, which works and quietly makes that backend stateful and un-drainable
•
behind a proxy the socket peer is the proxy, so the real client IP arrives in a header that you must validate before trusting
•
steering by geography or measured latency sends a user to the nearest healthy pool, unlike a static failover order
•
a WAF inspects traffic at the edge and drops known-bad requests before they reach an origin
J. Health checks, draining and zero-downtime
•
liveness answers "should this be restarted?", readiness answers "should this receive traffic?", and conflating them causes restart loops
•
a health check that queries the database marks the entire fleet unhealthy the moment the database blips
•
a slow-booting process needs an explicit startup allowance, or the supervisor kills it before it ever becomes ready
•
the platform sends SIGTERM, waits a fixed grace period, then sends SIGKILL; an app that ignores SIGTERM always loses in-flight requests
•
stop accepting new connections, let the in-flight ones finish, then exit — that ordering is what makes a deploy invisible
•
fail readiness first and keep serving for a few seconds, because the load balancer learns about the removal after the fact
K. Static, server-rendered and hybrid output
•
a prerendered site is objects on a CDN with no runtime to scale, patch or exploit
•
per-request HTML requires a live process or function somewhere, and its cost and failure surface scale with traffic
•
shipping an empty shell moves the work to the device, delays first content, and gives crawlers nothing to read
•
prerender the page, then rebuild it in the background on a timer or an explicit signal, trading freshness for origin cost
•
a client-routed app needs unknown paths rewritten to the shell, or every deep link and refresh returns a 404
•
a value read during the build is frozen into the bundle, so changing the runtime environment cannot change it
L. Serverless and edge runtimes
•
the platform creates an instance per concurrent request, so there is no queue or thread pool of yours to tune
•
an instance that does not exist must be created and initialized first, and heavy top-level imports are paid on every cold request
•
a V8 isolate boots in milliseconds because it shares a process, at the price of no native modules and no full Node API
•
time spent awaiting I/O is not CPU time, so a runtime that caps CPU lets a slow downstream call run far longer than the number suggests
•
anything started and not awaited dies when the response is returned, unless the platform exposes an explicit "wait until" hook
•
module-level state survives between invocations on a warm instance, which makes it a valid cache and never a source of truth
•
functions call outward from shared, changing addresses, so an upstream that allowlists by IP will not work
M. State, storage and data locality
•
anything written to local disk vanishes with the instance and was never visible to the other instances anyway
•
user files belong in an object store, usually uploaded direct-to-storage with a signed URL rather than through the app
•
a globally replicated key-value store can serve a stale read for some seconds after a write, by design
•
counters, locks, rate limits and seat reservations need one authoritative location, not one replica per region
•
an edge function far from its single-region database is slower than a regional server next to it; place compute near the data it reads
•
regulated data may be required to stay in a jurisdiction, which constrains where the compute, the caches and the backups may live
N. Container images and the Dockerfile
•
each instruction produces a read-only layer, and the running container only adds one thin writable layer on top
•
deleting a file in a later layer hides it without shrinking the image, so a secret added in an earlier layer stays extractable
•
a slim or distroless base cuts image size and CVE surface, and also removes the shell and package manager you were about to debug with
•
COPY does exactly one thing, while ADD also fetches URLs and auto-extracts archives, which is almost never what was intended
•
ENTRYPOINT is the command and CMD supplies its default arguments; only the exec form makes your process PID 1 and lets it receive signals
•
a container runs as root unless the image declares USER, and "it's isolated" is not the same as "it's unprivileged"
•
HEALTHCHECK lets the runtime call a container unhealthy while the process is still alive, which is the difference between hung and dead
O. Build cache, image size and reproducibility
•
copy the dependency manifest and install *before* copying the source, so editing one line of code does not reinstall every package
•
once one layer's cache is invalidated, every layer after it rebuilds regardless of whether its own inputs changed
•
an unignored .git or node_modules both inflates the build context and busts the cache on every single build
•
build in a fat stage and copy only the finished artifact into a thin runtime stage, so the compiler and the source never ship
•
ARG values are recorded in the image history and readable by anyone with the image; a real secret needs a build-time secret mount
•
FROM node:latest is a moving target, so an identical Dockerfile can produce a different image tomorrow
P. Registries and the orchestrator handoff
•
a tag can be repointed at any time while a sha256: digest cannot, so deploying by digest is what makes a rollout reproducible
•
always-pull versus use-cached-if-present decides whether a re-pushed tag actually reaches a node that already has that tag
•
one tag can index amd64 and arm64 images, and an arch mismatch built on an Apple-silicon laptop only fails at runtime on the server
•
a private image needs credentials available on the node, and a missing one fails as a pull error that looks nothing like an application bug
•
a containerized process writes to stdout and stderr and lets the platform collect them, instead of owning log files it cannot rotate
Q. Configuration and secrets in the pipeline
•
everything that differs between environments lives outside the artifact, so one build can run in all of them
•
rebuilding separately per environment means staging never actually tested the bytes that production runs
•
a secret must be write-only after it is set: not readable from the dashboard, not echoed in build output, not printed by a debug endpoint
•
a variable inlined into the client bundle is published permanently, and prefixes like NEXT_PUBLIC_ or VITE_ are an explicit opt-in to that
•
a credential that can only be rotated by rebuilding will not be rotated during the incident that requires it
•
a CI job that federates to the cloud with a per-run OIDC token has no long-lived key to leak; the win is credential lifetime and scope, not speed
R. CI/CD: build once, preview, promote
•
the artifact that passed staging must be the identical bytes promoted to production, never a fresh rebuild of the same commit
•
every build keeps its own permanent URL, which is what turns both promotion and rollback into an alias switch instead of a rebuild
•
an ephemeral environment per pull request lets a reviewer exercise behavior rather than read a diff
•
a preview environment pointed at the production database is a production write path wearing a temporary URL
•
type checks, tests and a successful build must be able to fail the pipeline, or the pipeline is only a deploy button with extra steps
•
deploy credentials held by CI are production credentials, and a workflow triggered by a fork's pull request must never be handed them
S. Release strategies and rollback
•
replace instances a few at a time, which means both versions serve real traffic for the length of the rollout
•
stand the new version up beside the old, cut traffic over in one step, and keep the old fleet warm so reverting is another one-step switch
•
route a small share of traffic to the new version first, so a defect is discovered by 1% of users instead of all of them
•
a percentage rollout that nobody is comparing error rate or latency against is just a slower outage
•
the code ships dark and a flag turns the behavior on, so a bad feature is switched off in seconds without a deploy
•
reverting the artifact is fast, but an applied migration, a drained queue or a sent email can make backward the impossible direction
•
add the new column, ship code that writes both, backfill, then drop the old one — a rename in a single release breaks whichever version is still running
T. Monitoring, logging and release signal
•
logs are discrete events, metrics are aggregates over time, and traces follow one request across service boundaries
•
a log line emitted as JSON fields is queryable and aggregatable; the same facts interpolated into a sentence are not
•
a request or trace id threaded through every hop is what makes one user's specific failure findable afterwards
•
a healthy mean latency routinely hides the p99 that the complaining users are experiencing
•
traffic, error rate, latency and saturation are the four series a deploy should be judged against before it widens
•
page on user-visible SLO burn rather than on CPU or memory, or the on-call is trained to ignore the pager
•
logs inherit the privacy obligations of whatever they contain, including tokens that arrived in a query string
•
every distinct label combination is another time series, which is how a metrics bill explodes
U. Cost, egress and capacity
•
bandwidth leaving a provider is metered while ingress usually is not, which is what makes a chatty cross-cloud architecture expensive
•
every edge hit is an origin request you did not pay for in money, capacity or latency
•
serverless bills invocation count and execution time separately, so a fast function called constantly and a slow one called rarely fail the budget differently
•
an always-on instance bills while doing nothing; scaling to zero removes that bill and buys a cold start with it
•
on most platforms the memory tier also sets the CPU share, so a larger instance that finishes sooner can be cheaper per request
•
a retry storm, a crawler loop or a runaway cron turns directly into money, so spend alerts belong in the deploy checklist
•
a managed service costs money to avoid costing time, and the trade only pays where the ops burden is real
V. Production failure modes
•
a container must listen on the port the platform injects and on 0.0.0.0; binding to a hardcoded port or to localhost passes locally and fails every health check
•
a popular cached object expiring everywhere at once stampedes the origin, so fills need jitter or request coalescing
•
retries at the client, the proxy and the service multiply together, so retries need backoff, jitter and a budget
•
serverless concurrency multiplied by a pool per instance overwhelms a database's connection limit; an external pooler is the fix, not a bigger pool
•
a long-cached HTML shell requesting hashed assets that the new deploy removed breaks the app until the HTML itself is invalidated
•
a slow dependency called without a timeout ties up every worker, turning one degraded service into a total outage
•
a backup nobody has restored is a hypothesis; the drill is what makes it a backup
•
RPO is how much data you can afford to lose, RTO is how long you can afford to be down
W. Web security headers, cookies and CORS
•
an HTTPS page loading a subresource over HTTP — the browser blocks or downgrades it, so the padlock is not the whole story
•
Content-Security-Policy constrains which sources may execute, turning an injected script into a blocked one
•
a strict policy drops inline handlers and eval, because an allowlist that permits them permits the attack too
•
X-Content-Type-Options stops the browser guessing a content type the server did not declare
•
clickjacking is answered by frame-ancestors (or X-Frame-Options), not by anything inside the page
•
HttpOnly keeps a session cookie out of document.cookie, so script that leaks cannot read it
•
the Secure flag stops a cookie ever travelling over plain HTTP
•
SameSite governs cross-site sending; None is cross-site by request and therefore requires Secure
•
Referrer-Policy decides how much of the current URL travels to the next origin
•
CORS relaxes the browser same-origin rule; it is not a server-side access control
•
a preflight OPTIONS fires when the request is not simple — a custom header, an unusual method, a non-form content type
•
Access-Control-Allow-Origin: * cannot be combined with credentials, and is wrong for anything private
•
start from a deny-heavy baseline and loosen per surface, because an omitted header fails open
X. SLOs, error budgets and incident practice
•
an indicator is the measured quantity — latency, availability, error rate — not the target for it
•
an objective is the target you commit to over a window, which is what makes it arguable
•
the budget is the failure the SLO permits; spending it is expected, and exhausting it is a signal, not a scandal
•
a runbook turns a known failure into steps someone can follow at 3am without context
•
the output is the system change that stops recurrence, not the person who typed the command
Y. Asynchronous work: queues, retries and idempotency
•
anything slow and not needed for the response belongs behind a queue, so the request can return
•
a queue converts a spike in arrivals into a longer backlog rather than a pile of timeouts
•
at-least-once delivery means a message can arrive twice, so processing must be safe to repeat
•
a client-supplied key lets the server recognise a retried request instead of charging twice
•
backpressure is the downstream telling the upstream to slow down instead of failing under load
•
a DLQ parks what cannot be processed so one poison message does not stall the queue
Z. Infrastructure as code and drift
•
you describe the wanted end state and the tool computes the change, which is what makes it reviewable
•
drift is reality diverging from the recorded state, usually via a console change nobody wrote down
•
a scheduled plan that expects an empty diff is how drift is found before it matters
•
a community fork of Terraform created after its licence change, sharing the language and workflow
Keentune is not affiliated with or endorsed by the organizations whose documentation informs these maps.
All exam, test, and product names and trademarks are the property of their respective owners and are used here for identification and reference only. Keentune is independent study practice — not affiliated with, authorized, or endorsed by any of these organizations.