Ne découvrez pas l'examen
le jour J

Réponse : Networking as a Service (NaaS).
Explication : Les trois modèles principaux sont IaaS, PaaS et SaaS ; NaaS n’est pas un modèle AWS officiel.

Réponse : AWS Cloud Development Kit (AWS CDK). Explication : AWS CDK est un framework open-source de développement logiciel pour définir l'infrastructure cloud en utilisant des langages de programmation familiers (TypeScript, Python, Java, etc.). Il se synthétise en modèles CloudFormation pour le déploiement.

Réponse : AWS CloudTrail. Explication : CloudTrail enregistre tous les appels API, y compris TerminateInstances. Les entrées du journal incluent l'identité de l'appelant, l'heure, l'adresse IP source et les paramètres — vous permettant de déterminer qui a terminé l'instance et quand.

Réponse : A) AWS WAF. AWS WAF (Web Application Firewall) protège les applications web contre les exploits courants, notamment l'injection SQL et les attaques XSS. Les règles peuvent être configurées pour inspecter les requêtes HTTP/S et bloquer les modèles malveillants correspondants, offrant une protection au niveau applicatif.

Réponse : Hybride.
Explication : Le modèle hybride combine des ressources cloud et des ressources sur site, facilitant les migrations progressives ou les scénarios spécifiques.

Réponse : Amazon EC2.
Explication : Amazon EC2 vous permet de gérer, configurer et contrôler chaque aspect des machines virtuelles (OS, stockage, réseau, sécurité, etc.).

Réponse : Dans une autre région.
Explication : Sauvegarder dans une autre région AWS protège contre les catastrophes locales et assure la reprise après incident.

Réponse : Dedicated Hosts.
Explication : Les Dedicated Hosts sont conçus pour la conformité logicielle et le BYOL, permettant la gestion des licences personnalisées.

Réponse : Automatiser autant que possible pour faciliter l’expérimentation architecturale.
Explication : L’automatisation permet de tester et déployer rapidement, réduisant les erreurs humaines et favorisant l’innovation.

Réponse : Une région AWS est un emplacement géographique contenant plusieurs zones de disponibilité.
Explication : Chaque région AWS regroupe plusieurs AZ isolées physiquement.

Retrieval-Augmented Generation (RAG) : Les Knowledge Bases extraient uniquement les passages documentaires pertinents pour augmenter le prompt, réduisant ainsi sa taille et les coûts d'appels API au Foundation Model. Cette approche améliore la pertinence en fournissant un contexte ciblé plutôt que des documents bruts complets, contrairement aux approches naïves qui injecteraient l'intégralité des données.

Asynchronous Inference : mode conçu pour les requêtes longues (jusqu'à 1 heure) et les gros volumes (jusqu'à 1 Go). Le client soumet la demande et reçoit une URL S3 pour récupérer le résultat ultérieurement. Contrairement à Real-time (synchrone, timeout court), Serverless (pas adapté aux gros payloads) et Batch Transform (données statiques en masse), l'inférence asynchrone offre la flexibilité nécessaire pour les traitements complexes avec réponse différée.

