# Quiz — Session 8: Infrastructure & Deployment **Program:** Applied AI — Intermediate Level — Instructor: Yann Isola **Format:** 14 MCQs (multiple choice questionnaire) — only one correct answer per question — recommended duration: 12 minutes. --- **Q1. What is the essential difference between a notebook prototype and a production service?** - A. The prototype uses a less powerful model than the production - B. Production must manage what the prototype ignores: authentication, failures, latency, costs, observability, security and scalability for thousands of users - C. The prototype is written in Python, the production in another language - D. There is no difference if the prompt is well written **Q2. Why should you NEVER place an API key in client-side code (browser, mobile application)?** - A. Because it slows down the loading of the page - B. Because providers prohibit more than two keys per account - C. Because anyone inspecting the client's code (developer tools, decompilation) can read the key, steal it and consume the API at your expense - D. Because API keys only work on Linux servers **Q3. Your application receives an HTTP 429 (Too Many Requests) response. What is the correct reaction?** - A. Try again immediately, in a loop, until it passes - B. Wait then retry with an exponential backoff (1 s, 2 s, 4 s…) and jitter (random variation), respecting the `retry-after` header if it is provided - C. Permanently abandon the request: a 429 error means that the account is banned - D. Change API key to bypass limitation **Q4. Which category of errors should NOT be automatically retried?** - A. Errors 429 (rate limit exceeded) - B. 500/503 errors (server error or temporary unavailability) - C. 400/401/403 errors (invalid request, missing authentication, access prohibited) — retrying the same invalid request will produce the same error - D. Network wait times (timeout) **Q5. Why does streaming via Server-Sent Events (SSE) improve user experience?** - A. It reduces the number of tokens generated, therefore the total latency - B. It makes model generation faster on the supplier side - C. It compresses the response to save bandwidth - D. It displays the tokens over the generation: the total latency hardly changes, but the perceived latency collapses because the first word appears in less than a second **Q6. How does prompt caching allow savings of up to ~90% ⚠ on the hidden part?** - A. The supplier invoices at a very reduced rate for tokens at the start of the prompt that are identical from one request to another (system prompt, documents, tools) — hence the rule: stable content at the beginning, variable content at the end - B. The cache stores the complete answers, the model is never called again - C. Caching compresses tokens so that they count half as much - D. Caching only saves time, never money **Q7. What is model routing?** - A. Distribute network traffic between multiple data centers - B. Direct each request to the cheapest model capable of processing it: a small model for simple tasks (often the majority of traffic), a large model for difficult tasks - C.Change LLM provider each month depending on prices - D. Always use the most recent model **Q8. Why do we monitor latency in percentiles (p50, p95, p99) rather than on average?** - A. Percentiles are simpler to calculate than the average - B. The average is always higher than p99 - C. The average hides the tail of the distribution: a service can have a good average and a catastrophic p99 — but it is the users in the worst cases who complain. SLAs (Service Level Agreement) are written in percentiles - D. Monitoring tools cannot calculate an average **Q9. What does “prompts are code” mean in practice?** - A. Prompts must be written in a programming language - B. The prompts are versioned (Git), reread by peers and tested: with each PR (Pull Request, merge request) which modifies a prompt, a series of evaluations runs in CI/CD (Continuous Integration / Continuous Deployment) to detect regressions - C. Prompts must be compiled before being sent to the model - D. Only developers have the right to modify prompts **Q10. You must summarize 50,000 documents every night, without a human in front of the screen, with a supplier rate limit of 500 requests/minute ⚠. Which architecture to choose?** - A. Send all 50,000 requests at once and retry those that fail - B. A dedicated GPU (Graphics Processing Unit) instance, essential for this volume - C. A queue architecture: documents are placed in the queue, workers consume them at the rate limit, the results are stored for the morning - D. SSE streaming, so that summaries arrive faster **Q11. What is the *quantization* of a model, and what is it used for?** - A. Limit the number of requests per minute to stay under the rate limit - B. Reduce the **number of bits by weight** (e.g. FP16 → INT8 → INT4): the model occupies less memory and reads faster, at the cost of a slight loss of quality — it is “the JPEG of models” - C. Compress the prompt tokens so that they cost less to the API - D. Train a small model so that it becomes as good as a big one **Q12. You must self-host an open-weights model of 70 billion parameters (data sovereignty) on two 24 GB VRAM cards. In FP16 it weighs ≈ 140 GB. Which approach is the most reasonable?** - A. Impossible: you must go through a supplier's API - B. Load it as is in FP16: the 140 GB will fit on 48 GB of VRAM - C. Quantify it in **INT4 (Q4, format GGUF)**: it falls to ~40 GB, fits on both cards, with a generally minimal loss of quality (1–3 points ⚠) - D. Cut it into 70 small models of a billion parameters executed one after the other **Q13. In an enterprise AI architecture, what does Zero Data Retention (ZDR) really mean?** - A. The supplier does not charge for entry tokens - B. The provider does not keep the prompts/responses, and ideally not the usable metadata; this reduces exposure but does not replace a possessed environment - C. The model automatically forgets its weights after each query - D. The application no longer needs internal logs **Q14.For a workload containing critical trade secrets, which option provides the strongest structural assurance?** - A. Standard API with a contractual confidentiality clause - B. Cloud with ZDR, without further technical control - C. Owned and air-gapped environment, possibly with quantified open-weights model if self-hosting is required - D. Change supplier regularly to reduce dependence --- ## Correction grid | Question | Answer | Express reminder | |---|---|---| | Q1 | **B** | Production = the invisible 80%: auth, failures, latency, costs, observability, security, scale. | | Q2 | **C** | A client-side key is de facto public. Always an intermediate backend. | | Q3 | **B** | 429 → exponential backoff + jitter, respect `retry-after`. | | Q4 | **C** | 4xx “query” errors (400/401/403) are deterministic: retrying is pointless. | | Q5 | **D** | Streaming plays on *perceived* latency (first token), not total latency. | | Q6 | **A** | Cache = stable tokens from the start of the prompt at a reduced rate. Structure: stable first, variable then. | | Q7 | **B** | The right model for the right job — often the biggest savings lever. | | Q8 | **C** | The average lies; percentiles reveal actual worst-case experience. | | Q9 | **B** | Versioning, review, evaluations in CI: prompt regressions are detected before production. | | Q10 | **C** | Asynchronous massive load = queue + workers. Neither streaming nor GPU makes sense here. | | Q11 | **B** | Quantization = fewer bits/weight (FP16→INT8→INT4). Lighter + faster, slight loss of quality: the “JPEG of models”. | | Q12 | **C** | Q4 (GGUF) divides the footprint by ~4 (140→40 GB) for minimal loss — this is what makes self-hosting viable. | | Q13 | **B** | ZDR = no retention of prompts/responses, ideally metadata included. This is exposure reduction, not complete sovereignty. | | Q14 | **C** | The more sensitive the workload, the more structural the assurance must be: owned/isolated hardware > attested TEE > ZDR cloud > standard API. | **Recommended scale:** 1 point per question. ≥ 11/14: production-ready 🚀 · 8–10: solid, review missed points · ≤ 7: reread the guide and redo Exercise 1 before Session 9.