CCDV-F – Examen blanc 2

Voici un deuxième examen blanc CCDV-F complet avec 53 items entièrement inédits — aucun ne reprend l’Examen blanc 1 ni les questions des pages de domaine. Il est calibré un peu plus difficile que l’Examen 1 : plus de scénarios à contraintes multiples, plus de qualificatifs FIRST / MOST cost-effective / TWO, et des distracteurs individuellement plausibles jusqu’à ce que vous appliquiez la contrainte déterminante. La répartition suit exactement le blueprint, si bien que votre score par domaine ici est un signal réaliste de préparation à la réservation.

Consignes

53 items · 120 minutes. Comptez environ 2 minutes par item ; marquez les items difficiles et revenez-y.
La notation est mise à l’échelle 100–1000, réussite à 720. Comme heuristique d’étude, visez ≥ 80 % en brut (≈ 43/53) avant de réserver.
Les items sont à choix multiple (sélectionnez une réponse) ou à réponses multiples (sélectionnez deux réponses — l’item le précise). Il n’y a pas de pénalité pour les mauvaises réponses, alors répondez à tout.
Surveillez les qualificatifs : FIRST demande la première action correcte, MOST cost-effective classe selon le coût compte tenu des contraintes, et TWO signifie exactement deux bonnes options.

Répartition par domaine

Domaine	Poids	Items ici
D1 · Applications and Integration	33,1 %	18
D2 · Model Selection and Optimization	16,8 %	9
D3 · Agents and Workflows	14,7 %	9
D4 · Prompt and Context Engineering	11,0 %	6
D5 · Tools and MCPs	10,6 %	5
D6 · Security and Safety	8,1 %	4
D7 · Claude Code	3,1 %	1
D8 · Eval, Testing and Debugging	2,6 %	1

Comment utiliser les deux examens

Passez d’abord l’Examen blanc 1. Utilisez-le comme diagnostic pour repérer les domaines faibles, puis réétudiez ces pages de domaine avant de revenir.
Utilisez l’Examen blanc 2 comme feu vert avant réservation. Ses énoncés plus difficiles à contraintes multiples se rapprochent de la pression de l’examen réel. Obtenez ≥ 80 % en brut ici, sans qu’un seul domaine lourd (D1/D2/D3) soit nettement à la traîne, avant de réserver.
Comparez les résultats par domaine entre les deux examens. Un domaine solide à l’Examen 1 mais faible à l’Examen 2 signifie généralement que vous avez appris les faits à restituer mais pas le raisonnement à contraintes multiples — revenez à l’étude de cas et au tableau des idées reçues de ce domaine.

Interprétation du score

Score brut (sur 53)	Lecture
≥ 47 (≈ 89 %)	Solide — confortablement au-dessus du seuil de réussite probable, même sur des items plus difficiles
43–46 (≈ 81–87 %)	Sur la bonne voie — réservez une fois qu’aucun domaine lourd n’est à la traîne
38–42 (≈ 72–79 %)	Limite — revoyez les domaines faibles, surtout D1/D2/D3
moins de 38 (moins de 72 %)	Pas prêt — réétudiez les domaines lourds et retestez

Passer l’examen blanc

Le mode interactif déroule une session chronométrée une question à la fois et se termine par votre score, une ventilation par domaine et un corrigé complet ; le mode révision en dessous liste chaque question avec ses options et la réponse masquée jusqu’à ce que vous la demandiez.

Mode interactif

Passer l’examen d’entraînement

53 questions · une à la fois · compte à rebours de 120 minutes · résultats avec répartition par domaine et correction complète à la fin. Votre progression est enregistrée dans ce navigateur si vous quittez la page.

Limite de temps Mélanger l’ordre des questions

CCDV-FExamen d’entraînement

Question 1 sur 53

--:--

Toutes les questions (mode révision)

Les options sont présentées une par ligne. La réponse et l’explication restent masquées jusqu’à ce que vous cliquiez sur Afficher la réponse. Utilisez le mode interactif ci-dessus pour une session chronométrée.