BLEU (Bilingual Evaluation Understudy) : métrique standard en traduction automatique qui mesure la similitude entre la traduction générée et des références humaines via la comparaison de n-grammes. BLEU évalue la qualité globale en cherchant des correspondances de mots et phrases. Contrairement à ROUGE (résumé), METEOR (flexibilité) ou WER (taux d'erreur mot-à-mot), BLEU reste la métrique automatisée de référence pour l'évaluation systématique de la traduction.

Extraction documentaire hybride : Textract excelle dans l'extraction de données structurées et texte OCR précis. GenAI via Bedrock post-traite pour validation logique, corretion d'erreurs OCR et enrichissement sémantique. Combinaison optimale coût/performance.

Amazon OpenSearch Service k-NN : fournit des index vectoriels natifs et une recherche par plus proche voisin, essentielle pour les applications sémantiques (RAG, recherche de similarité). Contrairement à S3 (stockage objet), OpenSearch offre une indexation et requêtes vectorielles optimisées à grande échelle.

Température et Few-shot : réduire la température (ex: 0.1 vs 1.0) diminue l'aléatoire dans les tokens générés, assurant des prédictions cohérentes. Les exemples few-shot calibrent le LLM sur le style d'étiquetage attendu. À l'inverse, augmenter Top-K introduit plus de variation, et ignorer les exemples perd l'alignement contextuel nécessaire pour la classification stable.

SLMs optimisés sur edge : les Small Language Models (< 13B paramètres) associés à la quantification réduisent la taille modèle et la latence réseau en exécutant localement l'inférence. Les LLMs centralisés (70B+) engendrent latence réseau et délais batch incompatibles avec < 100ms. Seuls les SLMs quantifiés offrent le compromis optimal performance/ressources edge.

Température et déterminisme : La température contrôle la randomité des prédictions du LLM (0=déterministe, 1+=créatif). Pour la classification, baisser la température concentre la probabilité sur le token le plus probable, rendant les sorties reproductibles. Ceci diffère des tâches créatives où haute température génère plus de diversité.

Data drift et réentraînement : la dérive de données survient quand les caractéristiques des données en production divergent du corpus d'entraînement. Augmenter le volume ET la diversité des données permet au modèle de capturer davantage de variations et de patterns réels, améliorant ainsi sa généralisation. Cependant, cela atténue mais ne résout pas complètement le drift—un monitoring continu et un pipeline de réentraînement régulier restent essentiels.

AWS Artifact : service centralisé pour accéder aux rapports de conformité certifiés par des tiers (SOC 2, ISO 27001, etc.) et gérer les abonnements aux notifications de mise à jour. Contrairement à Audit Manager (audits internes), Trusted Advisor (recommandations d'optimisation) ou Data Exchange (données tierces), Artifact fournit spécifiquement les documents de conformité officiels nécessaires pour valider la posture de sécurité et de gouvernance AWS.

Réponse : La Dev Team décide du travail ; aucun titre pour les membres ; framework léger.
Explication : Scrum favorise l'auto-organisation à travers : le fait que la Development Team choisisse son propre travail, la suppression des titres de spécialisation pour encourager la polyvalence, et le fait d'être un framework (et non un processus prescrit) qui permet aux équipes de s'organiser selon leurs besoins.

Réponse : Respect, Focus, Courage.
Explication : Ne pas développer des éléments à faible valeur démontre : le Respect (du temps de l'équipe et de l'investissement des parties prenantes), le Focus (sur ce qui compte le plus) et le Courage (de dire non aux demandes à faible valeur). L'Engagement et l'Ouverture sont également des valeurs Scrum, mais elles sont moins directement illustrées ici.

Objectif du Daily Scrum : Le Daily Scrum est un événement de 15 minutes durant lequel les Développeurs inspectent la progression vers l'Objectif du Sprint et adaptent le Sprint Backlog. Il ne s'agit pas d'un compte-rendu de statut au Scrum Master, d'une attribution de tâches, ni d'une mise à jour du Product Backlog — c'est une inspection et une adaptation auto-organisées par l'équipe de développement.

Responsabilité du Product Owner : Le Product Owner est seul responsable de la gestion du Product Backlog, notamment de sa création, de son ordonnancement et de son affinement. Ce rôle garantit l'alignement entre les objectifs métier et le travail de développement. Bien que les Développeurs réalisent les éléments et que le Scrum Master facilite le processus, aucun des deux ne partage la propriété du Backlog. Les parties prenantes influencent les priorités, mais n'ont pas de responsabilité formelle à ce titre.

Création de la Definition of Done : Un engagement partagé créé par l'ensemble de la Scrum Team, et non par des individus seuls. Lorsqu'aucune norme organisationnelle n'existe, l'équipe l'établit de manière collaborative afin de garantir une qualité constante. Contrairement aux propositions suggérant qu'une seule personne en serait responsable (le Scrum Master, les Developers ou le Product Owner seul), la DoD requiert une appropriation et un accord collectifs.

Réponse : Le cadre Scrum est adopté et utilisé correctement.
Explication : Le Scrum Master est responsable de s'assurer que Scrum est compris et appliqué correctement. Il sert l'équipe en coachant la théorie Scrum, en éliminant les obstacles et en promouvant Scrum au sein de l'équipe et au-delà.

Durée et participants de la Mêlée Quotidienne : La Mêlée Quotidienne est un événement timboxé de 15 minutes destiné aux seuls Développeurs, et non de 30 minutes pour l'ensemble de l'Équipe Scrum. Bien que le Product Owner et le Scrum Master puissent y assister, seuls les Développeurs sont les participants obligatoires et discutent de la progression vers l'Objectif du Sprint.

Réponse : Dès qu'elle est identifiée.
Explication : Du travail est ajouté au Sprint Backlog dès qu'il est identifié par les Developers comme nécessaire pour atteindre l'Objectif du Sprint.

Les points de valeur constituent une technique d'ordonnancement légitime, mais ne sont pas obligatoires. L'approche empirique de Scrum permet au Product Owner de choisir n'importe quelle technique qui l'aide à optimiser la livraison de valeur. Certains PO utilisent le coût du délai, MoSCoW, le Weighted Shortest Job First (WSJF) ou une simple priorité métier. Ce qui compte, c'est que l'ordonnancement maximise la valeur — l'outil est secondaire. Affirmer que les points de valeur constituent la « méthode ultime » va à l'encontre de l'empirisme.

Pourquoi cette réponse est correcte : Les éléments du Product Backlog représentent le « quoi » — les fonctionnalités, les exigences et les besoins des utilisateurs qui apportent de la valeur au produit. Les éléments du Sprint Backlog représentent le « comment » — les tâches détaillées et la décomposition du travail créées par les Développeurs lors du Sprint Planning pour accomplir les PBIs sélectionnés. Cette distinction reflète la séparation des responsabilités entre le Product Owner (qui définit ce qu'il faut construire) et les Développeurs (qui planifient la façon de le construire).

Pourquoi les autres réponses sont incorrectes : Les PBIs et les éléments du Sprint Backlog ne sont pas identiques ni interchangeables. Le Product Owner crée les PBIs tandis que les Développeurs créent les tâches du Sprint Backlog. Les différences d'estimation varient également selon les organisations, mais les story points servent généralement à estimer les PBIs tandis que les heures peuvent servir à estimer les tâches — et non l'inverse.

Concept clé : La séparation des rôles et l'auto-organisation dans Scrum. Le Product Owner est responsable du « quoi » et du « pourquoi » — définir les objectifs du produit, prioriser le Backlog et clarifier la valeur métier. Les Developers sont responsables du « comment » — décider des approches techniques, de l'architecture et des détails d'implémentation. Le fait que le Product Owner dicte les solutions techniques enfreint le principe d'auto-organisation des Developers dans Scrum, compromet leur expertise et crée des dépendances qui réduisent l'agilité. Bien que le Product Owner puisse solliciter certaines considérations techniques pour des raisons métier, les Developers conservent l'autonomie de choisir la meilleure voie technique à suivre. Cette séparation garantit que les parties prenantes métier et les équipes techniques se concentrent chacune sur leur domaine d'autorité, ce qui conduit à de meilleures décisions et à des résultats de meilleure qualité.

La Sprint Retrospective est spécifiquement conçue pour que l'équipe Scrum inspecte ses processus et ses interactions, en identifiant ce qui s'est bien passé et ce qui pourrait être amélioré lors des prochains Sprints. C'est la seule réponse qui décrit avec précision l'objectif de l'événement Retrospective. Les autres options décrivent différents événements ou activités Scrum : la démonstration de l'Increment a lieu lors de la Sprint Review, le Product Owner gère la priorisation du Backlog de façon continue (et non pendant la Retrospective), et le Scrum Master n'assigne pas de tâches — c'est l'équipe de développement qui s'auto-organise dans son travail.

Pourquoi cette réponse est correcte : « Potentiellement livrable » signifie que l'Incrément est dans un état où il pourrait être livré si le Product Owner choisit de le faire. Il doit respecter la Definition of Done et être pleinement utilisable, mais la décision de livraison effective appartient au Product Owner en fonction des priorités métier.

Pourquoi les autres réponses sont incorrectes : La première option suggère à tort une livraison obligatoire après chaque Sprint — c'est le Product Owner qui contrôle le moment de la livraison, pas l'équipe. La troisième option confond « livrable » avec l'absence totale de défauts, alors que la Definition of Done garantit déjà le respect des standards de qualité. La quatrième option introduit une validation supplémentaire inutile ; la livrabilité est déterminée par le respect de la Definition of Done, et non par une approbation du client.

Concept clé : Le Sprint Goal en tant que mécanisme d'engagement flexible. Le Sprint Goal est un objectif unique que l'équipe Scrum s'engage à atteindre durant le Sprint, mais il ne prescrit intentionnellement PAS les éléments exacts du Product Backlog nécessaires pour l'accomplir. Cette flexibilité est fondamentale dans l'approche empirique de Scrum. Au cours du Sprint, l'équipe peut découvrir que certains éléments sont inutiles, que d'autres nécessitent des modifications, ou que des éléments alternatifs servent mieux le Sprint Goal. Le Product Owner et l'équipe Scrum peuvent négocier le périmètre — en supprimant, ajoutant ou réordonnant des éléments — à condition que ces changements préservent l'intention et la valeur du Sprint Goal. Cela diffère de la gestion de projet traditionnelle où le périmètre est généralement fixé dès le début. Le Sprint Goal reste l'engagement stable ; le périmètre (les éléments complétés) devient la variable. Cette conception permet aux équipes de s'adapter aux apprentissages et aux évolutions de contexte tout en maintenant l'alignement et la direction stratégiques. Sans cette flexibilité de périmètre associée à un Sprint Goal fixe, les équipes seraient contraintes soit d'abandonner leur objectif, soit de réaliser des travaux inutiles.

Réponse : Chaque Sprint doit progresser vers le Product Goal.
Explication : Chaque Sprint rapproche le produit du Product Goal. Les Sprints n'ont pas besoin d'atteindre pleinement le Product Goal à chaque fois.

L'Objectif Produit est l'objectif à long terme de la Scrum Team et constitue un engagement associé au Product Backlog. Le partager aide l'équipe à se concentrer sur la direction stratégique plutôt que de traiter les Sprints comme des tâches isolées. Cela rend également l'inspection lors de la Sprint Review plus significative et permet à l'équipe d'évaluer ses décisions par rapport à un objectif commun. Remarque : l'estimation des dates d'achèvement n'est pas un bénéfice de l'Objectif Produit — Scrum évite les prévisions déterministes.

Réponse : Les story points, le burndown chart, la Definition of Ready.
Explication : Seuls le Daily Scrum (et les autres événements Scrum) sont prescrits. Les story points, les burndowns et le DoR sont des pratiques optionnelles.

Suivi des bénéfices dans le cycle de vie du projet : Le suivi des bénéfices est un processus continu qui s'étend bien au-delà de la clôture du projet. Selon le PMBOK 7e édition, la réalisation des bénéfices est un élément fondamental de la gestion de projet, car les projets sont menés pour créer de la valeur. Ce suivi débute dès les phases initiales du projet avec la définition claire des bénéfices attendus, continue tout au long de l'exécution pour vérifier que les livrables créent effectivement la valeur prévue, et se prolonge après la clôture administrative pour mesurer si les bénéfices promis ont réellement été atteints. Cette approche longitudinale est cruciale car de nombreux bénéfices ne se manifestent que longtemps après la livraison des livrables (amélioration de la productivité, retour sur investissement, satisfaction client durables). Les autres affirmations sont incorrectes : limiter le suivi à la seule clôture ignore la majorité du cycle de vie et empêche les ajustements ; déléguer au seul commanditaire dès le démarrage contournerait la responsabilité du gestionnaire de projet ; enfin, le suivi des bénéfices complète plutôt qu'il ne remplace le contrôle qualité,

Indicateurs de Performance : Le CPI (Indice de Performance des Coûts) mesure l'efficacité budgétaire. CPI = 0,9 signifie que chaque euro dépensé ne produit que 0,9€ de valeur (dépassement de 10%). Le SPI (Indice de Performance du Calendrier) = 1,1 indique que le projet progresse 10% plus vite que prévu. Le projet est donc simultanément en surcoût et en avance.

Gestion des changements formelle : Toute exigence supplémentaire doit être évaluée pour son impact sur la triple contrainte (délai, coût, qualité). L'analyse permet au comité de pilotage de prendre une décision éclairée : accepter le changement en ajustant les contraintes, ou le refuser. Cela évite les surcharges non contrôlées et protège le projet, contrairement à l'intégration immédiate qui génère des dérives ou au rejet brutal qui mécontente le client.

Crashing : technique de compression d'échéancier consistant à ajouter des ressources (budget, personnel, équipement) aux activités du chemin critique pour réduire la durée totale du projet. Contrairement au fast-tracking qui réorganise les dépendances (risqué et parfois impossible), le crashing augmente directement les ressources affectées aux tâches critiques, garantissant une réduction mesurable du délai tout en acceptant une augmentation de coûts. Cette approche est idéale quand un sponsor exige une accélération urgente et que le budget peut être augmenté. Le fast-tracking (parallélisation) peut créer des risques en chevauchant des tâches normalement séquentielles. La simulation Monte Carlo analyse la probabilité de délais mais ne réduit pas la durée. Le PERT est une technique d'estimation, non de compression. Selon le PMBOK 7e édition, le crashing reste la technique privilégiée pour gagner du temps rapidement sur un projet critique en contrepartie d'une hausse budgétaire acceptée par le sponsor.

Transfert du risque : confier la responsabilité d'un risque à un tiers (prestataire, assureur) via contrat. L'externalisation transfère le risque au fournisseur, contrairement à l'atténuation (réduire l'impact) ou l'acceptation (tolérer le risque).

Gestion des risques réalisés et plans de contingence : Un risque réalisé est un événement d'incertitude qui s'est matérialisé et impacte le projet. Selon le PMBOK 7e édition, la gestion des risques inclut l'identification des risques potentiels lors de la planification, et la définition de plans de contingence (réponses préplanifiées). Lorsque la panne d'outil critique survient, c'est précisément le moment de déclencher le plan de contingence préalablement documenté. Cette approche proactive demontre une maîtrise disciplinée du projet : le chef de projet n'improvise pas, mais exécute une stratégie de réponse anticipée. Mettre en œuvre ce plan stabilise le projet et limite les dégâts. Parallèlement, informer les parties prenantes est obligatoire pour maintenir la transparence, gérer les attentes et préserver la confiance. Les autres options sont contre-productives : ignorer le problème (option 2) aggrave le retard sans le résoudre; accuser l'équipe (option 3) est une réaction émotionnelle qui ne corrige rien; arrêter le projet (option 4) est disproportionné sans exploration d'alternatives. La bonne réponse aligne donc planification des risques, exécution du plan d'action et communication stakeholder, trois

Code d'éthique et de conduite professionnelle du PMI : Le PMI établit quatre valeurs fondamentales (Responsabilité, Respect, Équité et Honnêteté) qui constituent le socle de la conduite professionnelle des chefs de projet. Agir avec intégrité signifie être honnête dans toutes les communications, respecter ses engagements et prendre des décisions basées sur les principes éthiques plutôt que sur des intérêts personnels. Respecter la confidentialité exige de protéger les informations sensibles de l'organisation et des parties prenantes, conformément aux accords légaux et contractuels. Éviter les conflits d'intérêts implique de déceler et de déclarer toute situation où vos intérêts personnels pourraient influencer votre jugement professionnel.

Pourquoi cette réponse est correcte : Ces trois comportements reflètent directement le cadre éthique du PMI. Un chef de projet intègre gagne la confiance de son équipe et des parties prenantes, fondamentale pour la réussite du projet. Le PMBOK 7e édition renforce cette approche en mettant l'accent sur la performance de domaine incluant l'éthique.

Intégration Continue : pratique d'automatiser l'intégration du code plusieurs fois par jour pour détecter les incompatibilités immédiatement. Cela prévient l'accumulation de défauts d'intégrabilité qui apparaissent tardivement. Les Scrum of Scrums améliorent la communication mais pas la détection technique. Une QA parallèle identifie les bugs existants sans prévention. L'intégration manuelle reste tardive et coûteuse.

Cette question correspond à l\'objectif d\'apprentissage FL-4.4.1 (K2) - Expliquer l\'estimation d\'erreurs.

● a) Faux → Cette réponse simplifie excessivement l\'utilisation de l\'estimation d\'erreurs en appliquant un \"seuil standard\" arbitraire de 80%. L\'estimation d\'erreurs ne se limite pas à un pourcentage fixe et ne peut pas, à elle seule, déterminer si les tests doivent être arrêtés. De plus, le calcul ignore les 40 défauts supplémentaires découverts, ce qui porterait le total à 390 défauts identifiés.
● b) Faux → Ce n’est pas une conclusion fiable. Le fait de trouver 40 défauts en deux semaines n\'indique pas nécessairement une inefficacité des tests. La détection des défauts n\'est généralement pas linéaire, et le taux peut varier selon les phases de test.
● c) Faux → L’estimation d’erreurs donne une fourchette (ici 410–480), et les 40 nouveaux défauts sont encore dans cette fourchette. Le modèle reste valide, il faut juste le réévaluer progressivement, pas le rejeter
● d) Correct → Cette réponse reflète avec précision la valeur et les limites de l\'estimation d\'erreurs. L\'estimation fournit une base quantitative pour évaluer la progression des tests, mais ne doit pas être utilisée comme seul critère de décision pour arrêter les tests. D\'autres facteurs qualitatifs comme la sévérité des défauts restants, la couverture des risques métier, et les contraintes de projet doivent également être pris en compte. Cette approche équilibrée est particulièrement importante pour un système critique comme un système d\'information sur la santé.

