AI Advanced · 18% of the exam

Production AI Architecture: free practice questions

5 sample questions from our 129-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real DataCertPrep exam.

1. A startup is building a customer support chatbot using Next.js and the Vercel AI SDK. Users are complaining that the interface feels unresponsive because they see nothing until the full response arrives. Which combination of server-side and client-side changes will deliver the best perceived performance improvement?

A. Use a standard REST endpoint that returns JSON, and poll the endpoint every 500 ms from the client.
B. Switch the Next.js API route to use a streaming response with Server-Sent Events (SSE), and render tokens incrementally on the client with the AI SDK's `useChat` hook.✓ Correct
C. Increase the server's timeout limit to 120 seconds so the full response can be generated before sending.
D. Pre-generate all possible responses offline and serve them from a CDN edge cache.

Explanation

Option B is correct. Streaming via SSE allows the server to push each token to the client as it is generated. The AI SDK's `useChat` hook is purpose-built to consume this stream and append tokens to the UI incrementally, giving users immediate visual feedback. — Option A (polling) introduces latency between poll intervals and is wasteful on server resources; it does not provide token-by-token rendering. — Option C simply extends the silent wait; the user still sees nothing until the full response is ready, worsening the experience. — Option D is only feasible for a tiny, static FAQ set and is entirely impractical for an open-domain support chatbot.

2. A team runs a high-volume AI API and wants to implement a circuit breaker on their primary LLM provider connection. They configure the circuit breaker with a failure threshold of 5 consecutive errors and a half-open probe interval of 30 seconds. A chaos test introduces a provider outage lasting 3 minutes. Which sequence of states does the circuit breaker correctly transition through?

A. Closed → (5 consecutive failures) → Open → (30-second timer) → Half-Open → (probe succeeds after provider recovery) → Closed.✓ Correct
B. Closed → (5 consecutive failures) → Half-Open → (probe fails) → Open → (30-second timer) → Closed.
C. Closed → (first failure) → Open → (5 retry attempts) → Half-Open → (probe succeeds) → Closed.
D. Closed → (5 consecutive failures) → Open → (30-second timer elapses, provider still down) → Half-Open → (probe fails) → Closed.

Explanation

The canonical circuit breaker state machine is: **Closed** (normal operation, failures counted) → threshold met → **Open** (all requests immediately fail/fail-fast) → timer elapses → **Half-Open** (one probe request allowed) → probe succeeds → **Closed**. Option A correctly describes this sequence for a 3-minute outage where the provider recovers before or during the half-open probe. **B** is wrong — the circuit goes from Closed directly to Open (not Half-Open) after the failure threshold; Half-Open is the state after the timer, not immediately after failures. **C** is wrong — the circuit opens after the failure threshold (5 consecutive errors), not after the first failure; retry counts are separate from circuit breaker state transitions. **D** is wrong — when the probe in Half-Open state fails, the circuit returns to **Open** (not Closed); the timer resets and the cycle repeats until a probe eventually succeeds.

3. A SaaS company uses LiteLLM as an AI gateway to route requests across OpenAI, Anthropic, and a self-hosted vLLM instance. Their routing policy prioritizes the self-hosted model for cost savings, but falls back to GPT-4o if the self-hosted model is unavailable. After a deployment, the team notices that even when the self-hosted model is healthy, all traffic is routing to GPT-4o. Which configuration issue is MOST likely responsible?

A. LiteLLM's fallback list is ordered incorrectly, placing GPT-4o before the self-hosted model in the `model_list` priority order
B. The self-hosted vLLM endpoint's health check URL is returning HTTP 200 but with a non-OpenAI-compatible response body, causing LiteLLM to mark it as unhealthy
C. LiteLLM does not support mixing cloud and self-hosted providers in the same router configuration
D. The `rpm_limit` (requests per minute) on the self-hosted model entry is set to 0, causing LiteLLM to treat it as having no capacity and skip it✓ Correct

Explanation

In LiteLLM's router, setting `rpm_limit: 0` on a model entry is interpreted as zero available capacity, so the router will skip that model and immediately route to the next available option in the fallback chain. This would cause all traffic to bypass the self-hosted model even when it is healthy. — Option A is wrong: the model_list priority order affects routing, but the symptom is that the self-hosted model is skipped entirely, not that GPT-4o takes priority in a tie; an rpm_limit of 0 more precisely explains the complete bypass. — Option B is wrong: LiteLLM's health checks specifically probe the `/health` or `/models` endpoints; a valid HTTP 200 from the OpenAI-compatible API would typically be accepted. — Option C is wrong: mixing cloud and self-hosted providers is a core and well-documented LiteLLM use case.

4. A Next.js application uses an API route to stream LLM responses to the client using Server-Sent Events (SSE). A developer notices that when the API route is deployed on Vercel's serverless infrastructure, the stream silently cuts off after approximately 10 seconds on long responses. The underlying LLM provider stream is healthy and continues sending tokens. What is the MOST likely cause and the correct fix?

A. The AI SDK's `useChat` hook has a default 10-second client-side timeout; increase it via the `timeout` option in the hook configuration.
B. Vercel serverless functions have a maximum execution duration; the team should upgrade to a plan with a higher function timeout limit or migrate the streaming route to an Edge Runtime function.✓ Correct
C. SSE connections are not supported on serverless platforms; the team must switch to WebSockets for streaming LLM responses.
D. The `Content-Type: text/event-stream` header is missing from the response, causing the CDN to buffer the entire response and release it only after the function exits.

Explanation

Vercel serverless (Lambda-based) functions have a maximum execution duration (10 seconds on the Hobby plan, configurable on Pro/Enterprise). Long-running streams exceed this limit, causing a silent cutoff. The fix is to increase the timeout limit via plan upgrade or to use the Edge Runtime, which supports long-lived streaming responses without the same hard timeout. — Option A is wrong: `useChat` does not have a built-in 10-second timeout by default; the issue is server-side, not client-side. Option C is wrong: SSE is fully supported on serverless platforms within their execution time limits, and WebSockets are actually harder to implement on serverless infrastructure. Option D is wrong: a missing `Content-Type` header would typically cause the client to receive the response as a plain text download rather than streaming, not a silent cutoff mid-stream.

5. A conversational AI product uses a sliding-window approach to manage context: only the last N tokens of conversation history are included in each request. A product manager reports that users are frustrated because the assistant 'forgets' important details from earlier in long conversations. Which architecture change BEST preserves long-term context without linearly increasing token costs per turn?

A. Replace the sliding window with a hierarchical memory system: maintain a running LLM-generated summary of older turns and prepend it before the recent sliding window.✓ Correct
B. Double the context window size by switching to a model with 128K token support and passing the full conversation history on every request.
C. Store all conversation turns in a vector database and retrieve the top-3 most semantically relevant past turns to inject into each new request.
D. Increase the sliding window size from the last N to the last 2N tokens to retain more history.

Explanation

A hierarchical memory approach — compressing older turns into a running summary while keeping recent turns verbatim — preserves long-range context at roughly constant token cost per turn, regardless of conversation length. This is a well-established pattern for managing unbounded conversations. Option B is wrong — switching to a 128K model and passing full history solves the forgetting problem but costs grow linearly with conversation length, which the question explicitly asks to avoid. Option C is also a valid RAG-style approach, but without also including a summary, semantically relevant retrieval alone may miss sequential narrative context (e.g., user's name, ongoing task state) that isn't retrievable by similarity. Option D is wrong — doubling the window only delays the problem; forgetting still occurs and costs still scale with conversation length.

124 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free