# Mock exam — Advanced Level, Session 10 # “Mock exam & final project” **Program:** Applied AI — Yann Isola **Format:** 30 MCQs (MCQ = Multiple Choice Questionnaire), exam conditions — only one correct answer per question **Duration:** 45 minutes (i.e. 90 seconds per question, the actual pace of the exam ⚠) **Threshold:** 22/30 (≈ 72%, aligned with the certification threshold ⚠) **Weighting by domain (aligned with the official exam ⚠):** | Domain | Weight review ⚠ | Questions here | |---|---|---| | D1 — Agent architecture & orchestration | 27% | Q1–Q8 (8) | | D2 — Tool design & MCP integration | 18% | Q9–Q13 (5) | | D3 — Configuration & workflows Claude Code | 20% | Q14–Q19 (6) | | D4 — Prompt engineering & structured output | 20% | Q20–Q25 (6) | | D5 — Context management & reliability | 15% | Q26–Q30 (5) | > ⚠ **Volatility:** the exam format (60 questions, 90 minutes, threshold 720/1000 ≈ 72%), domain weightings and API behaviors described reflect the documentation at the time of writing. Check the official Anthropic certification page before booking the exam. > **Instructions for use:** take this mock exam **in real conditions** — timer started, no documentation, all questions answered (no penalty for a wrong answer). Then correct with the explanations, and report the score by domain in the preparation dashboard (session web page). --- ## Domain 1 — Agent architecture & orchestration (Q1–Q8) ### Q1 — Single agent or orchestrator? A fintech company builds a support assistant that must: (1) answer questions about fees, (2) analyze PDF statements for anomalies, (3) write regulatory complaint letters. Each capability requires a lengthy system prompt and different tools. A single agent begins to confuse the instructions. Which architectural evolution is most justified? - A. Merge the three prompt systems into one, more detailed, with XML sections - B. An orchestrator-router who classifies the request then delegates to three specialized agents, each with its own prompt and tools - C. Three instances of the same agent in parallel, with majority vote on the final response - D. Increase `max_tokens` and upgrade to the most powerful model available **Answer: B.** The symptom described — instructions which contaminate each other between heterogeneous capacities — is the canonical cutting signal. The orchestrator-router isolates each specialty: short and clean prompt, minimal tools, testability by agent. A worsens the contamination (even longer prompt). C (consensus) responds to a problem of reliability of the same task, not heterogeneity of tasks. D treats the symptom, not the cause: the power of the model does not replace the separation of responsibilities. --- ### Q2 — Context isolation of subagents A document retrieval agent launches 4 sub-agents in parallel, each exploring a different source, then synthesizes their reports. What is the **main** benefit of this architecture compared to a single agent which would explore the 4 sources sequentially? - A. The total token cost is always lower with subagents - B. Each sub-agent works in its own and isolated context; the orchestrator only receives the summaries, not the raw exploration tokens - C.Subagents can use different models, which is not possible otherwise - D. Parallelization guarantees deterministic results **Answer: B.** Context isolation is the central architectural benefit: the thousands of exploration tokens (pages read, dead ends, attempts) remain in the context of each sub-agent and never clutter that of the orchestrator, who reasons on dense syntheses. A is false — the total cost is often *higher* (4 contexts instead of one); we pay in tokens what we gain in quality and latency. This is false: a single agent can also call different models per request. D is false: parallelization does not provide any determinism. --- ### Q3 — Consensus pattern In which case is the pattern “N agents evaluate independently, then vote/aggregate” **best** justified? - A. To divide a long task into sequential steps - B. For a decision with high stakes and subjective criteria — p. ex. validate that a regulatory response does not contain any risky assertions — where an isolated error is costly - C. To reduce the latency of a simple task - D. To save tokens on high volume tasks **Answer: B.** The consensus multiplies the cost by N; it is only justified when the cost of an error greatly exceeds the additional cost of inference, typically high-stakes decisions with an element of judgment. Described workflow, not consensus. C and D are the opposite of reality: consensus increases latency and cost. --- ### Q4 — Router: classifier or agent? A router must direct each incoming ticket to one of 5 queues. Traffic is 80,000 tickets/day. Which implementation to favor? - A. A complete agent with tools and reasoning loop, for maximum flexibility - B. A single call, short prompt with definitions of the 5 classes + few-shot examples, constrained structured output, fast and economical model - C. A system of regex rules only, the AI being too expensive at this volume - D. A multi-agent orchestrator where each queue has its agent who “claims” the tickets **Answer: B.** Routing is a classification: closed, high-volume task, where latency and cost dominate. A simple call with constrained output on a fast model is the right tool. A is a classic exam anti-pattern: deploying an agentic loop where a call is enough. C throws the necessary semantic capacity (the tickets are in natural language). D is expensive and non-deterministic over-engineering. --- ### Q5 — Placement of the human in the loop A reimbursement management agent can: consult a file (read), calculate an amount (calculation), issue a transfer (irreversible action). Where to place the mandatory human validation? - A. Before each tool call, without exception — maximum safety - B. Only before the irreversible action (transfer), with an amount threshold beyond which approval is required - C. After the transfer, in the form of a posteriori audit - D. Nowhere: if the system prompt prohibits errors, validation is redundant **Answer: B.** The architectural principle: human friction is placed at the point of no return, proportionate to the risk (amount threshold). Destroyed the usefulness of the agent (each read validated by hand).It comes too late for irreversible action — the audit completes but does not replace approval. D confuses instruction and guarantee: a prompt is never a guarantee of execution; only the code (approval gate) is one. --- ### Q6 — Incident recovery in a parallel fan-out An orchestrator launches 6 sub-agents in parallel. Subagent #4 fails (timeout of an external tool). Which production strategy is the most robust? - A. Cancel the 6 branches and restart the whole thing from scratch - B. Silently ignore branch 4 and summarize on 5 results without mentioning it - C. Collect the 5 valid results, restart only branch 4 with backoff, and if the failure persists, synthesize by explicitly signaling the gap - D. Fail the entire user request with the raw timeout error **Answer: C.** Graceful degradation pattern: partial results preserved, targeted retry with backoff (backoff = increasing wait between attempts), and transparency on the gap if the failure persists — the summary says what it does not cover. A wastes 5 successes. B produces a falsely exhaustive synthesis: it is the worst choice in terms of reliability (invisible gap). D degrades the experience for a partial and recoverable failure. --- ### Q7 — Status and session resume (SDK Agent) An onboarding agent leads a 12-step process that can span several days. The user returns to step 7. Which approach is correct? - A. Replay the entire message history of steps 1–6 in context each time - B. Persist a structured state (current step, validated data, decisions taken) out of context, and rehydrate upon resuming a compact summary + the structured state - C. Rely on implicit model memory between two API calls - D. Ask the user to summarize for themselves where they were **Answer: B.** The durable state lives **outside** of the context (database, session store) in structured form; upon recovery, we reinject the minimum useful amount. A works but explodes in tokens and latency over the steps — and ends up saturating the window. This is a fundamental factual error: the API is stateless, the model does not “remember” anything between two calls. D externalizes to the user what the architecture must guarantee. --- ### Q8 — Workflow or agent? Among these four tasks, which justifies an **autonomous agentic loop** (the agent decides its next actions) rather than a workflow with fixed steps? - A. Extract the fields from an invoice and write them into a database — stable schema, known steps - B. Translate each new blog post into 3 languages, every day - C. Diagnose a failure whose cause is unknown, by exploring logs, metrics and code, where each clue determines the next investigation - D. Generate a weekly report from the same 4 data sources **Answer: C.** Decision rule: if the path is known in advance → workflow (deterministic, cheaper, testable); if the path depends on intermediate discoveries → agent. The breakdown diagnosis is the agent's textbook case: it is impossible to script the steps in advance. A, B, and D are fixed-stage pipelines — deploying an agent there is over-engineering that is punished by review. --- ## Domain 2 — Tool design & MCP integration (Q9–Q13) ### Q9 — The #1 tool selection leverAn agent has 12 tools and regularly chooses an unsuitable one. The JSON schemas of the parameters are correct. Which is the most effective correction lever first? - A. Upgrade to a more powerful model - B. Rewrite the **descriptions** of the tools: precise use cases, when to use it AND when not to use it, explicit distinctions between neighboring tools - C. Reduce the temperature to 0 - D. Add an additional “disambiguation” tool **Answer: B.** The tool description is the selection prompt: the model chooses based on descriptions, not implementations. Production quality descriptions include scope, contraindications (“do not use for…”) and distinctions between similar tools. It costs a lot to get around a specification defect. C reduces variance but not semantic confusion. D adds error surface instead of removing it. --- ### Q10 — MCP: tools, resources, prompts In MCP (MCP = Model Context Protocol, open protocol for connection between AI applications and external systems), a server exposes three primitives. What assignment is correct for an "internal knowledge base" server? - A. Tool = read a document; Resource = run a search; Prompt = the document itself - B. Tool = `rechercher(requête)` (parameter action, triggered by the model); Resource = content of a document identified by URI, loaded in the context; Prompt = reusable template “summarizes this document for a client” - C. Tool, resource and prompt are interchangeable — the choice is purely stylistic - D. Resource = any function with side effects; Tool = read-only data **Answer: B.** The canonical separation: **tools** = actions invokable by the model with parameters (search, write); **resources** = contents addressable by URI (URI = Uniform Resource Identifier) ​​that the application loads in the context, for reading; **prompts** = reusable interaction templates exposed to the user. D exactly reverse the first two. This is false: the three primitives have different control cycles (model / application / user). --- ### Q11 — Granularity of tools An internal MCP server exposes 22 tools, including `get_client_name`, `get_client_email`, `get_client_phone`, `get_client_address`… The agent multiplies calls and saturates its context. Which redesign is best? - A. Keep the 22 tools but document each one further - B. Consolidate into task-oriented tools — p. ex. `get_client_profile(client_id, champs?)` — which returns in one call what the agent consumed in four - C. Remove all tools and give the agent raw SQL access to the database - D. Create a unique, totally generic `do_anything(action, params)` tool **Answer: B.** Granularity is understood from the point of view of the **agent's task**, not the structure of the underlying API: one tool = one intention. Consolidation reduces back and forth, tokens, and opportunities for error. A does not solve the structural problem. C trades off over-granularity for a risk of data injection and destruction. D destroys the value of the typed schema: the model no longer has any guidance on possible actions. --- ### Q12 — Choice of MCP transport A team is hesitating between stdio transport and HTTP (streamable) transport for its MCP servers. Which statement is correct? - HAS.stdio is suitable for local servers launched as a subprocess of the host application; HTTP is suitable for remote, shared servers with authentication - B. HTTP is always preferable because it is more modern - C. stdio allows sharing of the same server between several remote machines - D. The transport modifies the available primitives: the resources only exist in HTTP **Answer: A.** stdio (stdio = standard input/output): local server, subprocess, minimal latency, security by local isolation — perfect for workstation tooling. Streamable HTTP: remote server, shared between clients, with authentication layer (e.g. OAuth) — perfect for business. B is a fashion reflex, not an architect's. This is false by definition of stdio. D is false: MCP primitives are transport independent. ⚠ The exact names of transports evolve with the MCP specification — check the current version. --- ### Q13 — Tool errors: who should see them? A `reserver_salle` tool fails because the room is already taken. What design allows the agent to **recover** instead of failing? - A. Throw an exception on the server side: the API call fails and the application displays a 500 error - B. Return to the agent a tool result marked as error, with an actionable message — “Room B occupied from 2 p.m. to 3 p.m.; rooms A and C free in this slot” — so that he can adjust his strategy - C. Return an empty string so as not to disrupt the model - D. Return `succès: true` with an internal note, so that the conversation remains fluid **Answer: B.** The tool error is **reasoning data**: returned in the result (error field or `is_error`), formulated in an actionable way, it allows the agent to reschedule (propose room A). Transforms a recoverable business hazard into a technical failure. C lets the model hallucinate a success or a cause. D is the worst case: lying to the model guarantees a final confidently false answer. --- ## Domain 3 — Configuration & workflows Claude Code (Q14–Q19) ### Q14 — Role of CLAUDE.md What should the `CLAUDE.md` file contain at the root of a repository for a team of 12 developers? - A. The complete user documentation of the product - B. Conventions not deducible from the code: exact build/test commands, team style and prohibitions, folder architecture, known repository pitfalls - C. A copy of the README intended for humans - D. The history of sprint decisions **Answer: B.** `CLAUDE.md` is automatically loaded into the context at each session: each line costs tokens at each interaction. We put the **operational contract** there that the agent cannot guess by reading the code — exact commands (`make test-unit`, not “run the tests”), conventions, dangerous zones. A and D dilute the signal and inflate the cost. C duplicates a document written for another audience with another level of detail. --- ### Q15 — Headless mode in CI In a CI pipeline (CI = Continuous Integration), which invocation is correct for a non-interactive automatic review whose output will be parsed by a script? - A. `claude` in interactive mode, with a developer answering questions - B. `claude -p "Analyse ce diff et liste les problèmes" --output-format json` with explicitly bounded tool permissions for the CI environment - C.`claude --dangerously-skip-permissions` systematically, to avoid any blocking - D. Copy the diff into the web interface and paste the response into the pipeline **Answer: B.** Headless mode (`-p` / `--print`) executes a single query without interaction; `--output-format json` makes the output reliably pipeline-parsable; and in CI, permissions are explicitly declared (tool allowlist) rather than being granted in bulk. This is the recurring security trap: bypassing all permissions in an automated environment that can execute arbitrary code. ⚠ CLI flags are changing — check `claude --help` on the installed version. --- ### Q16 — Slash commands vs CLAUDE.md Which information belongs to a **slash command** (file in `.claude/commands/`) rather than `CLAUDE.md`? - A. The branch naming convention, permanently useful - B. An on-demand and configurable procedure — p. ex. `/release-notes v2.3` which generates version notes according to a precise template - C. The command to launch unit tests - D. The list of folders to never modify **Answer: B.** Sorting criterion: what must be **known at all times** goes into `CLAUDE.md` (loaded at each session); what is **invoked on demand** with arguments goes into a slash command (loaded only on call — zero cost the rest of the time). A, C and D are permanent knowledge → `CLAUDE.md`. B is a one-time parameterized ritual → slash command. --- ### Q17 — Outline mode In which case does the plan mode of Claude Code (exploration and proposal **without modification** of files) provide the most value? - A. Correct a typo in a comment - B. A refactoring that affects 14 files and a database schema migration, where we want to validate the complete approach before the first write - C. Add a unit test to an existing tests file - D. Rename a local variable in a function **Answer: B.** The plan mode separates the decision from the execution: the agent explores the code, proposes a complete plan, and the human arbitrates **before** any writing. Its value increases with the scale and irreversibility of the change (multi-files, migration). A, C, D are trivial and local modifications where the plan mode adds friction without benefit. --- ### Q18 — Team permissions A team wants Claude Code, on the shared repository, to always be able to run tests and linter, but never `git push` without validation. Which mechanism is the right one? - A. Say it in `CLAUDE.md`: “Never push without asking” - B. A versioned shared permissions file in the repository (`.claude/settings.json`) with explicit allowlist (test commands, lint) and approval requirement for the rest - C. Each developer configures their local permissions to their convenience - D. Ban the Bash tool completely **Answer: B.** Cardinal distinction of the examination: `CLAUDE.md` = **instruction** (the model can forget it or bypass it); permissions configuration = **guarantee** (enforced by the program, not by the model). Versioning `settings.json` in the repository makes the policy uniform and auditable for the entire team. Confused deposit and guarantee. C produces 12 divergent policies. D destroys the main use (running the tests) to avoid a finely manageable case. --- ### Q19 — PR review automationFor an automatic review of each PR (PR = Pull Request, code merger proposal), which integration is most suitable? - A. A developer launches Claude Code interactively on each PR and copies its conclusions - B. A CI job triggered when the PR is opened: headless mode, context = diff + description of the PR + review instructions, structured output posted as a comment, read-only permissions - C. Give the agent the right to automatically merge the PRs it deems good - D. Have the entire filing reread at each PR for maximum context **Answer: B.** The canonical pattern: event triggering, non-interactive mode, targeted context (the diff, not the entire repository), exploitable structured output, and **read only** — the review informs, the human decides. A does not scale. C crosses the red line of irreversible action without humans. D explodes the context and the cost for marginal gain: the diff and its surroundings are enough for the review. --- ## Domain 4 — Prompt engineering & structured exit (Q20–Q25) ### Q20 — Prefilling + stop_sequences You end the query with the message `{"role": "assistant", "content": ""}` and pass `stop_sequences: [""]`. The model generates “compliant and I specify…”. What does your application receive in the response text? - A.`conforme` - B. `conforme` — with `stop_reason: "stop_sequence"` - C.`conforme et je précise…` - D. `conforme` — with `stop_reason: "end_turn"` **Answer: B.** Two API behaviors to know by heart: (1) the prefill text (prefilling of the start of the response) is **not repeated** in the output — the generation continues after it; (2) the triggered shutdown sequence is **not included** in the returned text, and everything that followed is cut off; `stop_reason` is `"stop_sequence"`. Result: the application receives exactly the useful value, without tags or chatter. This is the canonical deterministic extraction pattern. ⚠ Volatile behavior: check current API documentation. --- ### Q21 — Counterproductive Chain of Thought On which task is adding step-by-step reasoning (CoT) likely to **degrade** performance? - A. A depreciation plan calculation in 6 steps - B. The verbatim copy of a contract number from a document to a JSON field - C. A differential diagnosis between three possible causes of failure - D. Planning a migration in several phases **Answer: B.** The CoT helps with tasks where the answer *results* from intermediate steps (A, C, D). On a verbatim copy, the “think” stage invites the model to rephrase, standardize, or paraphrase — exactly what we don’t want. Architect's reflex: the CoT is a measurable tool, not a reflex; it is activated when the evaluation shows a gain. --- ### Q22 — Ensure schema-compliant JSON Your downstream pipeline crashes at the slightest invalid JSON. Which approach gives the **strongest guarantee** of structural compliance? - A. Write “ONLY respond in valid JSON” in capital letters in the prompt - B. Define the expected structure as a tool with JSON schema (input_schema) and force its call (tool_choice): the generated arguments are constrained by the schema; then validate on the code side - C. Add 10 few-shot examples of well-formed JSON -D.Reread the output with a second LLM call which corrects the JSON **Answer: B.** The use of a tool as a structured output “mold” is the most restrictive mechanism offered by the API: the generation of arguments is guided by the schema (types, required fields, enumerations), and `tool_choice` forces the call. Downstream programmatic validation remains mandatory (belt + suspenders guarantee). A and C improve the probability without guarantee. D adds cost and latency and can introduce new errors. ⚠ Structured output mechanisms are evolving quickly — check common API options. --- ### Q23 — Composition of a few-shot game With a budget of 5 few-shot examples for a conformance classifier, which composition is the most effective? - A. 5 perfect nominal cases of the most frequent case - B. 1 nominal case, 3 ambiguous borderline cases decided with justification, 1 case outside the scope showing the expected refusal - C. 5 cases randomly chosen from the production data - D. 5 variations of the same example with different formulations **Answer: B.** The few-shot examples teach the **decision boundaries**, not the center of the distribution: the model already handles easy cases well. The clear-cut borderline cases show where the line passes; the case of refusal defines the perimeter. A and D waste the budget on what is already acquired. C leaves the composition to chance — the selection of examples is a design decision, not sampling. --- ### Q24 — Long context: placement You submit an 80-page contract and a specific question. What organization of the prompt maximizes response quality? - A. Question first, then document, so the model knows what to look for - B. The long document at the top of the prompt (ideally in structuring tags), the question **at the end**, and first ask the model to extract the relevant quotes before answering - C. Divide the contract into 40 successive user messages - D. Put the contract in the system prompt and the question in the user message, the internal order having no effect **Answer: B.** Three long context best practices combined: large documents at the **top** of the prompt, query at the **end** (final instructions are best followed after a long context), and citation anchoring ("cites relevant passages first") forces the model to rely on the actual text before concluding. Reverses the optimal placement. C fragments without benefit. D is false: position in context has a measurable effect. --- ### Q25 — Design an assessment harness To continuously evaluate a biller data extraction pipeline, which harness is best designed? - A. A golden set of 50 annotated invoices, programmatic verifications field by field (exact equality, numerical tolerances), automatic execution at each change of prompt, tracking of scores over time - B. Ask an LLM every week “does this pipeline look good to you?” » - C. Manually test 3 invoices after each modification - D. Measure only latency and cost, quality being subjective**Answer: A.** The four pillars of a harness: annotated and versioned reference set, **programmatic** metrics when the ground truth is objective (the extraction is: an amount is right or wrong), automation (the evaluation runs like a CI test), and history (detecting regressions). The LLM-judge (B) reserves himself for subjective qualities (tone, usefulness) — and calibrates himself against human judgments. C has no coverage or reproducibility. D measures everything except what matters. --- ## Domain 5 — Context management & reliability (Q26–Q30) ### Q26 — Long agent: manage context saturation An analysis agent has been running for 2 hours; its context approaches the limit. Which production strategy is most suitable? - A. Let the API silently truncate the oldest messages - B. Compact: synthesize the history into a structured summary (decisions taken, current state, remaining tasks), persist the details out of context, and start again on a fresh context containing the summary - C. Stop the agent and start from the beginning - D. Randomly delete every other message **Answer: B.** Compaction is the standard pattern for long-running agents: context is a managed resource, not an infinite log. The summary retains the decision-making essentials; raw details remain accessible out of context (files, database) if necessary. A loses information without control over *which*. C throws 2 hours of work. D is a caricature of A. --- ### Q27 — Prompt caching: invalidation Your application uses the prompt cache (prompt caching: paid reuse at a reduced price ⚠ of the prompt prefixes already processed). What modification **invalidates** the cache of a marked prefix? - A. Change a word in the system prompt, located before the cache point - B. Add new user message after cached prefix - C. Reuse the same prefix within 5 minutes ⚠ - D. Send the same request from another machine on the same account **Answer: A.** The cache works by **exact prefix**: any modification upstream of the cache point (a word, a tool, an order of blocks) changes the prefix, therefore invalidates the cache. B is precisely the intended use: the stable prefix is ​​reused, only the sequence varies. C describes the typical freshness window (≈5 minutes⚠, recharged on each access), not an invalidation. D does not invalidate: the cache is attached to the account/prefix, not to the machine. Architectural consequence: **stable content at the head** (system, tools, documents), **variable content at the tail**. ⚠ Volatile durations and prices. --- ### Q28 — Reduce hallucinations in the RAG system A documentary assistant (RAG — Retrieval-Augmented Generation) sometimes invents references. What combination of measures is most effective? - A. Lower the temperature to 0 — this eliminates hallucinations - B. Explicitly allow "I don't know" when documents do not cover the question, require citations from the documents provided, and programmatically verify that each citation exists in the sources - C. Add “Never hallucinate” in the system prompt - D. Increase the number of documents retrieved for each request**Answer: B.** Triple defense: the **way out** (allowing admission of ignorance reduces the pressure to invent), **anchoring** (required citations from sources), and **programmatic verification** (a non-existent citation is detectable by code — it's a guarantee, not a directive). Reduced the variance, not the invention: a hallucination at temperature 0 is simply reproducible. It is an instruction without a mechanism. D can make it worse (more noise, diluted context). --- ### Q29 — API error resilience Your service receives errors 429 (rate limit) and 529 (overload ⚠) during peak hours. Which customer strategy is correct? - A. Try again immediately in a tight loop until success - B. Retry with exponential backoff and jitter (jitter = randomness added to delays to desynchronize clients), retry ceiling, respect for the `retry-after` header if present, and upstream queue to smooth out peaks - C. Permanently switch all requests to another provider at first 429 - D. Increase the customer timeout to 10 minutes **Answer: B.** The complete resilience pattern: exponential backoff (immediate retries aggravate congestion - A is a self-inflicted denial of service), jitter against the herd effect, ceiling to avoid endless looping, respect for server indications, and upstream traffic smoothing. This is a disproportionate strategic decision for a transitional and normal phenomenon. D confuses slowness and refusal: a 429 responds quickly, extending the timeout changes nothing. --- ### Q30 — Traceability and provenance in production For an AI system subject to regulatory audit, what minimum must be logged to reconstruct **why** the system produced a given response? - A. Only the final response sent to the user - B. For each request: prompt version identifier, exact model and parameters, context provided (or its fingerprint + reference), tools called with arguments and results, response produced, timestamp — with protected personal data (minimization, bounded retention) - C. All raw network traffic, indefinitely - D. Nothing: the outputs of a model are not reproducible, the audit is therefore impossible **Answer: B.** Provenance requires being able to replay the causal chain: what prompt (versioned), what model, what context, what tool actions, what output. Without the prompt version and entries, an incident is undiagnosable. Data protection applies to the logs themselves (PII — Personally Identifiable Information — minimized, encrypted, purged when due). A does not allow any causal diagnosis. This is ultimately illegal (unlimited retention of personal data) and unusable. D confuses bit by bit reproducibility and traceability: we can always trace what was provided and decided. --- ## Quick correction grid| Q | R | Domain | | Q | R | Domain | | Q | R | Domain | |---|---|---|---|---|---|---|---|---|---|---| | 1 | B | D1 | | 11 | B | D2 | | 21 | B | D4 | | 2 | B | D1 | | 12 | A | D2 | | 22 | B | D4 | | 3 | B | D1 | | 13 | B | D2 | | 23 | B | D4 | | 4 | B | D1 | | 14 | B | D3 | | 24 | B | D4 | | 5 | B | D1 | | 15 | B | D3 | | 25 | A | D4 | | 6 | C | D1 | | 16 | B | D3 | | 26 | B | D5 | | 7 | B | D1 | | 17 | B | D3 | | 27 | A | D5 | | 8 | C | D1 | | 18 | B | D3 | | 28 | B | D5 | | 9 | B | D2 | | 19 | B | D3 | | 29 | B | D5 | | 10 | B | D2 | | 20 | B | D4 | | 30 | B | D5 | > **Pedagogical note (trainer):** the correct answer is often deliberately in position B in this correction document — in the real exam, the positions are random. The session's web simulator **mixes the proposals** at each attempt: use the simulator for training, this document for the commented correction. ## Score interpretation | Score | Diagnosis | Action | |---|---|---| | 27–30 | Ready. | Book the exam. Review only areas < 80%. | | 22–26 | At threshold — insufficient margin. | One week of revision targeted on the 2 weakest areas, then second mock exam. | | 17–21 | Foundations present, significant differences. | Resume sessions corresponding to domains < 60%; redo the practical exercises (not just the reading). | | <17 | Do not book the exam. | Resume the course from weak sessions; practice with real API calls — practice beats reading. | **Calculation by domain:** domain score = correct questions ÷ domain questions. Any domain < 60% is a red zone, regardless of the overall score — the actual exam weights, and a collapsed domain can cost certification.