Cette question correspond à l’objectif d’apprentissage FL-1.5.3 (K2) – Distinguer les avantages et les inconvénients de l\'indépendance du test.

● a) Correct → Une équipe trop indépendante peut manquer d’informations essentielles sur le produit et son contexte d’utilisation.
● b) Faux → Une plus grande objectivité est un avantage, et non un inconvénient.
● c) Faux → Une séparation trop marquée peut au contraire augmenter les conflits entre testeurs et développeurs.
● d) Faux → Une équipe totalement indépendante n’accélère pas forcément les tests, cela dépend de l’organisation en place.

Cette question correspond à l\'objectif d\'apprentissage FL-4.4.1 (K2) – Expliquer les
techniques de test basées sur l\'expérience et leur utilisation.
● a) Faux → La rédaction de cas de test détaillés nécessite une documentation
complète, ce qui n\'est pas disponible ici.
● b) Correct → Les tests exploratoires permettent de découvrir rapidement des
défauts même en l\'absence de documentation détaillée.
● c) Faux → Attendre la documentation complète retarderait inutilement le processus
de test.
● d) Faux → L\'automatisation nécessite une connaissance préalable des cas de test et
du comportement attendu, ce qui n\'est pas possible sans documentation.

Cette question correspond à l’objectif FL-5.2.4 (K2) – Expliquer les mesures qui peuvent être prises en réponse à l\'analyse des risques produit.

La réponse correcte est a) 1B, 2D, 3A, 4C

● 1B) Correct →Risque de plantage dû à la charge → test de performance pour valider le comportement du système en situation de stress.

● 2D) Correct → Changement imposé par une source externe (nouvelle règle) → ce risque peut être transféré (ex. vers les juristes ou MOA).

● 3A) Correct → Une panne électrique peut être rare et incontrôlable → acceptation du risque si aucune action n’est envisageable en test.

4C) Correct → Mauvaise attribution de droits → peut être testé avecpartitionnement d’équivalence (groupes autorisés vs interdits).

Cette question correspond à l\'objectif d\'apprentissage FL-6.2.1 (K1) - Rappeler les avantages et les risques de l\'automatisation des tests.

● a) Faux → L\'automatisation n\'améliore pas nécessairement la qualité de conception des cas de test, qui dépend davantage des compétences des testeurs.
● b) Correct → Le principal avantage de l\'automatisation des tests de régression est qu\'elle permet d\'exécuter rapidement un grand nombre de tests qui doivent être
répétés fréquemment.
● c) Faux → L\'automatisation des tests ne garantit pas l\'absence de défauts, elle permet seulement de détecter ceux pour lesquels des tests ont été écrits.
● d) Faux → L\'automatisation ne remplace pas complètement les tests manuels, qui restent nécessaires pour certains aspects comme les tests exploratoires

Cette question correspond à l’objectif d’apprentissage FL-1.2.3 (K2) – Expliquer la relation entre erreur, défaut et défaillance.
● a) Faux → Une erreur est une faute humaine qui peut introduire un défaut, mais ce n’est pas une anomalie détectée en production.
● b) Faux → Un défaut peut exister sans être visible par l’utilisateur final.
● c) Correct → Une erreur humaine peut entraîner un défaut dans le logiciel, qui peut causer une défaillance en production
● d) Faux → Une défaillance est une anomalie observée lors de l’exécution, pas un problème directement présent dans le code source.

Cette question correspond à l\'objectif d\'apprentissage FL-4.2.1 (K3) - Appliquer le partitionnement en classes d\'équivalence pour dériver des cas de test.

● a) Correct → Pour couvrir toutes les classes d\'équivalence valides, nous avons besoin de tester : (économique, pas de vue), (économique, vue partielle), (standard,
pas de vue), (standard, vue partielle), (luxe, pas de vue), (luxe, vue partielle), et (luxe, vue panoramique). Cependant, comme seuls les hôtels de luxe peuvent avoir une vue panoramique, et que le formulaire a une validation qui empêche les
combinaisons invalides, nous pouvons couvrir toutes les classes valides avec 3 cas de test : (économique, pas de vue), (standard, vue partielle), et (luxe, vue panoramique).
● b) Faux → Trois cas de test suffisent pour couvrir toutes les classes d\'équivalence valides.
● c) Faux → Trois cas de test suffisent pour couvrir toutes les classes d\'équivalence valides.
● d) Faux →. Trois cas de test suffisent pour couvrir toutes les classes d\'équivalencevalides.

Cette question correspond à l’objectif d’apprentissage FL-1.1.1 (K1) – Identifier les objectifs habituels du test.
● a) Faux → Il est impossible de démontrer qu’un logiciel est totalement exempt de défauts.
● b) Correct → Les tests réduisent le risque de défauts et augmentent la probabilité que le logiciel réponde aux exigences.
● c) Faux → Vérifier la conformité aux spécifications est une partie des tests, mais pas leur seul objectif.
● d) Faux → Les tests ne remplacent pas l’assurance qualité, qui inclut d’autres activités comme l’analyse des processus.

Cette question correspond à l’objectif d\'apprentissage FL-4.2.2 (K3) – Appliquer l’analyse des valeurs limites pour identifier les cas de test.
● a) Faux → 23 et 27 : limites extérieures uniquement
● b) Faux → 24 et 26 : limites valides, pas d’extérieures
● c) Correct → 23, 24, 26, 27 : couvre toutes les limites valides et invalides
● d) Faux → 22, 24, 26, 28 : trop éloigné des limites directes

