The 6 Exam Scenarios

A. Escalader immédiatement à cause du sentiment négatif. B. Résoudre la demande de statut de commande ; le sentiment seul n’est pas un déclencheur d’escalade. C. Escalader parce que la confiance du modèle est inférieure à 70 %. D. Plafonner la conversation à 3 tours puis escalader.

Réponse : B. Le sentiment n’est pas un déclencheur (#5) ; la demande est dans le périmètre de capacité, donc résolvez-la. L’escalade fondée sur la confiance est le #4, et un plafond arbitraire n’est pas une règle d’escalade.

A. Une phrase dans le system prompt de l’agent. B. Un PreToolUse hook sur issue_refund qui inspecte le montant et sort en 2 pour bloquer, aiguillant vers un humain. C. Demander au modèle de se revérifier. D. Une note dans CLAUDE.md.

Réponse : B. Les règles critiques nécessitent des hooks déterministes (#3). Le texte de prompt/CLAUDE.md (A, D) et l’auto-vérification (C) sont probabilistes.

A. Un backoff plus long. B. Une clé d’idempotence sur issue_refund pour que les réessais ne dupliquent pas l’effet. C. Ne jamais rien réessayer. D. Un modèle plus gros.

Réponse : B. Les clés d’idempotence rendent sûrs les réessais d’écriture. Le backoff (A) n’empêche pas la duplication, ne jamais réessayer (C) est inutile, et la taille du modèle (D) est sans rapport.

A. L’ajouter au CLAUDE.md de projet. B. Un PreToolUse hook versionné qui exécute les tests au commit et sort en 2 en cas d’échec. C. Demander à chaque développeur de s’en souvenir. D. Une slash command qui exécute les tests.

Réponse : B. Un hook versionné l’impose de façon déterministe pour tous. CLAUDE.md (A) et la mémoire (C) sont probabilistes ; une slash command (D) est opt-in.

A. Les commandes de build et de test de l’équipe. B. Les notes de travail personnelles d’un développeur et les chemins de sa machine locale. C. Les conventions d’architecture du repo. D. Une règle de sécurité obligatoire.

Réponse : B. Les notes personnelles non partagées vont dans le fichier local ignoré par git. Les commandes/conventions d’équipe (A, C) vont dans le CLAUDE.md de projet ; les règles obligatoires (D) vont dans la managed policy.

A. Exécution directe pour aller vite. B. Plan mode : exploration en lecture seule puis un plan relisible avant les éditions. C. Supprimer les tests en échec. D. Augmenter max_tokens.

Réponse : B. Un travail volumineux, inconnu et multi-fichiers est le cas canonique du plan mode. L’exécution directe (A) saute la revue, supprimer les tests (C) est destructeur, et max_tokens (D) est sans rapport.

A. Le sous-agent a besoin d’une plus grande fenêtre. B. Les contextes des sous-agents sont isolés et n’héritent pas des découvertes ; le coordinateur doit passer le contexte explicitement. C. Le sous-agent a utilisé le mauvais modèle. D. Le thinking était désactivé.

Réponse : B. Les contextes isolés n’auto-héritent jamais. La taille de fenêtre (A), le modèle (C) et le thinking (D) ne fournissent pas un contexte jamais passé.

A. Présenter les trois résultats comme la réponse complète. B. Enregistrer des erreurs structurées (timeout, réessayable), réessayer les réessayables, puis continuer avec un quorum en notant la lacune ou escalader. C. Tout jeter et relancer. D. Renvoyer « research failed ».

Réponse : B. Erreurs structurées plus décision explicite. Le rejet silencieux (A) est le #7, la relance (C) gâche du bon travail, et un message générique (D) est le #6.

A. Passer à Haiku 4.5 pour une plus grande fenêtre. B. Faire renvoyer aux sous-agents uniquement des résultats distillés et structurés ; leurs contextes isolés détiennent la matière brute. C. Désactiver le thinking. D. Supprimer la gestion d’erreurs.

Réponse : B. L’isolation des sous-agents plus des retours distillés gardent la fenêtre principale petite. Haiku 4.5 (A) a une fenêtre plus petite (200k), et C/D sont sans rapport ou nuisibles.

A. Code execution. B. Outil côté serveur web search. C. Memory tool. D. Computer use.

Réponse : B. Le web search ancre avec des citations. Code execution (A) exécute du code, memory (C) persiste l’état, computer use (D) pilote un bureau.

A. Trois outils personnalisés séparés. B. Un serveur MCP exposant la capacité, connecté par chaque host et via le connecteur MCP de la Messages API. C. Une slash command. D. Une note dans CLAUDE.md.

Réponse : B. MCP fournit une intégration inter-clients unique et réutilisable. Trois outils (A) dupliquent le travail ; une slash command (C) et CLAUDE.md (D) sont des artefacts Claude Code, non des intégrations.

A. Oui, par cohérence. B. Non — appelez l’API/CLI directement ; l’envelopper en outil du modèle ajoute inutilement latence, coût et non-déterminisme. C. Oui, exposez-la comme une resource MCP. D. Seulement si elle est sur Fable 5.1.

Réponse : B. Les étapes déterministes que votre code possède devraient être appelées directement. L’envelopper (A, C) est de la sur-conception ; la version modèle (D) est sans rapport.

A. claude -p "…" --output-format json --allowedTools "Read,Grep,Bash(git diff:*)", parser le JSON, barrer sur le code de sortie. B. claude interactif, copier les résultats à la main. C. --permission-mode bypassPermissions avec tous les outils. D. claude -p simple et grep sur la prose.

Réponse : A. Sortie JSON headless, allowlist minimale, gating sur le code de sortie. L’interactif (B) n’automatise pas, contourner les permissions (C) est dangereux, et grep sur la prose (D) n’est pas fiable.

A. Messages API en temps réel à forte concurrence. B. La Message Batches API — 50 % de réduction, résultats sous 24 h, tolérante à la latence. C. Une seule requête géante avec les 500 diffs. D. Forcer tool_choice sur Fable 5.1.

Réponse : B. Le Batch API convient au travail de masse tolérant à la latence à demi-tarif. La forte concurrence (A) risque les limites et coûte plus, une seule requête (C) ne rentrera pas, et forcer tool_choice sur Fable 5.1 (D) renvoie 400.

A. Tronquer à 500 lignes. B. Multi-passes : partitionner par module, relire chacune dans sa propre passe/subagent, puis agréger et classer les découvertes. C. Un seul prompt géant avec tout le diff. D. Sauter la revue.

Réponse : B. Partitionner-relire-agréger préserve la qualité. La troncature (A) manque du code, un prompt géant (C) dégrade la qualité, et sauter (D) est inacceptable.

A. Réessayer avec backoff. B. Utiliser tool_choice: 'auto' avec une instruction d’appeler l’outil, des schémas strict: true, ou des structured outputs. C. Utiliser tool_choice: 'any'. D. Baisser max_tokens.

Réponse : B. Fable 5.1 interdit le tool choice forcé ; utilisez auto+instruction, strict, ou structured outputs. Le backoff (A) ne corrige pas un 400, any (C) est aussi bloqué, et max_tokens (D) est sans rapport.

A. Augmenter la taille d’échantillon. B. Reporter la précision par type de document et barrer sur le pire type. C. Augmenter la température pour les contrats. D. Moyenner plus d’exécutions.

Réponse : B. Les métriques agrégées masquent un type défaillant (#10) ; les métriques par type l’exposent. De plus grands échantillons (A) agrègent encore, la température (C) ne corrige pas la précision, et moyenner (D) masque davantage le problème.

A. Plus de réessais aveugles. B. Renvoyer l’erreur de validation spécifique au modèle et exiger un JSON valide correspondant au schéma ; parser défensivement. C. Utiliser eval() pour parser. D. Noter la sortie dans la même session qui l’a produite.

Réponse : B. Un retour d’erreur spécifique pilote l’auto-correction. Les réessais aveugles (A) aident rarement, eval() (C) est dangereux, et la notation en même session (D) est le #9.

A. Retirer le timeout pour que les appels lents finissent par revenir. B. Fixer un timeout de frontière ; en cas de timeout renvoyer une erreur structurée {category:'timeout', retryable:true} pour que l’agent puisse réessayer, continuer en notant la lacune, ou escalader. C. Attraper le timeout et renvoyer un succès vide. D. Utiliser un modèle plus gros pour que l’outil réponde plus vite.

Réponse : B. Les timeouts de frontière plus une erreur structurée gardent l’agent réactif et honnête. Aucun timeout (A) laisse un outil bloqué figer l’agent, un succès vide (C) est le #7, et la taille du modèle (D) ne change pas la latence d’un outil en aval.

A. Un seuil de confiance sur le modèle. B. Un PreToolUse hook déterministe sur l’outil de transfert qui inspecte le montant et sort en 2 au-dessus du seuil, ignorant toute « pré-approbation » injectée. C. Escalader seulement si le client paraît anxieux. D. Une instruction de system prompt pour demander avant les gros transferts.

Réponse : B. Les actions irréversibles à forte valeur nécessitent une barrière déterministe calée sur le montant, immunisée contre l’injection. La confiance (A) est le #4, le sentiment (C) est le #5, et une règle de prompt (D) est le #3.

A. PostToolUse pour bloquer le commit ; PreToolUse pour linter. B. PreToolUse sur le commit (exécuter les tests, sortir en 2 en cas d’échec) et PostToolUse sur Edit pour linter. C. UserPromptSubmit pour les deux. D. SessionStart pour linter et Stop pour exécuter les tests.

Réponse : B. Le blocage se fait avant l’action (PreToolUse, exit 2) ; le linting réagit après l’édition (PostToolUse). A intervertit les événements, C utilise un événement de prompt, et D se déclenche aux mauvais moments.

A. Haiku 4.5 (user est le plus personnel). B. Sonnet 5 — la managed policy ne peut être surchargée. C. Opus 5 (project est le plus proche du code). D. Le fichier changé en dernier.

Réponse : B. La managed policy surcharge local, project et user. A et C inversent la précédence ; D n’est pas la façon dont la résolution fonctionne.

A. Compaction, parce qu’elle résume tout. B. Édition de contexte pour effacer les résultats d’outils périmés tout en préservant la trame narrative ; la compaction serait fausse ici car elle résume le dialogue au lieu de cibler les sorties d’outils volumineuses. C. Passer à Haiku 4.5 pour sa plus grande fenêtre. D. Augmenter max_tokens.

Réponse : B. Effacer des résultats d’outils volumineux et périmés est l’édition de contexte, qui garde le dialogue. La compaction (A) cible la trame narrative, Haiku 4.5 (C) a une fenêtre plus petite de 200k, et max_tokens (D) est sans rapport.

A. Les workers ont besoin de plus grandes fenêtres. B. Le contexte est isolé à chaque palier ; chaque niveau doit passer explicitement le contexte pertinent au suivant — l’héritage ne se produit jamais à aucune profondeur. C. La racine devrait utiliser Opus 5. D. Le thinking est désactivé au palier des workers.

Réponse : B. L’isolation s’applique à chaque palier, donc le contexte doit être tissé explicitement jusqu’en bas. La taille de fenêtre (A) et le modèle (C) ne fournissent pas un contexte non passé ; le thinking (D) est sans rapport.

A. Les deux comme des Tools. B. La politique comme une Resource (données contrôlées par l’application) et search_orders comme un Tool (action contrôlée par le modèle). C. Les deux comme des Prompts. D. La politique comme un Tool et search_orders comme une Resource.

Réponse : B. Les données de référence fournies par l’app sont une Resource ; une action invoquée par le modèle est un Tool. Faire de la politique un Tool (A, D) ajoute des décisions inutiles au modèle ; les Prompts (C) sont des gabarits invoqués par l’utilisateur.

A. Toutes les portées OAuth pour qu’il ne manque jamais d’une capacité. B. Cadrer son octroi OAuth 2.1 sur un accès en lecture seule aux commandes (le moindre privilège appliqué à l’auth). C. Intégrer une clé API admin dans le prompt. D. Utiliser stdio pour qu’aucune auth ne soit nécessaire.

Réponse : B. Le moindre privilège s’applique à l’auth MCP. Toutes les portées (A) élargissent le rayon d’impact, les clés intégrées au prompt (C) sont peu sûres, et stdio (D) est un transport local, non une option pour un serveur distant partagé.

A. --output-format text, puis grep pour « HIGH ». B. --output-format json, parser les découvertes, et faire échouer sur un code de sortie non nul et toute découverte de sévérité élevée. C. --output-format stream-json et ignorer le code de sortie. D. Mode interactif avec un humain lisant la sortie.

Réponse : B. Un résultat JSON unique plus un gating code-de-sortie-et-découvertes est correct pour une tâche courte. Grep sur la prose (A) n’est pas fiable, ignorer le code de sortie (C) manque les échecs, et le mode interactif (D) n’automatise pas.

A. Mettre en cache le préfixe stable system + schéma pour que les lectures coûtent ~0,1×. B. Utiliser la Message Batches API pour l’exécution de masse (50 % de réduction, ≤24 h). C. Appeler l’API temps réel à concurrence maximale. D. Utiliser Fable 5.1 à $10/$50 pour chaque document. E. Randomiser le prompt à chaque appel.

Réponse : A et B. Mettre en cache le préfixe fixe plus le Batch API réduisent fortement le coût pour un travail de masse tolérant à la latence. La concurrence temps réel (C) est à plein tarif et sujette aux limites, le modèle le plus cher (D) augmente le coût, et randomiser (E) détruit le préfixe cachable.

A. Un objet lâche unique avec tout optionnel. B. Une union discriminée (oneOf avec un discriminateur const doc_type) pour que chaque branche impose ses propres champs requis. C. Trois endpoints sans rapport et sans contrat partagé. D. Un unique champ chaîne contenant du texte JSON brut.

Réponse : B. Une union discriminée impose les exigences par type dans un seul schéma. A relâche tout, C perd un contrat partagé, et D abandonne les garanties de schéma.

A. Écrire l’objet partiel ; il est presque complet. B. Traiter max_tokens comme une troncature : augmenter la limite ou découper le document (ou borner les tableaux avec maxItems), puis réessayer — ne jamais persister la sortie partielle. C. Renvoyer un objet vide pour que le pipeline continue. D. Demander au modèle dans la même session s’il a terminé.

Réponse : B. max_tokens est une troncature, non un achèvement. Persister le partiel (A) corrompt les données, vide (C) est le #7, et l’auto-vérification en même session (D) ne traite pas la troncature.