Next.js Practice Test: App Router, Caching and Next.js 16

Next.js questions date faster than almost anything else you will be tested on. Caching defaults, params handling and middleware all changed between 13 and 16, so a bank written two years ago will confidently teach you answers that are now wrong. Everything here is written against Next.js 16.x.

A note on what this is. These are original practice questions, not a copy of any actual exam. Real test questions are confidential, and sites that publish them get taken down. Every question carries an explanation of why the answer is right.

What changed, and why it matters

If you learned the App Router when it launched, these are the answers that have since flipped. Each one appears in some form on current assessments, and each one has a plausible-sounding wrong answer that used to be correct.

1. v15params and searchParams became Promises.So did cookies(), headers() and draftMode(). You now write const { slug } = await params. This is the single most commonly missed migration step.
2. v15fetch is no longer cached by default.Next.js 13 and 14 cached fetches implicitly, which caused years of confusion about stale data. Caching is now opt-in via cache: 'force-cache' or a next.revalidate value.
3. v15GET Route Handlers are no longer cached by default.The same reversal. If you built an API endpoint on 14 that returned live data, it was probably being cached without you asking for it.
4. v16middleware.ts is now proxy.ts.The rename signals what the layer is for: fast, edge-level concerns. It was never the right place for database queries or business logic, and the old name encouraged exactly that.
5. v16'use cache' makes caching explicit.Placing it at the top of a function, component or file marks the output as reusable. Together with Partial Prerendering it becomes Cache Components — a static shell with dynamic holes streamed in.
6. v16Turbopack is the default bundler.Stable for all apps, with substantially faster Fast Refresh and builds than Webpack. The difference shows up most on large codebases.

What is covered

89 questions across 9 sections, every answer explained.

The one distinction everything hangs off

Most App Router questions reduce to a single idea: where a component runs, and therefore what it is allowed to do. Server Components are the default, they can be async and await data directly, and their JavaScript never reaches the browser. They cannot hold state or run effects.

The 'use client'directive does not mean “render in the browser” — Client Components still server-render for the initial HTML. It marks the point where the tree stops being server-only and starts shipping JavaScript. That is why putting it in the root layout forfeits the entire benefit, and why the answer to “how do I use a Server Component inside a Client Component” is always pass it as children, never import it.

Get that model straight and the questions about serializable props, onClick errors, hydration mismatches and bundle size all answer themselves.

How to use this bank

Work through it in study mode first, filtered to one section at a time. Do not grade yourself yet — reading the explanation for questions you got right is where most of the value is, because a right answer for the wrong reason will not survive a reworded question.

Then do a timed run across all sections. Anything you miss twice, go read that page of the Next.js docs rather than re-reading the explanation — and check the version, because the docs for 16 and the blog posts for 13 disagree about caching in ways that will cost you marks.