Cette question correspond à l’objectif d’apprentissage FL-3.2.4 (K2) – Comparer et opposer les différents types de revues.
La bonne réponse est d) 1B, 2A, 3C, 4D
● 1B) Correct → Une revue informelle ne suit pas de processus strict.
● 2A) Correct → L’inspection est une revue très structurée avec un modérateur et des
checklists.
● 3C) Correct → Une revue technique implique des experts métier ou techniques pour
examiner un document.
● 4D) Correct → La revue par les pairs est une analyse collaborative des documents.

Smishing : Attaque de phishing par SMS dans laquelle des messages texte frauduleux incitent les utilisateurs à effectuer des actions telles que l'achat de cartes-cadeaux. Se distingue du phishing (e-mail), du vishing (appels vocaux) et du pretexting (ingénierie sociale sans recours à la technologie) par le fait qu'il utilise spécifiquement les messages texte comme vecteur d'attaque.

Responsabilité des actifs : Étiqueter les ordinateurs portables et les associer aux identifiants des employés établit une propriété claire et une traçabilité. Cela permet aux équipes de réponse aux incidents d'identifier rapidement les utilisateurs concernés et d'enquêter sur les violations de sécurité. Contrairement aux politiques de pare-feu ou à l'automatisation de la gestion des correctifs, le suivi des actifs soutient directement la responsabilisation et la notification des employés lors d'incidents.

Système de Détection d'Intrusion (IDS) : Un outil de sécurité réseau qui surveille le trafic en temps réel afin d'identifier les comportements suspects et les tentatives d'intrusion potentielles. Contrairement aux pare-feux qui bloquent le trafic, l'IDS analyse passivement le comportement du réseau pour détecter les menaces. Les antivirus ciblent les fichiers et le chiffrement protège la confidentialité des données — aucun de ces deux outils ne fournit une surveillance active des menaces.

Réduction de la surface d'attaque : La désactivation des services inutiles élimine les points d'entrée non utilisés avant toute autre mesure de durcissement. Chaque service actif représente une exposition potentielle aux vulnérabilités. Cette étape fondamentale doit précéder les correctifs, les pare-feux ou les mots de passe — la suppression des services inutilisés empêche les attaquants de les exploiter, tandis que les autres options se contentent de sécuriser les surfaces d'attaque existantes.

Sauvegardes régulières : Une sauvegarde est une copie des données stockée séparément de l'original. Les défaillances matérielles (pannes de disque, corruption) détruisent les données primaires ; les sauvegardes permettent de les restaurer. L'antivirus prévient les logiciels malveillants, les pare-feu bloquent les attaques réseau et le chiffrement protège la confidentialité des données — aucune de ces mesures ne permet de récupérer des données perdues suite à une défaillance matérielle.

Réponse : Le crime organisé.
Explication : Les acteurs étatiques ciblent généralement les infrastructures critiques d'autres pays, mais les groupes de crime organisé sont souvent engagés comme intermédiaires pour assurer une plausible dénégation. Le crime organisé possède les capacités techniques et la motivation financière pour mener des attaques commanditées par des États contre rémunération.

Réponse : Relancer une analyse du réseau.
Explication : Après avoir remédié aux vulnérabilités, l'étape suivante consiste à vérifier l'efficacité des correctifs en effectuant une nouvelle analyse. Cela clôt le cycle de gestion des vulnérabilités, en confirmant que toutes les vulnérabilités identifiées ont été résolues avec succès.

Classification des contrôles techniques : Un pare-feu est un contrôle technique (préventif) — il utilise la technologie pour bloquer le trafic réseau non autorisé avant qu'il n'atteigne les systèmes. Contrairement aux contrôles administratifs (politiques/procédures), aux contrôles physiques (verrous/barrières) ou aux contrôles de détection (surveillance/alertes), les pare-feux préviennent activement les menaces grâce à des mécanismes matériels et logiciels.