Q1D1 · Applications et intégrationSélectionnez une réponse
Une intégration de production diffuse les réponses en streaming et doit (a) afficher le texte au fur et à mesure et (b) enregistrer le stop_reason final et la consommation de tokens pour la facturation. Quel traitement SSE est correct ?
- A. Lire text_delta depuis content_block_delta pour l’affichage, et lire stop_reason et l’usage final depuis l’événement message_delta.
- B. Tout lire depuis message_start, qui contient le texte complet et l’usage final.
- C. Accumuler les événements content_block_start ; stop_reason se trouve sur message_stop.
- D. Seul message_stop transporte le texte, l’usage et stop_reason.
Afficher la réponse
Réponse : A.
Le texte est diffusé en tant que text_delta à l’intérieur de content_block_delta ; le stop_reason final et l’usage arrivent sur message_delta (avant message_stop). B relève de la simple mémorisation et est faux : message_start n’a pas d’usage final. C place stop_reason à tort sur message_stop. D relève de la pensée « échec silencieux » : message_stop termine simplement le flux et ne transporte aucun texte.
Q2D1 · Applications et intégrationSélectionnez une réponse
Une boucle d’usage d’outils ajoute les blocs tool_use de l’assistant et les blocs tool_result, mais renvoie par intermittence 400 invalid_request. Les journaux montrent des tours occasionnels où un tool_result manque pour l’un des deux blocs tool_use parallèles. Quel est le FIRST correctif ?
- A. Renvoyer exactement un tool_result par bloc tool_use, tous dans le même tour user suivant, chacun rattaché à son tool_use_id.
- B. Réessayer le 400 avec un backoff exponentiel et du jitter.
- C. Baisser temperature pour que Claude émette moins d’appels d’outils parallèles.
- D. Régler disable_parallel_tool_use: true de façon permanente pour éviter le problème.
Afficher la réponse
Réponse : A.
Chaque bloc tool_use a besoin d’un tool_result correspondant (même id) dans le tour user suivant ; un manquant provoque le 400. A corrige la cause racine. B est faux car un 400 est déterministe, pas transitoire. C (température) ne garantit pas des appels sériels et relève de la pensée « prompt-comme-application ». D sur-conçoit en supprimant une capacité valide au lieu de renvoyer tous les résultats.
Q3D1 · Applications et intégrationSélectionnez deux réponses
Un service réutilise un préfixe système+schéma de 30 000 tokens sur Sonnet 5, sur environ 500 appels/heure, chacun avec une courte question unique. Les coûts sont dominés par les tokens d’entrée. Quelles DEUX modifications réduisent le PLUS le coût d’entrée tout en gardant la qualité de sortie inchangée ?
- A. Placer le préfixe stable en premier et marquer sa fin avec cache_control pour qu’il soit écrit une fois puis lu à environ 0,1× ensuite.
- B. Réutiliser le préfixe mis en cache identique à chaque appel dans la TTL.
- C. Régler temperature: 0.
- D. Augmenter max_tokens pour réduire les réessais dus à la troncature.
- E. Déplacer le préfixe après la question de l’utilisateur pour qu’il se mette mieux en cache.
Afficher la réponse
Réponse : A et B.
Mettre en cache un préfixe stable et le réutiliser dans la TTL fait tomber le coût du préfixe à environ 10 % lors des hits. A et B sont les leviers. C (température) et D (max_tokens) n’affectent pas le coût du cache d’entrée. E est faux : le préfixe cacheable doit venir en premier ; le placer après la question variable empêche les hits de cache.
Q4D1 · Applications et intégrationSélectionnez une réponse
Un worker appelle le SDK dans un asyncio.gather serré sur 5 000 éléments et commence à voir de nombreuses réponses 429 avec un en-tête retry-after. Quelle modification est la MOST cost-effective et correcte pour cette charge tolérante à la latence ?
- A. Déplacer les 5 000 éléments vers la Message Batches API (remise de 50 %, résultats sous 24 h) au lieu d’une concurrence artisanale.
- B. Ignorer retry-after et réessayer immédiatement dans une boucle plus serrée.
- C. Alterner entre plusieurs clés API pour multiplier la limite du compte.
- D. Basculer chaque appel sur Opus 5 pour réduire le nombre de réessais.
Afficher la réponse
Réponse : A.
Un traitement en masse tolérant à la latence a sa place sur la Batches API : moitié du coût et pas de tempête de limites de débit auto-infligée. A est correct. B ignore retry-after et aggrave la limite. C est aveugle à la contrainte : les limites de compte ne se multiplient pas par les clés et cela peut enfreindre les conditions. D sur-conçoit avec un modèle plus coûteux qui ne traite pas les limites de débit.
Q5D1 · Applications et intégrationSélectionnez une réponse
Avec le thinking adaptatif activé sur Opus 5, le code lit response.content[0].text et lève une AttributeError sur certaines réponses mais pas d’autres. Quelle est la cause racine et le traitement correct ?
- A. content[0] est parfois un bloc thinking (ou tool_use) ; parcourez content et concaténez les blocs où type == 'text'.
- B. Le thinking désactive aléatoirement la sortie texte ; désactivez le thinking pour stabiliser.
- C. Le content de la réponse est parfois une simple chaîne ; appelez .strip() d’abord.
- D. Le texte n’apparaît qu’en streaming ; passez au streaming.
Afficher la réponse
Réponse : A.
Quand le thinking ou les outils sont actifs, le premier bloc de contenu peut être thinking ou tool_use, donc l’index 0 n’est pas toujours du texte. A parcourt et filtre par type. B est faux : le thinking ne supprime pas le texte et le désactiver est de la sur-ingénierie. C se trompe sur la forme (le contenu est un tableau typé, pas une chaîne). D est sans rapport avec la forme de la réponse.
Q6D1 · Applications et intégrationSélectionnez une réponse
Une entreprise doit conserver toute l’inférence dans son projet Google Cloud, sous ses contrôles IAM et VPC existants. Quel client et quelle configuration sont appropriés ?
- A. AnthropicVertex sur Google Vertex AI, avec des model IDs Vertex et une portée régionale.
- B. AnthropicBedrock avec AWS SigV4.
- C. Le client Anthropic par défaut avec la clé API stockée dans Google Secret Manager.
- D. claude.ai avec le SSO Google activé.
Afficher la réponse
Réponse : A.
Vertex maintient l’inférence dans le projet GCP du client, sous IAM. A est correct. B est sur AWS, le mauvais cloud. C est aveugle à la contrainte : stocker la clé dans Secret Manager appelle toujours l’API Anthropic externe, ce qui sort de GCP. D est une surface grand public, pas une voie programmatique dans le compte.
Q7D1 · Applications et intégrationSélectionnez une réponse
Un lot de 20 000 requêtes est créé et le code appelle immédiatement results(), qui ne renvoie rien, si bien qu’il recrée le lot et double la dépense. Quel est le cycle de vie correct ?
- A. Interroger processing_status jusqu’à ended, puis streamer results() et faire correspondre chaque élément par custom_id ; utiliser une clé d’idempotence à la création pour éviter les doublons.
- B. Les batches sont synchrones ; un résultat vide signifie que le lot a échoué, donc recréez-le.
- C. Appeler results() dans une boucle serrée sans délai jusqu’à l’apparition des données.
- D. Les batches ne renvoient des résultats que sur Opus 5 ; changez de modèle et réessayez.
Afficher la réponse
Réponse : A.
Les batches sont asynchrones : interrogez jusqu’à ended, puis lisez les résultats rattachés par custom_id, et utilisez l’idempotence à la création. A est correct. B est faux (les batches ne sont pas synchrones ; recréer duplique le travail). C martèle l’API sans raison. D invente une contrainte de modèle inexistante.
Q8D1 · Applications et intégrationSélectionnez une réponse
Une réponse renvoie stop_reason: 'refusal'. Le code actuel l’attrape dans un except générique, journalise « API error » et réessaie avec un backoff. Qu’est-ce qui ne va pas et que devrait-il se passer ?
- A. refusal est un refus de sûreté, pas une erreur ; routez-le vers une voie de politique/humaine et faites remonter le contexte de diagnostic — ne réessayez pas aveuglément.
- B. refusal est transitoire ; le réessai avec backoff est correct.
- C. refusal signifie que la sortie a été tronquée ; augmentez max_tokens et réessayez.
- D. refusal signifie qu’un outil a été demandé ; exécutez l’outil.
Afficher la réponse
Réponse : A.
refusal est un stop reason de sûreté délibéré et doit être traité par politique, pas réessayé. A est correct et corrige aussi l’anti-pattern de l’erreur générique. B réessaie aveuglément un signal non transitoire. C le confond avec max_tokens. D le confond avec tool_use.
Q9D1 · Applications et intégrationSélectionnez deux réponses
Une équipe durcit une nouvelle intégration avant la production. Quelles DEUX pratiques relèvent de l’étape de durcissement plutôt que de la formulation du prompt ?
- A. Réessayer 429/5xx/529 avec un backoff exponentiel + jitter, en respectant retry-after.
- B. Valider la sortie structurée par rapport à un schéma et réessayer avec l’erreur en cas d’échec.
- C. Rendre la réponse plus amicale de ton.
- D. Ajouter plus d’emoji au prompt système.
- E. Demander au modèle de revérifier son propre travail dans le même appel.
Afficher la réponse
Réponse : A et B.
Le durcissement concerne la fiabilité : backoff sur les erreurs transitoires et validation-réessai de schéma. A et B sont corrects. C et D sont des ajustements cosmétiques du prompt, pas du durcissement. E est de l’auto-évaluation en même session, un anti-pattern qui ne durcit pas l’intégration.
Q10D1 · Applications et intégrationSélectionnez une réponse
Un contrat PDF de 180 pages est réutilisé sur des dizaines de requêtes d’extraction par jour. Les octets base64 sont renvoyés à chaque appel, dominant la bande passante et la latence. Quelle est la MOST cost-effective méthode d’entrée ?
- A. Téléverser le PDF une seule fois via la Files API et le référencer par file_id dans chaque requête.
- B. Extraire le texte localement et le coller dans chaque prompt.
- C. Convertir chaque page en image et envoyer les images à chaque appel.
- D. Continuer d’envoyer du base64 mais activer le streaming.
Afficher la réponse
Réponse : A.
La Files API téléverse une seule fois et référence par file_id, éliminant les envois répétés. A est correct. B renvoie encore un texte volumineux à chaque appel. C est encore plus lourd (images par page à chaque fois). D (streaming) affecte la livraison, pas le coût d’envoi répété.
Q11D1 · Applications et intégrationSélectionnez une réponse
Une couche de cache marque un préfixe de 12 000 tokens avec cache_control, mais le taux de hits de cache est proche de zéro. L’inspection montre que le prompt système intègre l’horodatage UTC courant. Quelle affirmation est correcte ?
- A. Tout changement d’octet dans le préfixe (l’horodatage) invalide le cache ; déplacez les valeurs par requête après le point de rupture de cache pour que le préfixe reste identique au bit près.
- B. Le cache est désactivé sur les préfixes de plus de 10 000 tokens.
- C. Le préfixe est trop court pour être mis en cache ; rembourrez-le à 16 000 tokens.
- D. Passez la TTL à 1 heure et l’horodatage sera ignoré.
Afficher la réponse
Réponse : A.
Un hit de cache exige un préfixe identique au bit près ; un horodatage par requête le change à chaque appel. A corrige en gardant le contenu variable après le point de rupture. B invente un plafond de taille. C fait un mauvais diagnostic (12k est au-dessus du minimum d’environ 1024). D est faux : une TTL plus longue exige toujours des octets identiques pour faire un hit.
Q12D1 · Applications et intégrationSélectionnez une réponse
Sous charge soutenue, l’application atteint d’abord un 429 sur l’axe ITPM, alors que le RPM est correct. Quelle modification traite le plus directement l’axe réellement limitant ?
- A. Réduire les tokens d’entrée par requête (mettre en cache le préfixe partagé, élaguer le contexte) et/ou demander un palier supérieur.
- B. Envoyer plus de requêtes par minute puisque le RPM a de la marge.
- C. Augmenter max_tokens pour qu’il faille moins de requêtes.
- D. Baisser temperature pour réduire l’usage de tokens.
Afficher la réponse
Réponse : A.
La limite atteinte est celle des tokens d’entrée par minute, donc réduire les tokens d’entrée (cache, élagage) ou monter de palier est le correctif direct. A est correct. B ignore l’axe contraignant. C augmente les tokens de SORTIE, aggravant un autre axe. D (température) ne change pas le nombre de tokens.
Q13D1 · Applications et intégrationSélectionnez une réponse
Un développeur envoie des messages commençant par un tour role: 'assistant' et obtient 400 invalid_request. Quelle est la règle ?
- A. messages doit commencer par un tour user et alterner ; les blocs assistant précédents sont ajoutés tels quels en assistant, les sorties d’outils en user avec des blocs tool_result.
- B. messages peut commencer par l’un ou l’autre rôle ; le 400 est une limite de débit.
- C. Le premier tour doit être system à l’intérieur de messages.
- D. Les tours assistant ne sont autorisés qu’en streaming.
Afficher la réponse
Réponse : A.
Les conversations commencent par user et alternent. A énonce la règle. B est faux (un 400 n’est pas un 429). C est faux : system est un champ de premier niveau, pas une entrée de message sur les modèles actuels. D invente une contrainte de streaming.
Q14D1 · Applications et intégrationSélectionnez une réponse
Un ingénieur support demande la chose la plus utile à inclure dans les journaux applicatifs pour que le support Anthropic puisse tracer un appel échoué précis. Laquelle est-ce ?
- A. Le request-id de la réponse (corrélé avec votre propre request ID).
- B. La clé API complète utilisée pour l’appel.
- C. Les PII brutes de l’utilisateur pour le contexte.
- D. La seule valeur de max_tokens.
Afficher la réponse
Réponse : A.
Le request-id est l’identifiant de corrélation sur lequel le support et vos traces s’appuient tous deux. A est correct. B journalise un secret (violation de sécurité). C journalise des PII (violation d’hygiène). D est insuffisant et n’est pas un identifiant de trace.
Q15D1 · Applications et intégrationSélectionnez une réponse
Un harnais sur Fable 5.1 élague l’historique en éditant et réordonnant les tours précédents ; les utilisateurs signalent des erreurs sur des blocs de thinking invalides. Quelle refonte est correcte ?
- A. Rendre le harnais append-only : figer system/tools, exprimer les changements en cours de session en messages role: 'system' là où c’est pris en charge, et n’élaguer que côté serveur via context editing/compaction.
- B. Continuer à muter l’historique ; l’erreur est transitoire, donc ajoutez un backoff.
- C. Désactiver le thinking sur Fable 5.1 pour autoriser les éditions.
- D. Baisser temperature pour que les blocs de thinking cessent d’apparaître.
Afficher la réponse
Réponse : A.
Fable 5.1 invalide le thinking ultérieur quand les tours précédents changent, donc le harnais doit être append-only et élaguer côté serveur. A est correct. B réessaie aveuglément une erreur de conception déterministe. C est impossible (Fable 5.1 pense toujours). D n’empêche pas la production de blocs de thinking.
Q16D1 · Applications et intégrationSélectionnez deux réponses
Une migration conserve le même code Messages API mais doit passer par Amazon Bedrock pour la conformité. Quelles DEUX choses changent réellement par rapport à l’API Anthropic directe ?
- A. Le constructeur de client (AnthropicBedrock) et l’authentification (AWS IAM / SigV4).
- B. Le format des model IDs (identifiants de modèle de style Bedrock).
- C. La forme fondamentale des requêtes messages/system/max_tokens.
- D. La signification des valeurs de stop_reason.
- E. Le fait que max_tokens soit obligatoire.
Afficher la réponse
Réponse : A et B.
Sur Bedrock/Vertex, la forme des requêtes et la sémantique de stop_reason sont identiques ; ce qui change, c’est le client/l’authentification et le format des model IDs. A et B sont corrects. C, D et E sont inchangés — tout l’intérêt est la portabilité du corps de requête et des champs de contrôle.
Q17D1 · Applications et intégrationSélectionnez une réponse
Un chemin de code appelle client.messages.create avec max_tokens omis, en s’attendant à une valeur par défaut raisonnable, et reçoit 400. Quelle est l’explication correcte ?
- A. max_tokens est obligatoire et plafonne la sortie générée ; il n’y a pas de valeur par défaut implicite, donc une valeur omise est une requête invalide.
- B. max_tokens est facultatif ; le 400 doit être une surcharge transitoire.
- C. max_tokens définit la fenêtre de contexte et doit lui être égal.
- D. max_tokens n’est requis que lorsque des outils sont déclarés.
Afficher la réponse
Réponse : A.
max_tokens est un champ obligatoire qui plafonne la sortie générée. A est correct. B interprète à tort un 400 déterministe comme transitoire. C le confond avec la fenêtre de contexte. D invente une condition réservée aux outils.
Q18D1 · Applications et intégrationSélectionnez une réponse
Un client SDK est créé une fois et partagé sur un serveur web asynchrone gérant des milliers de requêtes concurrentes. Quelle configuration équilibre le mieux fiabilité et exactitude ?
- A. Utiliser le client asynchrone, définir un timeout délibéré, activer des réessais SDK bornés pour les erreurs transitoires, et plafonner la concurrence pour respecter les limites de débit.
- B. Créer un nouveau client synchrone par requête à l’intérieur de la boucle d’événements, sans timeout.
- C. Désactiver tous les réessais et timeouts pour maximiser le débit.
- D. Utiliser une concurrence non bornée pour que toutes les requêtes partent d’un coup.
Afficher la réponse
Réponse : A.
Un client asynchrone avec timeout, réessais bornés et plafond de concurrence est le pattern robuste. A est correct. B bloque la boucle avec un client synchrone sans timeout. C retire les filets de sécurité pour les erreurs transitoires. D ignore les limites de débit et provoque des tempêtes de 429.
Q19D2 · Sélection et optimisation des modèlesSélectionnez une réponse
Un pipeline exécute 200 000 classifications de sentiment courtes pendant la nuit ; la latence est sans importance et le jeu d’étiquettes est simple. Quel choix est la MOST cost-effective ?
- A. Haiku 4.5 via la Message Batches API (palier le moins cher + remise batch de 50 %).
- B. Opus 5 en synchrone avec forte concurrence pour la précision.
- C. Sonnet 5 avec streaming pour accélérer chaque appel.
- D. Fable 5.1 avec effort xhigh pour les meilleures étiquettes.
Afficher la réponse
Réponse : A.
Un travail simple, à fort volume et tolérant à la latence correspond au modèle capable le moins cher plus le batching. A est correct. B et D sont sur-conçus et coûteux pour des étiquettes triviales. C (streaming) ne réduit pas le coût en tokens et est sans intérêt pour un traitement hors ligne.
Q20D2 · Sélection et optimisation des modèlesSélectionnez une réponse
Une équipe veut un budget de raisonnement fixe de 1 500 tokens de thinking. Sur quel modèle actuel peut-elle régler budget_tokens, et que doivent utiliser les autres ?
- A. Seul Haiku 4.5 accepte budget_tokens ; Opus 5, Sonnet 5 et Fable 5.1 utilisent thinking: {type: 'adaptive'} avec des niveaux d’effort.
- B. Tous les modèles actuels acceptent budget_tokens s’il est inférieur à 2 048.
- C. Seul Opus 5 accepte budget_tokens ; les autres n’ont pas de thinking.
- D. budget_tokens doit être associé à top_p sur chaque modèle.
Afficher la réponse
Réponse : A.
budget_tokens est réservé à Haiku 4.5 ; les autres modèles actuels utilisent le thinking adaptatif avec effort. A est correct. B est faux (il renvoie 400 ailleurs). C est faux (les autres prennent bien en charge le thinking, en mode adaptatif). D invente une exigence d’association.
Q21D2 · Sélection et optimisation des modèlesSélectionnez une réponse
Une tâche envoie 4 000 tokens d’entrée + 800 de sortie, 30 000 fois par jour. Sonnet 5 ($2/$10 par MTok) et Haiku 4.5 ($1/$5) franchissent tous deux le seuil de qualité. Quelle est la différence de coût journalier, et lequel est le moins cher ?
- A. Haiku 4.5 (~$240/jour) est moins cher que Sonnet 5 (~$480/jour) d’environ $240/jour.
- B. Ils coûtent la même chose car les nombres de tokens sont identiques.
- C. Sonnet 5 est moins cher car les modèles plus grands se prêtent mieux au batching.
- D. Haiku 4.5 est à ~$480/jour et Sonnet 5 à ~$240/jour.
Afficher la réponse
Réponse : A.
Haiku : entrée 4000*30000*$1/1e6 = $120 + sortie 800*30000*$5/1e6 = $120 = $240/jour. Sonnet : $240 d’entrée + $240 de sortie = $480/jour. A est correct (~$240 de différence). B ignore que les tarifs par token diffèrent. C invente un effet de batching. D inverse l’arithmétique.
Q22D2 · Sélection et optimisation des modèlesSélectionnez une réponse
La majorité du trafic est trivial ; une petite minorité nécessite un raisonnement approfondi ; les cas difficiles ne doivent pas se dégrader et le coût doit rester bas. Un junior propose d’escalader chaque fois que Claude s’auto-évalue à une confiance inférieure à 0,8. Quelle est la conception correcte ?
- A. Cascade Haiku 4.5 → Sonnet 5 → Opus 5, en escaladant sur un signal programmatique (échec de validation de schéma, refusal, ou une étiquette de classifieur), pas sur une confiance auto-déclarée.
- B. Tout exécuter sur Opus 5 par sécurité.
- C. Tout exécuter sur Haiku 4.5 pour être économique.
- D. Escalader sur le score de confiance exactement comme proposé.
Afficher la réponse
Réponse : A.
Une cascade avec une porte d’escalade programmatique garde le gros du volume peu cher sans nuire à la minorité difficile. A est correct. B est sur-conçu/coûteux ; C échoue sur les cas difficiles (aveugle à la contrainte) ; D repose sur une confiance auto-déclarée (anti-pattern #4).
Q23D2 · Sélection et optimisation des modèlesSélectionnez deux réponses
Les utilisateurs trouvent une UI de chat « lente » bien que le temps total de la tâche soit acceptable, et la qualité de sortie ne doit pas changer. Quels DEUX leviers améliorent le mieux l’expérience perçue ?
- A. Activer le streaming pour que les tokens s’affichent au fur et à mesure de leur production (meilleur temps jusqu’au premier token).
- B. Mettre en cache le préfixe stable pour que le modèle commence à générer plus tôt.
- C. Basculer sur Opus 5 pour chaque requête.
- D. Augmenter max_tokens à 8 000.
- E. Régler l’effort sur xhigh.
Afficher la réponse
Réponse : A et B.
La latence perçue est le temps jusqu’au premier token ; le streaming plus le cache de préfixe (qui évite de retraiter le préfixe) permettent tous deux de faire circuler la sortie plus tôt sans changer la qualité. A et B sont corrects. C, D et E ajoutent tous de la latence et/ou du coût et modifient le comportement.
Q24D2 · Sélection et optimisation des modèlesSélectionnez une réponse
Pour une comparaison hors ligne équitable de deux versions de prompt, un développeur exécute chacune une fois à temperature: 0 sur un alias de modèle flottant et traite des scores identiques comme preuve d’équivalence. Quelle est la faille ?
- A. temperature: 0 réduit la variance mais n’est pas déterministe au bit près, et un alias flottant peut changer sous vos pieds ; épinglez un snapshot et exécutez plusieurs essais par version.
- B. Il n’y a pas de faille ; la température 0 garantit une sortie identique.
- C. La faille est de ne pas utiliser l’effort xhigh pour les deux.
- D. La faille est de ne pas activer le streaming pour la reproductibilité.
Afficher la réponse
Réponse : A.
La température 0 réduit mais n’élimine pas la variance, et un alias flottant compromet la reproductibilité. A est correct. B est la fausse idée testée. C (effort) ajoute de la variabilité, pas de la rigueur. D (streaming) est un mécanisme de livraison sans rapport avec la reproductibilité.
Q25D2 · Sélection et optimisation des modèlesSélectionnez deux réponses
Quelles DEUX affirmations sur les fenêtres de contexte et les plafonds de sortie de la gamme actuelle sont correctes ?
- A. Sonnet 5 et Opus 5 ont chacun une fenêtre de contexte de 1M.
- B. Haiku 4.5 a une fenêtre de contexte de 200k.
- C. Haiku 4.5 a une fenêtre de contexte de 1M.
- D. Fable 5.1 a une fenêtre de contexte de 128k.
- E. Sonnet 5 a une fenêtre de contexte de 200k.
Afficher la réponse
Réponse : A et B.
Sonnet 5 et Opus 5 sont à 1M de contexte ; Haiku 4.5 est à 200k. A et B sont corrects. C est faux (Haiku est à 200k). D confond les 128k de SORTIE MAXIMALE de Fable 5.1 avec son contexte de 1M. E sous-estime la fenêtre de 1M de Sonnet 5.
Q26D2 · Sélection et optimisation des modèlesSélectionnez une réponse
Une extraction de 10 000 documents s’exécute la nuit et est sensible au coût ; Sonnet 5 franchit le seuil de qualité. Chaque requête a un préfixe stable de 2 000 tokens et 1 000 tokens uniques plus 500 tokens de sortie. Quelle combinaison est la MOST cost-effective ?
- A. Sonnet 5 via la Batches API avec cache_control sur le préfixe partagé de 2 000 tokens.
- B. Opus 5 en synchrone, sans cache, pour une qualité maximale.
- C. Sonnet 5 en synchrone avec uniquement le cache (pas de batching).
- D. Haiku 4.5 en synchrone avec effort xhigh.
Afficher la réponse
Réponse : A.
Un travail tolérant à la latence doit empiler les trois leviers : le modèle le moins cher qui franchit le seuil, les Batches (50 % de remise) et le cache du préfixe stable. A est correct. B est sur-conçu. C laisse la remise batch de 50 % inutilisée. D est invalide car Haiku 4.5 n’a pas de paramètre effort.
Q27D2 · Sélection et optimisation des modèlesSélectionnez une réponse
Une équipe migrant de Sonnet 5 vers Opus 5 veut minimiser le risque. Quelle séquence est correcte ?
- A. Modifier l’unique constante de modèle pilotée par l’environnement derrière un flag, réexécuter le jeu d’eval de référence, vérifier les paramètres supprimés et les écarts de coût/latence, puis déployer sur une petite fraction avant de monter en charge.
- B. Remplacer le model ID dans chaque fichier et déployer directement en production.
- C. Laisser chaque microservice choisir son propre modèle à l’exécution.
- D. Ne changer qu’en production pour obtenir le signal réel le plus vite.
Afficher la réponse
Réponse : A.
Une migration centralisée, protégée par un flag, validée par eval et montée en charge progressivement est la voie sûre. A est correct. B risque un large rayon d’impact ; C provoque une dérive de modèle et une incohérence ; D change la production sans filet de sécurité.
Q28D3 · Agents et workflowsSélectionnez une réponse
Un workflow a trois étapes fixes et ordonnées (transcription → synthèse → classification), chacune avec des entrées et sorties connues. Un développeur propose un agent autonome qui décide des étapes. Quelle est la BEST conception et pourquoi ?
- A. Prompt chaining : prévisible, testable et peu coûteux pour des sous-tâches séquentielles fixes ; réservez les agents aux chemins qui ne peuvent pas être prédéterminés.
- B. Un agent autonome, car les agents sont toujours plus capables.
- C. Un unique méga-prompt qui fait les trois d’un coup.
- D. Orchestrator-workers avec génération dynamique de sous-agents.
Afficher la réponse
Réponse : A.
Des étapes fixes et ordonnées sont la définition même du prompt chaining. A est correct. B est sur-conçu — l’autonomie ajoute de l’imprévisibilité sans bénéfice ici. C sacrifie le contrôle et la testabilité. D est pour des tâches dont les sous-tâches sont inconnues au moment de la conception, pas celle-ci.
Q29D3 · Agents et workflowsSélectionnez une réponse
Une boucle d’agent ne se termine parfois jamais. Le code actuel s’arrête quand le texte de l’assistant contient « done » et plafonne aussi à 5 itérations. Quelle est la condition d’arrêt PRIMARY correcte ?
- A. Continuer tant que stop_reason == 'tool_use' et s’arrêter sur end_turn ; garder le plafond d’itérations uniquement comme filet de sécurité et gérer max_tokens/pause_turn/refusal explicitement.
- B. S’appuyer sur le plafond de 5 itérations comme arrêt principal.
- C. Étendre la liste de mots-clés pour capter davantage de tournures proches de « done ».
- D. Baisser temperature pour que la formulation soit cohérente.
Afficher la réponse
Réponse : A.
La terminaison doit être pilotée par stop_reason ; le plafond est un filet de sécurité. A est correct. B fait du plafond l’arrêt principal (anti-pattern #2). C parse de la prose (anti-pattern #1). D ne crée pas de signal de contrôle fiable.
Q30D3 · Agents et workflowsSélectionnez une réponse
Le contexte d’un agent de recherche se remplit de sorties d’outils intermédiaires verbeuses, dégradant le raisonnement ultérieur et gonflant le coût. Quelle conception corrige cela le plus directement ?
- A. Déléguer les sous-tâches à des sous-agents à contexte isolé qui ne renvoient que des résumés distillés au coordinateur.
- B. Augmenter max_tokens pour faire tenir plus de sortie.
- C. Baisser la température pour raccourcir la sortie.
- D. Retirer tous les outils de l’agent.
Afficher la réponse
Réponse : A.
Les sous-agents à contexte isolé maintiennent le travail intermédiaire bruyant hors de la fenêtre du coordinateur et ne renvoient que des résumés. A est correct. B plafonne la longueur de sortie, pas l’encombrement du contexte. C ne réduit pas la sortie d’outil. D retire une capacité nécessaire (aveugle à la contrainte).
Q31D3 · Agents et workflowsSélectionnez deux réponses
Dans le Claude Agent SDK, quelles DEUX options imposent directement le moindre privilège et une sûreté déterministe pour un agent qui ne doit jamais faire de force-push ni supprimer de données ?
- A. Une allowlist allowed_tools restreignant l’agent aux outils dont il a vraiment besoin.
- B. Un hook PreToolUse bloquant qui refuse les commandes destructrices correspondantes.
- C. Régler max_turns sur 1000.
- D. Un system_prompt plus long et plus sévère interdisant les actions.
- E. permission_mode: 'bypassPermissions'.
Afficher la réponse
Réponse : A et B.
Une allowlist plus un hook bloquant imposent le moindre privilège et des arrêts nets de façon déterministe. A et B sont corrects. C affaiblit le filet de sécurité. D relève du prompt-comme-application (anti-pattern #3). E retire entièrement les garde-fous.
Q32D3 · Agents et workflowsSélectionnez une réponse
Une équipe veut qu’Anthropic héberge la boucle d’agent et le sandbox pour livrer vite des tâches agentiques standard avec un minimum d’ops. Quelle option convient, et quel est le principal compromis ?
- A. Managed Agents — Anthropic héberge la boucle et le sandbox ; le compromis est un moindre contrôle sur l’environnement et les outils.
- B. Agent SDK auto-hébergé — Anthropic exécute quand même le sandbox pour vous.
- C. Une boucle Messages API brute sans outils — Anthropic gère la terminaison.
- D. Une tâche cron invoquant un unique prompt — c’est un managed agent.
Afficher la réponse
Réponse : A.
Les Managed Agents hébergent la boucle et le sandbox avec un moindre contrôle de l’environnement. A est correct. B se trompe sur le SDK (c’est vous qui l’hébergez). C ne fournit pas de boucle/sandbox managé et c’est vous qui gérez la terminaison. D n’est pas un agent du tout.
Q33D3 · Agents et workflowsSélectionnez une réponse
Un agent unique est configuré avec 18 outils et sélectionne fréquemment le mauvais. Quel remède est conforme aux recommandations d’Anthropic ?
- A. Réduire à environ 4 à 5 outils ciblés, répartir les responsabilités entre sous-agents, et utiliser l’outil de recherche d’outils avec defer_loading pour le plus grand catalogue.
- B. Ajouter des outils encore plus finement décrits pour couvrir chaque cas limite.
- C. Forcer un outil spécifique à chaque tour avec tool_choice.
- D. Augmenter max_turns pour qu’il finisse par choisir correctement.
Afficher la réponse
Réponse : A.
Trop d’outils est l’anti-pattern #8 ; le correctif est moins d’outils actifs, la spécialisation par sous-agents, et la recherche d’outils + defer_loading. A est correct. B aggrave la surcharge. C est fragile et casse sur Fable 5.1. D n’améliore pas la sélection.
Q34D3 · Agents et workflowsSélectionnez une réponse
Une boucle d’agent renvoie stop_reason == 'max_tokens' en pleine réponse, et le harnais marque le tour comme terminé. Quel est le traitement correct ?
- A. Reconnaître que la sortie a été tronquée : continuer la réponse (ou augmenter max_tokens), et non la marquer comme terminée.
- B. Traiter max_tokens comme end_turn ; la réponse est complète.
- C. Réessayer toute la requête à temperature: 0.
- D. Basculer sur Haiku 4.5 et renvoyer.
Afficher la réponse
Réponse : A.
max_tokens signifie troncature, pas achèvement. A récupère le contenu manquant. B tronque silencieusement le travail (échec silencieux). C régénère au lieu de continuer et perd la partie déjà produite. D change de modèle sans récupérer le contenu tronqué.
Q35D3 · Agents et workflowsSélectionnez une réponse
Une tâche doit exécuter plusieurs recherches indépendantes puis les agréger ; les résultats ne dépendent pas les uns des autres. Quel pattern convient le BEST ?
- A. Parallelization : exécuter les sous-tâches indépendantes en parallèle et agréger leurs résultats.
- B. Prompt chaining, en injectant chaque résultat dans le suivant.
- C. Evaluator-optimizer avec une boucle de critique.
- D. Routing vers un unique chemin spécialisé.
Afficher la réponse
Réponse : A.
Des sous-tâches indépendantes concurrentes avec agrégation, c’est la parallelization. A est correct. B sérialise inutilement du travail indépendant. C est pour l’amélioration itérative de la qualité. D dispatche vers une seule catégorie, pas plusieurs sous-tâches concurrentes.
Q36D3 · Agents et workflowsSélectionnez deux réponses
Un coordinateur de recherche délègue des sujets à des sous-agents workers. Quels DEUX choix gardent le contexte du coordinateur propre et les coûts bas ?
- A. Donner à chaque worker sa propre fenêtre de contexte isolée ne contenant que sa portion de tâche.
- B. Faire renvoyer par chaque worker un court résumé distillé au coordinateur.
- C. Renvoyer la transcription complète de chaque worker, y compris la sortie d’outil intermédiaire.
- D. Exécuter tout le travail dans l’unique contexte partagé du coordinateur.
- E. Donner à chaque worker les 18 outils.
Afficher la réponse
Réponse : A et B.
Des contextes de workers isolés plus des retours de résumés distillés gardent la fenêtre du coordinateur propre et peu coûteuse. A et B sont corrects. C et D réintroduisent l’encombrement ; E est l’anti-pattern #8 (trop d’outils).
Q37D4 · Ingénierie des prompts et du contexteSélectionnez une réponse
Un endpoint sur Sonnet 5 doit renvoyer du JSON conforme au schéma à chaque appel. Quelle approche est la MOST fiable ?
- A. output_config.format avec un schéma JSON (ou un schéma d’outil strict: true) plus une boucle de validation-réessai qui réinjecte l’erreur.
- B. Demander du JSON dans le prompt et régler temperature: 0.
- C. Augmenter max_tokens pour que le JSON tienne toujours.
- D. Faire un prefill de { et faire confiance à la sortie sans validation.
Afficher la réponse
Réponse : A.
Une sortie structurée contrainte par schéma plus la validation-réessai est le pattern fiable. A est correct. B est purement basé sur le prompt et dérive. C traite la troncature, pas la conformité. D omet la validation (risque d’échec silencieux).
Q38D4 · Ingénierie des prompts et du contexteSélectionnez une réponse
Une boucle de validation-réessai rejette le JSON du modèle mais ne renvoie que le prompt d’origine, si bien que la même erreur se reproduit jusqu’à épuisement des tentatives. Quel est le correctif ?
- A. Ajouter la sortie fautive et l’erreur précise (par ex. « total must be a number ») comme nouveau tour user pour que la prochaine tentative cible exactement ce défaut.
- B. Augmenter le nombre de réessais à 20 et continuer d’envoyer le même prompt.
- C. Basculer sur Opus 5 pour les réessais.
- D. Baisser max_tokens à chaque réessai.
Afficher la réponse
Réponse : A.
Une validation-réessai efficace réinjecte l’erreur concrète pour que le modèle puisse la corriger. A est correct. B répète aveuglément la même erreur (simple mémorisation). C change de modèle sans lui dire ce qui n’allait pas. D peut aggraver la troncature et ne transmet rien.
Q39D4 · Ingénierie des prompts et du contexteSélectionnez deux réponses
Un agent de longue durée ralentit et perd le fil à mesure que l’historique grossit. Le récit doit rester cohérent, mais les anciens résultats d’outils sont volumineux et obsolètes. Quels DEUX contrôles côté serveur traitent cela correctement ?
- A. Le context editing pour effacer les résultats d’outils obsolètes devenus inutiles.
- B. La compaction pour résumer les tours anciens tout en préservant le récit.
- C. Augmenter max_tokens.
- D. Ajouter davantage d’outils pour l’aider à se concentrer.
- E. Augmenter temperature.
Afficher la réponse
Réponse : A et B.
Le context editing efface les sorties d’outils obsolètes ; la compaction condense le récit tout en gardant le fil. A et B sont corrects. C ne fait que plafonner la longueur de sortie. D et E ne font rien contre l’encombrement/la dérive.
Q40D4 · Ingénierie des prompts et du contexteSélectionnez une réponse
Un prompt de QA sur long document place la question de l’utilisateur en premier, puis 200 pages de source, et les réponses sont mal ancrées tandis que le cache n’aide jamais. Quel unique réordonnancement corrige les deux problèmes ?
- A. Placer les instructions stables et les documents en premier (avec un point de rupture de cache) et la question en dernier.
- B. Déplacer la question dans le prompt système mais la garder avant les documents.
- C. Intercaler la question entre chaque page.
- D. Répartir les documents sur de nombreuses requêtes aléatoires.
Afficher la réponse
Réponse : A.
Documents d’abord, requête en dernier améliore l’ancrage et rend le préfixe stable cacheable en un seul changement. A est correct. B fait toujours précéder les preuves par la question. C et D nuisent à la cohérence et au cache.
Q41D4 · Ingénierie des prompts et du contexteSélectionnez une réponse
Une équipe a besoin d’une extraction structurée fiable sur Fable 5.1, mais forcer un outil spécifique avec tool_choice renvoie 400. Que doit-elle utiliser à la place ?
- A. output_config.format avec un schéma JSON (ou strict: true, ou auto + une instruction claire), puisque Fable 5.1 rejette le choix d’outil forcé.
- B. Forcer l’outil quand même et réessayer le 400 avec un backoff.
- C. Désactiver le thinking sur Fable 5.1.
- D. Baisser max_tokens jusqu’à ce que l’outil soit choisi.
Afficher la réponse
Réponse : A.
Fable 5.1 rejette le choix d’outil any/forcé, donc les sorties structurées ou strict/auto sont les voies. A est correct. B réessaie un 400 déterministe. C est impossible et sans rapport. D n’influence pas le choix d’outil.
Q42D4 · Ingénierie des prompts et du contexteSélectionnez deux réponses
Un synthétiseur gère bien les documents courants mais mishandle de façon répétée un format rare de formulaire manuscrit. Quels DEUX changements de prompt l’améliorent le mieux ?
- A. Ajouter des exemples few-shot représentatifs incluant le cas limite du formulaire manuscrit.
- B. Augmenter la diversité des exemples pour couvrir la gamme des formats.
- C. Ajouter dix exemples supplémentaires du format courant.
- D. Augmenter temperature pour plus de variété.
- E. Supprimer tous les exemples pour que le modèle généralise.
Afficher la réponse
Réponse : A et B.
Les échecs sur des cas limites appellent des exemples de cas limites représentatifs et une plus grande diversité. A et B sont corrects. C ajoute davantage du cas déjà géré (simple mémorisation). D ajoute de la variabilité. E supprime entièrement le guidage.
Q43D5 · Outils et MCPSélectionnez une réponse
Claude appelle fréquemment le mauvais outil et transmet des arguments malformés pour un champ à ensemble fermé comme la priorité. Quel est le FIRST et le MOST efficace correctif ?
- A. Réécrire la description de l’outil (quoi/quand/quand-pas/renvoie/effets de bord) et resserrer input_schema avec des types, un enum pour l’ensemble fermé, et required.
- B. Baisser temperature.
- C. Passer à Opus 5.
- D. Augmenter max_tokens.
Afficher la réponse
Réponse : A.
La description et le schéma sont les leviers principaux d’un usage correct des outils ; un enum empêche les valeurs inventées. A est correct. B, C et D sont secondaires et ne traitent pas une description vague ou un schéma trop lâche.
Q44D5 · Outils et MCPSélectionnez deux réponses
Un outil get_order expire pendant un appel d’outils parallèle aux côtés d’un search_kb réussi. Quelles DEUX actions gardent le protocole valide et permettent à Claude de récupérer ?
- A. Renvoyer un tool_result pour l’appel échoué avec le même tool_use_id, un message d’erreur, et is_error: true.
- B. Renvoyer le résultat réussi de search_kb dans le même tour user, rattaché à son tool_use_id.
- C. Omettre le résultat de l’outil échoué pour que Claude l’ignore.
- D. Fusionner les deux sorties en un seul tool_result.
- E. Lever une exception et mettre fin à la conversation.
Afficher la réponse
Réponse : A et B.
Chaque tool_use a besoin d’un tool_result correspondant dans le même tour ; les erreurs utilisent is_error: true. A et B sont corrects. C provoque un 400 et cache l’échec (échec silencieux). D casse la correspondance d’id. E abandonne l’exécution et perd les diagnostics.
Q45D5 · Outils et MCPSélectionnez deux réponses
Quelles DEUX capacités sont des outils intégrés côté serveur (hébergés par Anthropic) plutôt que des outils personnalisés côté client ?
- A. La recherche web.
- B. L’exécution de code dans un sandbox.
- C. Votre fonction interne de requête sur la base de données de commandes.
- D. Un script shell local que vous maintenez.
- E. L’API de facturation de votre entreprise.
Afficher la réponse
Réponse : A et B.
La recherche web et l’exécution de code sont des outils côté serveur hébergés par Anthropic. A et B sont corrects. C, D et E s’exécutent dans votre code/infrastructure et sont des outils personnalisés côté client.
Q46D5 · Outils et MCPSélectionnez une réponse
Une équipe veut les MÊMES outils disponibles dans Claude Code, Claude Desktop et son service Messages API de production, maintenus au même endroit, avec un serveur distant correctement sécurisé. Quel est le meilleur mécanisme et son exigence de sécurité ?
- A. Construire un serveur MCP et y connecter chaque hôte (stdio/Streamable HTTP) ; sécuriser le serveur distant avec OAuth 2.1.
- B. Copier le JSON des outils personnalisés dans chaque application.
- C. Écrire un Skill dans .claude/skills/ et partager le dossier.
- D. Mettre les définitions d’outils dans CLAUDE.md.
Afficher la réponse
Réponse : A.
MCP est le mécanisme de réutilisation multi-hôtes ; les serveurs distants utilisent OAuth 2.1. A est correct. B duplique la maintenance. C est un savoir-faire packagé propre à Claude Code, pas un serveur d’outils multi-hôtes. D contient des instructions, pas des outils exécutables.
Q47D5 · Outils et MCPSélectionnez une réponse
Dans MCP, quelle primitive est contrôlée par le modèle (Claude décide quand l’invoquer), et en quoi les deux autres diffèrent-elles ?
- A. Les tools sont contrôlés par le modèle ; les resources par l’application ; les prompts par l’utilisateur.
- B. Les resources sont contrôlées par le modèle ; les tools par l’utilisateur ; les prompts par l’application.
- C. Les prompts sont contrôlés par le modèle ; les tools et les resources sont des transports.
- D. Les trois sont contrôlés par le modèle.
Afficher la réponse
Réponse : A.
Tools (modèle), resources (application), prompts (utilisateur) est la bonne cartographie de contrôle. A est correct. B et C brouillent la cartographie ; les transports (stdio/HTTP) ne sont pas une primitive. D est faux — seuls les tools sont contrôlés par le modèle.
Q48D6 · Sécurité et sûretéSélectionnez une réponse
Un agent résume des pages web récupérées. Une page cache un commentaire HTML ordonnant à Claude d’appeler transfer_funds, et l’agent manque de s’exécuter. Quelle combinaison prévient le MIEUX le virement ?
- A. Encadrer le contenu récupéré dans des frontières de contenu comme des données ET imposer un hook PreToolUse qui bloque transfer_funds sans approbation humaine.
- B. Ajouter « ne jamais faire confiance aux pages web » au prompt système et s’en remettre au modèle.
- C. Baisser la température et réessayer le résumé.
- D. Basculer sur un modèle plus grand qui résiste à l’injection.
Afficher la réponse
Réponse : A.
C’est une injection indirecte ; la défense est des frontières de contenu (traiter le texte externe comme des données) plus un hook déterministe sur l’outil dangereux. A est correct. B relève du prompt-comme-application (anti-pattern #3). C et D n’arrêtent pas l’injection — la température et la taille du modèle ne sont pas des défenses contre l’injection.
Q49D6 · Sécurité et sûretéSélectionnez deux réponses
Un agent de support en lecture seule dispose actuellement des outils get_order, search_kb, issue_refund et delete_account. Quels DEUX changements satisfont le mieux le moindre privilège et l’hygiène des secrets ?
- A. Retirer issue_refund et delete_account de l’allowlist de l’agent ; router ces actions via un workflow séparé approuvé par un humain.
- B. Garder la clé API dans des variables d’environnement / un gestionnaire de secrets, jamais dans les prompts ni dans CLAUDE.md.
- C. Garder tous les outils mais ajouter une journalisation des remboursements et suppressions pour repérer les abus.
- D. Documenter la clé API dans CLAUDE.md pour l’équipe.
- E. Ajouter une règle dans le prompt système disant à l’agent de ne pas utiliser le remboursement/la suppression.
Afficher la réponse
Réponse : A et B.
Le moindre privilège retire les outils puissants inutiles ; les secrets vivent dans l’environnement/un gestionnaire de secrets. A et B sont corrects. C ne détecte le mal qu’après coup ; D fuit la clé dans le contrôle de version ; E relève du prompt-comme-application (anti-pattern #3).
Q50D6 · Sécurité et sûretéSélectionnez deux réponses
Une application de santé doit traiter des PHI avec zéro rétention de données et FedRAMP High. Quelles DEUX décisions conviennent aux contraintes ?
- A. Accéder à Claude via Bedrock ou Vertex sous un BAA / une autorisation FedRAMP High.
- B. Choisir un modèle éligible ZDR plutôt que Fable 5.1, et caviarder les PHI au minimum nécessaire.
- C. Utiliser Fable 5.1 car c’est le modèle le plus capable.
- D. Mettre les PHI dans le prompt système pour que Claude ait toujours le contexte.
- E. Désactiver toute journalisation et tous les hooks pour réduire l’empreinte de données.
Afficher la réponse
Réponse : A et B.
Bedrock/Vertex fournissent FedRAMP High et la couverture BAA ; un modèle éligible ZDR avec minimisation des PHI satisfait la zéro rétention. A et B sont corrects. C casse le ZDR (Fable 5.1 impose une rétention de 30 jours). D sur-partage les PHI. E retire l’application des règles et l’auditabilité.
Q51D6 · Sécurité et sûretéSélectionnez une réponse
Dans une conception de garde-fous en couches (détecter → instruire → appliquer → vérifier → approuver), où faut-il réellement appliquer « aucune suppression en production sans approbation » ?
- A. La couche d’application — un hook PreToolUse déterministe qui bloque la suppression (exit 2) et route vers l’approbation humaine.
- B. La couche d’instruction — une phrase forte dans le prompt système.
- C. La couche de détection — un classifieur d’entrée.
- D. La couche de vérification — une validation de sortie a posteriori.
Afficher la réponse
Réponse : A.
Les règles critiques et irréversibles doivent vivre dans la couche d’application sous forme de hooks déterministes. A est correct. B relève du prompt-comme-application (anti-pattern #3). C détecte mais ne bloque pas. D vérifie après que l’action a déjà été exécutée.
Q52D7 · Claude CodeSélectionnez deux réponses
Une équipe doit bloquer la famille de commandes rm -rf pour tout le monde dans Claude Code, d’une manière qu’aucun développeur ne puisse contourner, tout en s’exécutant de façon non interactive en CI. Quelles DEUX étapes y parviennent ?
- A. Ajouter Bash(rm -rf:*) à permissions.deny et l’imposer via une politique managée pour qu’il soit non contournable (deny l’emporte sur allow).
- B. Exécuter en CI en headless avec claude -p ... --output-format json et une allowlist explicite --allowedTools.
- C. Écrire « never run rm -rf » dans ./CLAUDE.md.
- D. Utiliser --permission-mode bypassPermissions en CI pour la vitesse.
- E. Ajouter un hook PostToolUse qui s’excuse après l’exécution de la commande.
Afficher la réponse
Réponse : A et B.
Un motif deny managé bloque la famille de façon non contournable, et le headless -p avec une allowlist d’outils s’exécute en CI en toute sécurité. A et B sont corrects. C est un conseil en prose, pas une application. D retire les garde-fous. E se déclenche une fois les dégâts faits.
Q53D8 · Eval, tests et débogageSélectionnez deux réponses
Un modèle obtient 93 % global aux evals mais un incident en production concerne des formulaires manuscrits, et le pipeline d’eval faisait noter au générateur ses propres réponses dans la même session. Quelles DEUX pratiques auraient détecté et correctement jugé cela ?
- A. Rapporter des métriques par segment (par type de document) et conditionner la CI au pire segment, pas à l’agrégat.
- B. Utiliser un LLM-as-judge dans une session distincte, idéalement un modèle différent, par rapport à une grille.
- C. Faire noter à la même session sa propre sortie, par souci d’efficacité.
- D. Ne suivre que l’exactitude agrégée.
- E. Ignorer les evals en CI et s’appuyer sur la surveillance en production.
Afficher la réponse
Réponse : A et B.
Le conditionnement par segment fait apparaître l’échec sur les formulaires manuscrits (anti-pattern #10), et un juge en session distincte/modèle différent évite le biais d’auto-évaluation (anti-pattern #9). A et B sont corrects. C est de l’auto-évaluation en même session (#9) ; D masque via l’agrégat (#10) ; E retire entièrement le filet de sécurité.