Attaque d'ingénierie sociale : Manipulation des utilisateurs pour les pousser à effectuer des actions dangereuses par des tactiques psychologiques plutôt que par des exploits techniques. Trouver une clé USB dans un parking est une technique d'appâtage classique — les attaquants placent intentionnellement des dispositifs pour exploiter la curiosité humaine. Contrairement à la sécurité physique (qui traite du contrôle d'accès), cette méthode exploite le comportement humain et la confiance.

Injection SQL : attaque exploitant des champs de saisie non sécurisés pour injecter des commandes SQL malveillantes, permettant un accès non autorisé à la base de données, la manipulation ou la consultation de données. Les attaquants contournent l'authentification en insérant du code dans les entrées utilisateur. Contrairement au cross-site scripting (qui cible les navigateurs), l'injection SQL cible directement les bases de données dorsales.

Normalisation en base relationnelle : processus d'organisation des données en tables séparées pour éliminer les redondances et incohérences. Objectif : chaque donnée existe une seule fois, réduisant l'espace disque et évitant les anomalies de mise à jour. Contrairement aux idées reçues, la normalisation ne garantit pas des requêtes plus rapides (les jointures peuvent ralentir) ni n'ajoute automatiquement des colonnes.

Modèle PaaS d'Azure SQL Database : Microsoft, en tant que fournisseur cloud, gère entièrement l'infrastructure, le moteur SQL et les mises à jour de sécurité. Le client ne s'occupe que des données et de l'application. Contrairement à un serveur on-premises, l'administrateur réseau n'intervient pas sur les patchs du moteur SQL.

DAX (Data Analysis Expressions) : langage propriétaire de Microsoft conçu spécifiquement pour Power BI et Analysis Services. Il permet de créer des mesures (calculs dynamiques) et colonnes calculées (valeurs statiques) à partir de données multidimensionnelles. SQL interroge des bases de données relationnelles, Python et R sont des langages de programmation généraux non intégrés nativement à Power BI pour cette fonction.

Réponse : Online Transaction Processing (OLTP). Explication : Les applications e-commerce effectuent des transactions fréquentes et petites de lecture/écriture (placement de commandes, mises à jour d'inventaire, recherches de clients) — la caractéristique déterminante d'OLTP. OLAP serait utilisé pour les rapports analytiques sur les données historiques agrégées.

Cohérence : propriété garantissant que la base de données passe d'un état valide à un autre état valide après chaque transaction. Elle vérifie que toutes les contraintes d'intégrité (clés primaires, clés étrangères, règles métier) sont respectées. Contrairement à l'atomicité (tout ou rien), l'isolation (concurrence) ou la durabilité (persistance), la cohérence assure la validité logique des données.

DELETE vs DROP : DELETE supprime des lignes spécifiques (ou toutes les lignes) d'une table tout en conservant sa structure. DROP supprime l'intégralité de la table, y compris sa structure. REMOVE et ERASE ne sont pas des commandes SQL standards. DELETE est donc la seule commande appropriée pour supprimer des données lignes par lignes.

Réponse : Atomicité. Explication : L'atomicité est le « A » dans les propriétés ACID des bases de données transactionnelles. Elle garantit qu'une transaction est traitée comme une unité indivisible — soit toutes les opérations réussissent (commit), soit toutes échouent (rollback), sans exécution partielle.

Réponse : CREATE. Explication : Les instructions DDL (Data Definition Language) définissent et modifient la structure de la base de données : CREATE (créer des objets), ALTER (modifier des objets), DROP (supprimer des objets), TRUNCATE (vider des tables). CREATE est un exemple classique de DDL — il crée des objets de base de données comme les tables, les vues et les index.

Concept clé : ALTER modifie la structure. La commande ALTER permet de modifier le schéma d'une table (ajouter, supprimer ou renommer des colonnes, modifier des types de données). À distinguer : UPDATE change les données existantes, INSERT ajoute des lignes, SELECT interroge les données. ALTER agit sur la définition de la table elle-même, pas sur son contenu.

Index dans une base relationnelle : structure de données qui organise les valeurs d'une ou plusieurs colonnes pour accélérer la localisation des enregistrements. Sans index, le moteur doit scanner chaque ligne (table scan). Avec un index, il utilise une structure optimisée (arbres B) pour retrouver les données en quelques accès disque seulement, d'où une amélioration drastique de performance. À ne pas confondre avec la suppression de redondance (normalization), l'unicité (contrainte unique) ou la sécurité (transactions ACID).

Réponse : Mappe les opérations AA vers des comptes GL par classe et zone
La détermination des comptes en AA (Account Determination) configure les comptes G/L à débiter/créditer pour chaque type d'opération (acquisition, amortissement, cession) selon la classe d'immobilisation et la zone de dépréciation. Configuration via transaction AO90.

Réponse : Exécuter l’amortissement ; Examiner les AUC et règlements ; Revue de l’Asset History Sheet ; Vérifier les cessions et transferts de période.
Explication : Ces activités garantissent l’exhaustivité et la correcte valorisation des actifs.

Réponse : Variante d'exercice fiscal ; plan comptable d'exploitation. Explication : Pour que plusieurs sociétés partagent une zone de contrôle de gestion, elles doivent utiliser la même variante d'exercice fiscal (même calendrier financier) et le même plan comptable d'exploitation (même structure de compte du grand livre) pour assurer une présentation financière cohérente.

Réponse : In‑app key‑user (Custom Fields & Logic, adaptation UI) ; BAdI/API publiés (« released ») ; Side‑by‑side sur SAP BTP via services OData/événements.
Explication : Le clean core évite les modifications du standard : on favorise les extensions in‑app ou latérales via BTP et API stables.

Réponse : Un acompte (down payment)
Les Special G/L Indicators permettent de gérer des opérations spéciales AP/AR sur des comptes G/L séparés, sans affecter les comptes de réconciliation normaux. L'acompte (Down Payment) est l'exemple classique : il utilise un compte G/L spécial pour distinguer les acomptes versés des factures ouvertes ordinaires.

Réponse : Un transfert intra-société peut ajuster la base d’amortissement ; Un transfert inter-sociétés utilise un processus dédié ; L’historique des valeurs est conservé dans ACDOCA.
Explication : Les transferts déplacent la VNC/valeurs et préservent la traçabilité.

Réponse : Vrai
Explication : Le mandat SEPA (type CORE/B2B) est requis pour débiter le compte du client.

Réponse : Financial Closing Cockpit (Fiori).
Explication : Le FCC fournit des modèles, des listes de tâches, des dépendances et un suivi d’exécution pour les clôtures périodiques et annuelles.

Réponse : GGB1
La transaction GGB1 (Validations) permet de définir des règles de validation qui vérifient les données saisies dans les documents comptables avant leur enregistrement. Par exemple : bloquer une écriture si un compte de charges est utilisé avec un centre de profit non autorisé. C'est un outil de contrôle de saisie en temps réel.

Réponse : Ils se mettent à jour automatiquement via les sous-comptes BP
Les comptes de réconciliation (reconciliation accounts) sont des comptes G/L spéciaux qui ne peuvent pas être saisis directement. Ils sont alimentés automatiquement lors de la comptabilisation sur les comptes clients ou fournisseurs (sous-comptes Business Partner), assurant ainsi la cohérence entre les sous-livres et la comptabilité générale.

Réponse : S\'assurer que les fournisseurs de l\'organisation et leurs performances sont gérés de manière appropriée afin de supporter l\'approvisionnement continu de produits et services de qualité.
Explication : La gestion des fournisseurs assure que les relations avec les fournisseurs externes sont correctement gérées pour garantir un approvisionnement continu en produits et services de qualité.

Réponse : Rôles et responsabilités.
Explication : La dimension \'Information et technologie\' couvre les données, systèmes d\'information et outils. Les rôles et responsabilités appartiennent à la dimension \'Organisations et personnes\'.

Réponse : Le centre de services.
Explication : Le centre de services constitue le point de contact unique (SPOC) entre le fournisseur de services et les utilisateurs pour toutes les communications, demandes et incidents.

Réponse : Les principes directeurs peuvent guider une organisation en toutes circonstances.
Explication : Les principes directeurs ITIL 4 sont universels et s\'appliquent en toutes circonstances, à toute organisation et tout type de projet ou initiative, quelle que soit la situation.

Réponse : les résultats.
Explication : Selon ITIL 4, un service est un moyen de co-créer de la valeur en facilitant les résultats que les clients souhaitent atteindre, sans qu\'ils aient à gérer les coûts et risques spécifiques.

Réponse : Chaque activité de la chaîne de valeur contribue à la chaîne de valeur en transformant des entrées spécifiques en livrables.
Explication : Chaque activité de la chaîne de valeur transforme des entrées en livrables spécifiques. Les activités ne sont pas séquentielles mais s\'interconnectent selon les besoins pour créer de la valeur.

Réponse : 1 et 4.
Explication : La résolution d\'un problème implique l\'amélioration continue (identifier et éliminer la cause) et le contrôle des changements (implémenter la correction de manière contrôlée et sécurisée).

Réponse : Pour planifier les changements et éviter les conflits.
Explication : Le calendrier des changements sert principalement à planifier les changements et à prévenir les conflits entre eux, en offrant une vue consolidée de tous les changements prévus.

Réponse : La gestion des niveaux de service.
Explication : La gestion des niveaux de service définit et suit les métriques reflétant l\'expérience réelle du client, en établissant des accords sur la qualité du service fourni.

Réponse : Penser et travailler de façon holistique.
Explication : Le principe \'Penser et travailler de façon holistique\' recommande de prendre en compte les quatre dimensions de la gestion des services pour éviter une vision en silos.

• Dynamics 365 Sales est une solution SaaS conçue pour :

  • Gérer les prospects et clients

  • Suivre les opportunités commerciales

  • Centraliser les interactions avec les clients

• Elle ne nécessite pas de déploiement d’infrastructure, tout est géré dans le cloud par Microsoft.

  🎯 À retenir pour l’examen MS-900 :

  • Dynamics 365 Sales = SaaS pour la gestion commerciale complète

  • Azure SQL ou Functions = nécessitent une application personnalisée pour gérer les ventes.

  • Power BI = visualisation des données, pas gestion opérationnelle des ventes.

💡 Explication :

• Defender for Cloud Apps permet de surveiller les activités des utilisateurs dans les applications SaaS.

• Avec une politique d’activité + règles de détection d’anomalies, vous pouvez :

  • Détecter des comportements inhabituels (ex : partage massif de fichiers)

  • Définir un seuil et déclencher une alerte automatique lorsque ce seuil est dépassé

    🎯 À retenir pour l’examen MS-900 :

    • Alertes automatiques sur activités SaaS = Activity policy + anomaly detection dans Defender for Cloud Apps.

    • L’accès conditionnel et Sentinel peuvent compléter, mais ne remplacent pas cette fonctionnalité.

• Co-authoring permet à plusieurs utilisateurs de :

  • Modifier un même fichier PowerPoint simultanément

  • Voir en temps réel les modifications des autres collaborateurs

• Les autres options ne permettent pas la collaboration en temps réel :

  • A : Presenter View sert à l’affichage du présentateur lors d’une présentation.

  • B : Version History permet de voir ou restaurer des versions précédentes, pas la coédition en temps réel.

  • D : Slide Show affiche le diaporama mais ne gère pas l’édition collaborative.

• Proactive Remediations permet de :

  • Détecter les appareils affectés par un problème spécifique (via des scripts de détection)

  • Appliquer automatiquement des scripts de correction ou empêcher l’installation d’un pilote problématique

• Les autres options ne bloquent pas activement les mises à jour problématiques :

  • A : Startup Performance report analyse les temps de démarrage, pas les pilotes

  • C : Health Metrics fournit des scores de santé des appareils mais ne permet pas de remediation proactive

  • D : Recommended Actions exporte des suggestions, mais ne bloque rien automatiquement

• Microsoft Secure Score se trouve dans le Microsoft 365 security center.

• Il permet de :

  • Voir le score actuel de sécurité de l’organisation

  • Accéder à des recommandations et actions pour améliorer la sécurité

• Les autres options ne donnent pas l’accès complet à Secure Score :

  • A : Azure AD Security montre certains paramètres, mais pas le score complet Microsoft 365.

  • C : Microsoft 365 admin center > Reports ne fournit pas le Secure Score détaillé.

  • D : Defender for Endpoint montre le posture de sécurité endpoints, pas le score global Microsoft 365.

Dans Microsoft Lists, la mise en forme de colonne (Column formatting) permet d’appliquer un style visuel conditionnel à une colonne spécifique.

👉 Elle permet notamment :

• De modifier la couleur d’arrière-plan

• De changer la couleur du texte

• D’ajouter des icônes

• D’appliquer des règles conditionnelles (ex : si la valeur < seuil → fond rouge)

Cette fonctionnalité utilise du JSON en arrière-plan, mais du point de vue fonctionnel, la capacité recherchée est bien la mise en forme de colonne.

Dans Microsoft Viva Goals, il est possible de contrôler la visibilité des objectifs (Goals) et des OKR en configurant des autorisations au niveau de l’équipe ou de l’objectif.

👉 Les contrôles d’accès basés sur l’équipe permettent :

• De limiter la visibilité d’un objectif à une équipe spécifique (par exemple : Finance)

• D’empêcher les autres utilisateurs de l’organisation d’y accéder

• De garantir la confidentialité des OKR sensibles

C’est la méthode appropriée pour gérer la visibilité directement dans Viva Goals.

• Dans Teams, la messagerie vocale est liée à la boîte aux lettres Exchange Online.

• Même sans licence Phone System, Teams peut délivrer les messages vocaux dans la boîte aux lettres Exchange Online.

• Les autres options :

  • B : Teams Premium ajoute des fonctionnalités avancées, pas nécessaire pour la messagerie vocale basique.

  • C : Phone System est requis uniquement pour passer/recevoir des appels via le PSTN.

  • D : Power Automate ne gère pas la messagerie vocale Teams nativement.

• La section Token Usage :

  • Montre le nombre total de tokens AI utilisés par votre organisation sur une période donnée.

  • Permet de suivre l’utilisation et estimer les coûts liés à l’usage de Copilot.

• Les autres sections ne fournissent pas cette information :

  • User Engagement → suit l’activité des utilisateurs avec Copilot.

  • Prompt Library → contient les prompts enregistrés et réutilisables.

  • Security Insights → fournit des informations de sécurité et de conformité.

    🎯 À retenir pour l’examen MS-900 :

    • Token Usage = suivi de la consommation de tokens et des coûts Copilot

    • Les autres sections se concentrent sur activité utilisateur, sécurité ou prompts.

• Pour pouvoir réclamer un crédit SLA, il est essentiel de documenter immédiatement toute interruption et de la comparer aux seuils définis dans le SLA.

• Sans preuves précises et horodatées, Microsoft peut rejeter la demande, même si le service a été interrompu.

• Les autres options ne résolvent pas le problème de suivi et documentation :

  • Automatiser les crédits (B) n’est pas possible.

  • Migrer vers un autre tenant (C) est excessif et non nécessaire.

  • Configurer des alertes (D) aide à la notification mais ne remplace pas la documentation des interruptions.

• Problème : les applications legacy utilisent souvent des protocoles d’authentification non sécurisés (ex : IMAP, POP3, SMTP Auth)

• Ces protocoles contournent Conditional Access, ce qui crée une surface d’attaque importante

• Solution Microsoft recommandée pour Zero Trust :

  • Bloquer la legacy authentication dans Conditional Access

  • Appliquer MFA et autres contrôles modernes uniquement sur les applications et utilisateurs qui supportent les protocoles modernes

  • Réduire considérablement le risque de compromission des identités

• CIEM (Cloud Infrastructure Entitlement Management) se concentre sur :

  • Découverte des droits et rôles dans les environnements cloud (AWS, Azure, GCP)

  • Analyse de l’usage des permissions pour identifier :

    • Les comptes avec permissions inutilisées

    • Les droits à haut risque accumulés inutilement

• Cette approche permet de détecter la sur-privatisation et de prévenir les risques d’escalade de privilèges ou d’accès abusif, ce qui est exactement l’objectif de la question.

• Scenario : Zero Trust → contrôler l’accès en fonction de l’état de l’appareil, de l’identité et de la localisation.

• Intune + Conditional Access permet :

  • Vérifier si l’appareil est géré et conforme aux politiques de sécurité

  • Appliquer des conditions préalables à l’accès, comme :

    • BitLocker activé

    • Antivirus à jour

    • Correctifs appliqués

  • Bloquer l’accès depuis appareils non conformes

• C’est la méthode standard Microsoft pour protéger Microsoft 365 dans un contexte Zero Trust avec des partenaires externes.

• ISO 27001 exige, entre autres :

  • Le contrôle strict des privilèges élevés

  • L’auditabilité et la traçabilité de l’accès aux ressources sensibles

• Azure AD PIM :

  • Fournit un accès Just-in-Time aux rôles à privilèges élevés

  • Chaque activation est journalisée et auditable

  • Permet de réduire le risque de sur-privatisation et de répondre aux exigences ISO 27001 sur le contrôle d’accès

• CAF DevSecOps recommande d’intégrer la sécurité et la conformité dès la phase de conception et de déploiement.

• Azure Blueprints permet de :

  • Appliquer des politiques et des contrôles RBAC cohérents sur plusieurs souscriptions

  • Garantir que toutes les ressources déployées respectent les standards internes et réglementaires

  • Automatiser la conformité dès la création de l’infrastructure (Infrastructure as Code)

• Cela offre une remédiation et un contrôle centralisé, ce qui répond directement aux exigences de gouvernance DevSecOps.

L’organisation demande :

• Visibilité centralisée et monitoring sur tous les environnements

• Alertes automatisées pour les ressources non conformes

Dans le Cloud Adoption Framework (CAF) pour Azure :

• Le domaine Management se concentre sur la supervision opérationnelle, le monitoring, la collecte de logs et la configuration d’alertes automatisées.

• Bien que la conformité et les standards fassent partie de la gouvernance, cette exigence met l’accent sur la gestion opérationnelle et la surveillance continue.

✅ Donc, le domaine CAF approprié pour cette exigence est : Management.

Azure Key Vault est un composant critique pour la sécurité :

• Il stocke des clés cryptographiques, certificats et secrets essentiels pour le chiffrement des données et la sécurité des transactions.

• Le vecteur de menace le plus critique est l’accès non autorisé :

  • Si un attaquant obtient l’accès à Key Vault, il peut récupérer les clés et décrypter les données sensibles ou signer des transactions frauduleuses.

• La protection contre ce vecteur repose sur :

  • Des politiques d’accès strictes (RBAC ou policies Key Vault)

  • L’activation de Azure AD Conditional Access

  • L’utilisation du principle du moindre privilège

• Business Impact Analysis (BIA) classe les risques en fonction de :

  • L’impact financier, réglementaire et opérationnel

  • La criticité des actifs pour le fonctionnement de l’organisation

• Dans cet exemple :

  • La divulgation des EHR entraîne des amendes HIPAA jusqu’à 2M$ → impact financier élevé et conformité critique

  • Une simple interruption n’a pas le même impact → faible perte opérationnelle

• Donc, pour la menace de divulgation, l’impact est élevé (High Business Impact)

• Objectif d’un tabletop exercise :

  • Identifier lacunes dans les procédures, rôles et responsabilités

  • Former les parties prenantes à la coordination et aux étapes critiques

• Observation : les chemins d’escalade ne sont pas clairs

  • Correctif immédiat = mettre à jour la documentation BCDR

  • Validation = planifier un nouvel exercice pour s’assurer que tous comprennent les procédures

• Cette approche :

  • Est non intrusive, sécurisée et pédagogique

  • Permet de corriger les processus sans risquer les systèmes en production

• Azure Key Vault :

  • Permet de centraliser tous les certificats TLS/SSL

  • Offre intégration native avec certaines CA pour le renouvellement automatique

  • Réduit le risque de pannes ou interruptions liées à l’expiration

  • Fournit gestion centralisée du cycle de vie (création, renouvellement, révocation, suivi)

• C’est la solution recommandée pour des environnements à grande échelle avec de nombreux certificats, comme une plateforme e-commerce.

Le rôle storage.objectCreator est le plus approprié : il permet uniquement la création d'objets dans le bucket (principe du moindre privilège). storage.objectAdmin donnerait trop de permissions (lecture, modification, suppression). Les scopes d'accès sont une ancienne méthode non recommandée.

Dans App Engine, router 100% du trafic vers une version précédente dans la page Versions est la méthode la plus rapide pour revenir en arrière. La commande 'gcloud app restore' n'existe pas. Les versions précédentes sont conservées et peuvent être réactivées instantanément.

gcloud iam roles copy avec le projet de destination est la méthode la plus rapide pour copier exactement les rôles IAM d'un projet à un autre en une seule commande, sans recréer manuellement chaque rôle.

Les bonnes pratiques Google recommandent d'utiliser des groupes plutôt que des comptes individuels et des rôles prédéfinis plutôt que des rôles personnalisés quand ils répondent au besoin. logging.viewer + bigQuery.dataViewer couvrent exactement les besoins d'audit.

gcloud config list affiche la configuration active, incluant le projet actif qui a été utilisé pour le déploiement. Si le mauvais projet était configuré, cela explique le déploiement au mauvais endroit. C'est la première chose à vérifier.

Les deux méthodes efficaces sont : les quotas personnalisés (limitent les octets traités par utilisateur/projet) et le passage au modèle forfaitaire avec slots (coût fixe prévisible). Créer des copies multiples augmenterait les coûts de stockage.

Les noeuds préemptibles peuvent être supprimés à tout moment par Google. Si un noeud est préempté après le scheduling du pod, ce pod passe en PENDING pendant que GKE crée un nouveau noeud pour le rescheduler. C'est le comportement normal avec des noeuds préemptibles.

Accorder Storage Object Viewer au compte de service des noeuds GKE dans le projet où les images sont stockées est la méthode recommandée. Elle utilise IAM correctement, sans clés supplémentaires ni accès trop larges.

MongoDB Atlas via Google Cloud Marketplace offre un environnement MongoDB entièrement géré avec SLA de support officiel. C'est la différence clé avec une installation manuelle : la gestion des mises à jour, des sauvegardes et du support est assurée par MongoDB.

Avec maxSurge=1 et maxUnavailable=0, la mise à jour progressive ajoute une nouvelle instance avant d'en supprimer une ancienne, garantissant que la capacité ne diminue jamais. maxUnavailable=0 signifie qu'aucune instance ne peut être indisponible pendant la mise à jour.

Faux. Le Guide Scrum ne limite pas les interactions avec les parties prenantes aux seules Sprint Reviews. En effet, la transparence et la collaboration sont des valeurs Scrum. Les parties prenantes peuvent échanger avec la Scrum Team tout au long du Sprint ; la Sprint Review est simplement l'opportunité formelle de recueillir des retours et d'effectuer une inspection.

Le Scrum Master coordonne en levant les impediments et en facilitant l'inspection et l'adaptation, et non par l'attribution directe de tâches ou l'escalade des conflits vers le management. Cette approche de servant-leadership permet aux équipes de s'auto-organiser et de résoudre les problèmes. Le Scrum Master accompagne les équipes sur les dépendances et la collaboration plutôt que d'imposer la coordination, respectant ainsi les valeurs d'auto-organisation de Scrum.

Le Scrum Master doit enseigner aux équipes à s'auto-organiser avec les compétences nécessaires pour créer des Incréments intégrés de manière autonome. Le Scrum Master ne coordonne pas le travail directement ; il facilite plutôt les conditions permettant aux équipes de se coordonner elles-mêmes. Les options A, C et D centralisent de manière inappropriée la coordination ou créent une synchronisation artificielle, violant ainsi le principe d'auto-organisation de Scrum.

Correct : Option 3 - L'auto-organisation est une valeur fondamentale de Scrum qui exige que les équipes de développement déterminent de manière autonome la meilleure façon d'accomplir leur travail dans des limites clairement définies. Les options 1 et 2 représentent des approches de commandement et de contrôle dans lesquelles la direction alloue les ressources, ce qui nuit à la capacité d'auto-organisation de l'équipe et viole les principes de Scrum.

Les options B et C décrivent correctement les Objectifs de Sprint. L'Objectif est élaboré en collaboration lors du Sprint Planning et apporte focus et flexibilité dans la mise en œuvre. Les Objectifs peuvent évoluer avec de nouvelles informations, mais restent ancrés dans un objectif métier stable. L'option A est fausse — les Objectifs sont définis lors du Planning, et non à la fin du Sprint. L'option D est trompeuse ; bien que les approches de mise en œuvre s'adaptent, l'Objectif lui-même doit rester stable, sauf si l'objectif métier change.

L'option D est correcte. Le Scrum Master doit faciliter la collaboration entre le Product Owner et l'équipe de développement afin de renforcer la Definition of Done pour répondre aux préoccupations de performance. L'option A reporte inutilement l'action, l'option B dirige l'équipe de manière inappropriée, et l'option C est défensive et écarte les retours des parties prenantes. La DoD est une responsabilité partagée qui évolue grâce à la collaboration.

Réponses correctes : Options 0 et 4. Un Scrum Master doit accompagner l'équipe de développement à s'auto-organiser et à résoudre les problèmes de manière collaborative (option 0), et coacher individuellement la personne concernée sur l'objectif du Daily Scrum — la synchronisation — et non les discussions techniques approfondies (option 4). Escalader le problème à la direction (option 1) contourne l'autonomisation de l'équipe. Imposer des règles strictes de timeboxing (options 2 et 3) constitue des solutions imposées plutôt qu'un accompagnement de l'équipe vers l'auto-gestion. Le Scrum Master facilite, il ne dicte pas.

L'impact immédiat sur la productivité de l'équipe d'origine est susceptible de diminuer (option 1). L'ajout de nouvelles équipes engendre une surcharge de communication, des dépendances potentielles et une fragmentation des connaissances. Bien que plusieurs équipes puissent augmenter le débit global du produit sur le long terme, l'équipe d'origine subit une perturbation dans un premier temps — un principe bien documenté dans la mise à l'échelle de Scrum.

Cette affirmation est Fausse. Scrum ne définit pas de rôle de Project Manager. Le Scrum Master facilite les processus Scrum, mais n'est pas un chef de projet. Cette distinction reflète le modèle d'équipe auto-organisée de Scrum, plutôt qu'un management traditionnel de type commande et contrôle.

Pour aider une nouvelle Scrum Team à démarrer efficacement, le Scrum Master doit se concentrer sur la présentation de l'équipe, la connaissance du produit et l'établissement de la Definition of Done. L'option 1 est incorrecte car la compatibilité des personnalités et les systèmes de récompenses ne relèvent pas des responsabilités du Scrum Master ; l'équipe s'auto-organise en fonction des compétences et de l'engagement envers les valeurs Scrum.

Réponse : Les métriques enregistrées lors du test de l\'outil de capture-rejouer..
Explication : C est correct car les métriques mesurées de l\'outil de capture-rejouer fournissent les données empiriques directes (taux d\'exécution, temps de création et maintenance des scripts, taux de faux positifs/négatifs, surcharge de configuration/nettoyage) nécessaires pour convertir les tâches de test spécifiées en estimations temporelles fiables et réduire l\'incertitude.

Réponse : Chaque niveau de test a des objectifs de test spécifiques à ce niveau..
Explication : C est correct car la définition d\'objectifs de test pour chaque niveau de test garantit que les tests sont intentionnels, mesurables et traçables aux risques correspondants. Le bon test dans tout modèle de cycle de vie exige que les activités de test soient planifiées et exécutées avec des objectifs spécifiques au niveau.

Réponse : Le plan de test du soumissionnaire décrit une mise en œuvre par phases avec des dates de livraison ultérieures à confirmer et indique que les livrables de test seront développés en utilisant la norme IEEE 829 comme guide..
Explication : D est correct car il démontre une réponse appropriée, centrée sur la gestion de test : un plan de livraison par phases réaliste associé à l\'engagement de développer les livrables de test selon un cadre documentaire reconnu (IEEE 829), sans imposer de dates inflexibles ni de processus propriétaires.

Réponse : Clôture du projet de test.
Explication : D est correct car la phase de clôture du projet de test produit le rapport de synthèse formelle, les artefacts de retours d\'expérience et les métriques consolidées qui constituent les principales entrées utilisées pour piloter et prioriser l\'amélioration du processus de test.

Réponse : Les développeurs perdent le sens des responsabilités et les testeurs indépendants peuvent devenir un goulot d\'étranglement..
Explication : Le test indépendant sépare la vérification du développement, ce qui peut diminuer le sens de la responsabilité des développeurs tandis que la coordination des tests et le triage des incidents se concentrent dans une équipe distincte qui peut devenir un goulot d\'étranglement processus.

Réponse : Inspections.
Explication : Les inspections (B) sont les moins appropriées car c\'est une technique d\'examen statique, axée sur les défauts, destinée à trouver des non-conformités dans les produits de travail plutôt qu\'à identifier proactivement les risques projet et produit. Les inspections utilisent des listes de contrôle et une approche orientée détection de défauts, tandis que l\'identification des risques nécessite une exploration prospective des incertitudes futures.

Réponse : L\'approche de test qui sera appliquée aux tests d\'intégration système..
Explication : C est correct car le plan directeur de test est un document au niveau du programme qui spécifie l\'approche de test de haut niveau pour les principaux niveaux de test, y compris les tests d\'intégration système. Le plan directeur communique la portée, les objectifs, l\'approche générale de test aux parties prenantes, tandis que les détails d\'exécution relèvent des plans subordonnés.

Réponse : Créer une estimation basée sur la technique d\'analyse de points de fonction et l\'analyse de points de test.
Explication : La réponse A est correcte car l\'analyse de points de fonction combinée à l\'analyse de points de test produit une estimation précoce basée sur la taille, spécifique aux tests, indépendante de la disponibilité du code source. L\'APF fournit une métrique de taille fonctionnelle, l\'APT traduit cette taille en effort de test en appliquant les facteurs de testabilité et de qualité.

Réponse : Organiser une réunion avec la direction générale pour qu\'elle aborde l\'importance d\'une bonne qualité de test pour ce projet.
Explication : D est correct car l\'appui visible de la direction générale élève la priorité organisationnelle des tests, fournit une reconnaissance et supprime les obstacles systémiques. Cela augmente la signification de la tâche et aligne l\'effort individuel avec les objectifs organisationnels, motivant durablement l\'équipe.

Réponse : Prévoir un environnement de test de secours en cas de défaillance de l\'environnement existant pendant les tests.
Explication : C est correct car prévoir un environnement de test de secours est une mesure d\'atténuation proactive et au niveau du projet qui réduit la probabilité et l\'impact d\'une défaillance d\'environnement. L\'atténuation des risques projet consiste en actions anticipées et délibérées réduisant l\'exposition aux menaces identifiées. Un environnement redondant est une mesure classique car une défaillance d\'environnement est un point de défaillance unique fréquent pouvant arrêter complètement les tests et augmenter les coûts.

A. Retourner une liste de vols vide comme si la recherche avait réussi mais n'avait trouvé aucun vol correspondant. Incorrect. Cela masque l'échec et induit le système en erreur en lui faisant croire qu'aucun vol n'existe, ce qui peut conduire à des conclusions incorrectes. B. Enregistrer l'erreur en interne et retourner une réponse vide, laissant le modèle continuer sans les données de vols. Incorrect. Cela supprime également le signal d'échec, empêchant l'agent de prendre des mesures correctives. C. Retourner un message d'erreur dans le résultat de l'outil expliquant que le service est temporairement indisponible. Incorrect. Bien que transparent, cela ne tente pas à lui seul une récupération et peut dégrader inutilement l'expérience utilisateur. D. Réessayer automatiquement la requête jusqu'à cinq fois avec un backoff exponentiel avant de retourner les résultats à l'agent. Correct. Il s'agit de l'approche la plus efficace : elle gère les pannes transitoires de manière élégante, améliore la fiabilité et ne remonte les erreurs que si les tentatives échouent.

A. Enregistrer l'erreur côté serveur et retourner un résultat vide pour ne pas perturber le modèle — Incorrect. Cela masque les informations critiques sur l'échec, rendant impossible pour l'agent de distinguer « aucune donnée » d'une « défaillance système ». B. Lever une exception depuis le gestionnaire d'outil afin que le framework agent puisse la capturer et la journaliser — Incorrect. Les exceptions sont utiles en interne, mais l'agent a toujours besoin d'une réponse structurée de l'outil ; les exceptions brutes ne propagent pas de manière fiable un contexte utile au modèle. C. Retourner le message d'erreur dans le contenu du résultat de l'outil avec le flag isError défini à true — Correct. Il s'agit du modèle MCP approprié : l'outil signale explicitement l'échec en utilisant isError: true, tout en fournissant un message d'erreur lisible afin que l'agent puisse décider de réessayer, d'escalader ou d'informer l'utilisateur. D. Retourner une réponse de succès avec un champ « status » indiquant le type d'erreur — Incorrect. Cela est trompeur car cela traite les échecs comme des réponses réussies, ce qui perturbe le raisonnement en aval et l'orchestration des outils.

B. Les détails de la commande sont ajoutés à la conversation et le modèle raisonne sur l'action à entreprendre. Correct. Dans une boucle agentique, les résultats des outils (comme « acheté il y a 45 jours ») sont réinjectés dans le contexte du modèle, et celui-ci réévalue la situation de manière dynamique. Il décide ensuite s'il convient de procéder avec process_refund, d'escalader vers un humain, ou d'entreprendre une autre action en fonction de la politique et des informations mises à jour. Pourquoi les autres réponses sont incorrectes : A. Séquence d'outils fixe planifiée dès le départ — Incorrect. Les systèmes agentiques ne sont pas des flux de travail statiques ; ils s'adaptent après chaque observation. C. Arbre de décision préconfiguré — Incorrect. Il s'agit d'une automatisation basée sur des règles, et non d'un raisonnement piloté par un LLM. D. La couche d'orchestration achemine automatiquement le prochain appel d'outil — Incorrect. Cela supprime le rôle de raisonnement du modèle et le transforme en un routage déterministe.

A. Votre invite système doit contenir des instructions explicites demandant à Claude de mémoriser les informations des échanges précédents. Incorrect. Les instructions seules ne confèrent pas de mémoire au modèle — le contexte doit être fourni à chaque requête. B. Vous n'incluez pas les messages précédents dans chaque requête API — l'API sans état ne conserve pas l'historique de la conversation. Correct. Claude est sans état. Si les messages précédents ne sont pas transmis dans la requête, il n'a aucune connaissance du vocabulaire antérieur. C. Vous devez activer la persistance de la conversation en transmettant un paramètre d'identifiant de session à chaque appel API. Incorrect. Il n'existe pas d'identifiant de session requis — la mémoire est gérée en incluant les messages passés. D. La fenêtre de contexte du modèle est saturée, ce qui entraîne la perte du contenu des échanges précédents. Incorrect. Cela ne se produirait que lors de conversations très longues, et non dans des scénarios de tests initiaux classiques.

A. Des descriptions de paramètres claires expliquant le format attendu, par exemple « user_id : UUID de l'utilisateur à mettre à jour (obligatoire) » — Correct. Des descriptions claires et lisibles sont le facteur le plus important pour aider Claude à comprendre quelles valeurs fournir et comment les paramètres doivent être structurés. B. Des noms de paramètres verbeux encodant des indications de format, comme user_id_string_uuid_format — Incorrect. Des noms excessivement verbeux réduisent la lisibilité et sont moins efficaces que des descriptions appropriées. C. Des contraintes de type JSON Schema strictes marquant user_id comme obligatoire et définissant fields_to_update comme type objet — Incorrect. Les contraintes de schéma facilitent la validation, mais n'expliquent pas suffisamment les attentes sémantiques comme le format UUID requis. D. Des réponses d'erreur détaillées expliquant pourquoi des valeurs de paramètres invalides ont été rejetées — Incorrect. Utiles après un échec, mais pas le facteur le plus critique pour prévenir les erreurs en amont.

A. Mettre en œuvre une déduplication sémantique pour identifier et supprimer les informations redondantes dans les résultats RAG accumulés et les tours de conversation — Incorrect. Cela réduit la redondance, mais ne résout pas le problème central de l'accumulation non bornée du contexte RAG. B. Mettre en œuvre une fenêtre glissante pour les résultats RAG des 2 à 3 dernières requêtes tout en préservant l'historique de la conversation — Correct. Cela répond directement au problème de saturation du contexte en limitant la croissance du RAG tout en maintenant la continuité de la conversation. C. Réaffecter le budget de contexte en faveur des résultats RAG tout en réduisant l'allocation de l'historique de conversation — Incorrect. Cela détériore la cohérence en sacrifiant le contexte conversationnel. D. Compresser tous les résultats RAG en un document de synthèse consolidé qui se met à jour de manière incrémentielle après chaque récupération — Incorrect. Cela peut entraîner une perte d'informations et une dérive du résumé, en particulier sur de nombreux tours de conversation.

A. La fenêtre de contexte du modèle a été dépassée par la longueur de la conversation — Incorrect. Cela ne se produirait que lors de conversations très longues, alors que le problème apparaît dès les premiers échanges. B. L'API Claude nécessite un paramètre session_id que vous n'avez pas configuré — Incorrect. Il n'existe pas de session_id obligatoire ; le contexte doit être géré explicitement par l'application. C. Claude nécessite une connexion à une base de données vectorielle pour maintenir la mémoire de la conversation — Incorrect. Une base de données vectorielle est optionnelle pour la récupération d'informations, elle n'est pas requise pour la mémoire conversationnelle de base. D. Votre application n'inclut pas les messages précédents dans le tableau messages — Correct. Claude ne conserve aucune mémoire entre les appels ; si les messages précédents ne sont pas inclus, il ne peut pas se souvenir des préférences exprimées antérieurement par l'utilisateur.

A. L'agent coordinateur reçoit la sortie de l'agent de recherche web et inclut les résultats pertinents dans le prompt lors de l'invocation de l'agent d'analyse de documents. Correct. Cela suit le modèle d'orchestration standard où le coordinateur gère tous les flux de données, en transmettant explicitement les sorties entre les sous-agents. B. Les agents communiquent via une file de messages orientée événements, l'agent d'analyse de documents s'abonnant aux événements de fin de recherche web. Incorrect. Cela introduit une complexité d'infrastructure inutile et ne correspond pas au modèle d'orchestration d'agents habituel. C. L'agent de recherche web invoque directement l'agent d'analyse de documents, en utilisant les sources découvertes comme paramètres. Incorrect. Les sous-agents ne doivent pas s'invoquer directement entre eux ; cela rompt le contrôle centralisé et la traçabilité. D. Les deux agents accèdent à un espace mémoire partagé où l'agent de recherche web écrit les résultats et l'agent d'analyse de documents les lit. Incorrect. Bien que cela soit possible dans des systèmes avancés, ce n'est pas l'approche standard ou la plus simple ; cela ajoute de la complexité sans nécessité évidente dans les pipelines classiques.

A. Fournir au sous-agent des définitions d'outils lui permettant de demander des résultats à d'autres sous-agents via des callbacks. Incorrect. Cette approche introduit un couplage et une complexité inutiles. Les sous-agents ne devraient pas avoir besoin de récupérer activement des données auprès des autres. B. Inclure directement les résultats complets des deux sous-agents dans le prompt du sous-agent de synthèse. Incorrect. Bien que simple, cette approche ne passe pas bien à l'échelle pour des résultats volumineux et peut dépasser les limites de contexte, réduisant ainsi l'efficacité. C. Transmettre des identifiants de référence et configurer le sous-agent avec un accès en lecture à un espace mémoire partagé où les autres sous-agents ont déposé leurs résultats. Correct. Il s'agit de l'approche la plus évolutive et prête pour la production. Elle préserve la fidélité des informations tout en évitant la surcharge du contexte, permettant à l'agent de synthèse de récupérer exactement ce dont il a besoin. D. Instancier le sous-agent avec seulement une brève description de tâche, en s'appuyant sur un héritage automatique du contexte depuis le coordinateur. Incorrect. Il n'existe pas d'héritage automatique du contexte — sans accès explicite aux données, l'agent de synthèse ne peut pas fonctionner correctement.

A. L'agent de synthèse a besoin d'outils capables de récupérer les résultats directement depuis l'historique des conversations des autres agents. Incorrect. Les agents n'ont pas besoin d'accéder directement aux historiques des autres. Une orchestration correcte transmet les sorties explicitement via des prompts. B. La fenêtre de contexte de l'agent de synthèse n'est pas suffisamment large pour contenir les sorties combinées des deux agents précédents. Incorrect. Si c'était le problème, l'agent recevrait des données tronquées, et non une absence totale de données. L'erreur indique que les entrées sont entièrement manquantes. C. Les sous-agents doivent partager une seule connexion API pour permettre le partage automatique du contexte entre les invocations. Incorrect. La communication entre agents ne dépend pas de connexions API partagées. Le contexte doit être explicitement transmis par le coordinateur. D. Le coordinateur n'a pas inclus les sorties des agents précédents dans le prompt de l'agent de synthèse. Correct. L'agent de synthèse ne peut agir que sur les informations fournies dans son prompt. Si les sorties précédentes ne sont pas transmises, il signalera l'absence des résultats de recherche.