Ne découvrez pas l'examen
le jour J

Réponse : Le type d’instance / La zone de disponibilité choisie.
Explication : Le prix dépend du type d’instance, de la région et AZ, mais pas du load balancing, ni du nombre de buckets/IP privés.

Réponse : C) AWS IAM Access Analyzer. IAM Access Analyzer analyse les politiques de ressource pour identifier les ressources (compartiments S3, rôles IAM, clés KMS, etc.) qui sont partagées avec des entités externes. Cet outil aide à détecter un accès involontaire depuis l'extérieur de votre organisation AWS.

Réponse : C) Activer l'authentification multifacteur (MFA) pour une sécurité renforcée lors du processus de connexion. MFA est une meilleure pratique fondamentale de sécurité IAM qui ajoute un deuxième facteur (jeton matériel ou application d'authentification virtuelle) au processus de connexion, protégeant les comptes même si les mots de passe sont compromis.

Réponse : Amazon DynamoDB.
Explication : DynamoDB est une base NoSQL clé-valeur, managée, adaptée au stockage de données structurées pour applications rapides.

Réponse : Réduction du time-to-market / Remplacement du CAPEX par l’OPEX.
Explication : AWS permet d’aller plus vite sur le marché et de transformer des investissements lourds en coûts variables faibles.

Réponse : Couplage faible.
Explication : Le « loose coupling » consiste à isoler les modules pour garantir la robustesse et faciliter la maintenance.

Réponse : Un système tolérant aux pannes.
Explication : La tolérance aux pannes permet à une application de continuer à fonctionner même si une partie de l’infrastructure tombe en panne.

Réponse : Maîtrise du cloud. Explication : La perspective des personnes du AWS CAF se concentre sur la gestion du changement organisationnel. La maîtrise du cloud — comprendre les concepts, les avantages et les modes de fonctionnement du cloud — est une capacité fondamentale de la perspective des personnes.

Réponse : Régions AWS. Explication : Les régions AWS permettent aux clients de déployer des ressources dans des emplacements géographiques spécifiques. Choisir une région proche de la localisation actuelle de l'entreprise minimise la latence et peut satisfaire les exigences de résidence des données lors de la migration.

Réponse : AWS Service Catalog. AWS Service Catalog permet aux organisations de créer et de gérer des catalogues de services IT approuvés en tant que modèles d'infrastructure as code. Il permet de gouverner les ressources qui peuvent être déployées tout en donnant aux équipes l'accès en libre-service aux configurations approuvées.

Agents for Amazon Bedrock : orchestrateur intelligent qui utilise un FM pour analyser des requêtes, décider automatiquement d'actions à exécuter (appels API, requêtes de bases de données, retrieval RAG) et enchaîner les résultats. Contrairement à Guardrails (filtrage de sécurité), PartyRock (prototypage simple) et Q Developer (assistant de code), les Agents gèrent l'automatisation complète d'un workflow complexe en déléguant intelligemment au FM les décisions d'orchestration.

Prompt engineering : technique d'optimisation du style et ton sans coûts additionnels. Les instructions précises (ex.: "réponds avec ton professionnel, 2 phrases max") contrôlent directement la génération. Contrairement au fine-tuning (coûteux) ou à la température (qui ajoute aléatoire), le prompt affinage itératif adapte le comportement du modèle existant efficacement.

Unsupervised learning (clustering) : découvre automatiquement des groupes de clients sans données étiquetées. Avec des pétaoctets non annotés, le clustering (K-means, DBSCAN) identifie des segments naturels. Le supervised learning exige des labels préexistants (impossible ici), le reinforcement learning optimise des actions (non pertinent), et RLHF affine des modèles génératifs (hors sujet).

Amazon Comprehend : service NLP entièrement géré qui analyse automatiquement les sentiments (positif/négatif/neutre) et extrait les entités dans du texte, sans nécessiter de ML expertise. Contrairement à Polly (synthèse vocale), Rekognition (vision) et Lex (chatbots), Comprehend se concentre spécifiquement sur l'analyse textuelle intelligente pour les avis, commentaires et documents.

Résumé génératif à grande échelle : Les modèles de fondation via Bedrock excellent dans la synthèse de contenu complexe et nuancé, bien mieux que les outils de classification. Scalable batch pour traiter des milliers de documents.

AWS PrivateLink expose un point de terminaison privé (ENI) dans le VPC pour accéder à Bedrock sans transiter par Internet, répondant aux contraintes réglementaires de trafic privé.

Average Call Duration (ACD) : métrique mesurant le temps total d'un appel. Avec un LLM, l'ACD diminue car le système automatise les tâches répétitives (recherche info, qualification) et permet aux agents de se concentrer sur les problèmes complexes. Contrairement à la CSR (éthique globale) ou à la conformité (exigence légale), l'ACD quantifie directement le gain d'efficacité opérationnelle recherché.

Transcribe + Translate : Transcribe convertit l'audio en texte avec haute précision dans 99+ langues. Translate, service automatisé, traduit le texte résultant vers les 8 langues cibles. Pipeline coût-efficace et parallélisable pour traiter 50 heures rapidement.

Transcribe + Bedrock/Claude : Transcribe convertit l'audio de réunion en texte exact. Claude, via Bedrock, génère résumés avec instruction de longueur variable (executive summary vs. détaillé). Pipeline élégant pour exploiter les réunions en documents actionnables.

Augmenter le nombre d'époques : chaque époque expose le modèle à l'ensemble des données d'entraînement, permettant au gradient de converger progressivement vers de meilleurs minima locaux. Contrairement à réduire le batch (variance élevée) ou diminuer les époques (convergence incomplète), plus d'itérations stabilisent l'optimisation et améliorent directement l'exactitude jusqu'au seuil requis.

Valeurs Scrum : L'engagement, le courage, la concentration, l'ouverture et le respect constituent le fondement de la culture Scrum. Ces valeurs permettent d'instaurer la confiance, la transparence et l'efficacité au sein des équipes. Elles guident les comportements et les décisions, garantissant que le cadre Scrum atteint son objectif de livraison de valeur à travers un développement produit adaptatif.

Rôle du Scrum Master : Le Scrum Master accompagne l'équipe dans les pratiques et le cadre Scrum, et non dans la mise en œuvre technique. L'expertise technique appartient aux Developers. La valeur du Scrum Master réside dans la suppression des obstacles, la facilitation des événements et le développement de l'auto-organisation — des compétences indépendantes des connaissances techniques.

Immuabilité du Sprint Goal : Le Sprint Goal est établi lors du Sprint Planning et reste fixe tout au long du Sprint. Cet engagement fournit une orientation et une direction à l'équipe de développement, en évitant l'élargissement incontrôlé du périmètre. Bien que le Product Owner puisse ajuster le Product Backlog, le Sprint Goal lui-même — une fois convenu — ne peut pas être modifié unilatéralement par un seul rôle, garantissant ainsi la stabilité et la prévisibilité de l'équipe.

Réponse : Aucun travail restant au regard du DoD ; prêt à être livré aux utilisateurs finaux.
Explication : « Terminé » signifie que l'Increment satisfait pleinement la Definition of Done (tous les critères sont remplis) et se trouve dans un état tel que le Product Owner pourrait choisir de le livrer aux utilisateurs. Ces deux conditions réunies définissent l'exhaustivité.

La pensée Lean dans Scrum : Elle consiste à éliminer les activités sans valeur ajoutée tout en maximisant la livraison de valeur au client. Les principes Lean s'alignent sur l'approche itérative de Scrum en minimisant le gaspillage (processus inutiles, délais, défauts) et en concentrant les ressources sur le travail essentiel. Contrairement à la réduction de la taille de l'équipe ou à l'accélération forcée, le Lean met l'accent sur une efficacité durable grâce à l'amélioration continue.

Gestion des obstacles dans Scrum : Les Developers identifient les blocages lors du Daily Scrum, puis travaillent activement à les résoudre. Le Scrum Master facilite la suppression des obstacles organisationnels en dehors de la réunion, en maintenant le Daily Scrum dans sa timebox et en le gardant concentré sur l'essentiel. Cette approche évite de prolonger les réunions ou de reporter la résolution des problèmes jusqu'à la Sprint Review.

Objectif de la Sprint Review : il s'agit d'une session de travail interactive au cours de laquelle l'équipe Scrum et les parties prenantes inspectent l'Increment et collaborent sur les adaptations du Product Backlog. Ce n'est PAS une réunion de suivi où la direction reçoit des comptes rendus ; elle met au contraire l'accent sur la transparence, le feedback et la prise de décision collective plutôt que sur le reporting.

La Focalisation signifie que la Scrum Team se concentre sur le travail du Sprint et sur le Sprint Goal. Décliner du travail qui détournerait l'attention du Sprint Goal illustre la Focalisation. L'Engagement consiste à consacrer ses efforts à l'atteinte du Sprint Goal. Le Courage consiste à faire ce qui est juste, y compris avoir des conversations difficiles. Le Respect consiste à traiter ses coéquipiers comme des professionnels compétents. La Focalisation protège l'équipe contre l'élargissement non maîtrisé du périmètre et permet une livraison prévisible.

Réponse : Avoir une transparence totale sur ce qui a été accompli à la fin de chaque Sprint.
Explication : La Definition of Done (DoD) crée une compréhension commune de ce que signifie « terminé ». Lorsque tous les membres de l'équipe la respectent, le PO peut avoir confiance que les éléments « Done » sont véritablement prêts à être livrés — ce qui élimine toute ambiguïté lors des Sprint Reviews.

Réponse : Le taux de conversion des clients.
Explication : L'EBM (Evidence-Based Management) se concentre sur les résultats et les impacts plutôt que sur les livrables. Le taux de conversion est une métrique de résultat.

Réponse : Le Product Owner (contexte métier) en collaboration.
Explication : La décision de livraison est une décision métier prise par le Product Owner, éclairée par la transparence et le contexte organisationnel.

Réponse : Un ordre clair, un Product Goal, des éléments suffisamment clairs.
Explication : La transparence est assurée par un ordonnancement approprié, un alignement sur un Product Goal et des éléments compréhensibles par l'ensemble des parties prenantes.

Réponse : Le Product Backlog est continuellement mis à jour avec les informations les plus récentes.
Explication : Un Product Backlog obsolète devient opaque et trompeur. La transparence exige un affinage continu — ajouter de nouveaux éléments, supprimer ceux qui sont dépassés, réordonner en fonction des nouvelles informations — afin que le Backlog reflète toujours la compréhension actuelle.

Timebox du Sprint Planning : Le Sprint Planning est limité à une heure par semaine de durée du Sprint. Pour un Sprint d'un mois (4 semaines), cela représente un maximum de 8 heures. Le Guide Scrum établit cette relation proportionnelle afin de garantir un temps suffisant pour que l'équipe de développement et le Product Owner puissent discuter des éléments du Product Backlog, définir l'Objectif du Sprint et s'engager sur un Sprint Backlog réaliste, sans alourdir excessivement la planification. Les Sprints plus courts (par exemple, 1 semaine) bénéficient proportionnellement de moins de temps (4 heures), tandis que les Sprints plus longs en disposent davantage. L'option « Sans limite » suggère à tort que la planification peut se prolonger indéfiniment, ce qui va à l'encontre du principe même de la timebox. Les options de 2 heures et 4 heures sous-estiment la complexité nécessaire pour un Sprint d'un mois.

Concept clé : La Definition of Done (DoD) est l'engagement formel qui définit ce que signifie pour un Incrément d'être complet et potentiellement livrable. Selon le Guide Scrum 2020, chaque Incrément doit être conforme à la Definition of Done — une compréhension partagée entre l'Équipe de Développement et le Product Owner concernant les standards de qualité, les exigences de test et les critères d'acceptation. Cela garantit la cohérence, la transparence et la prévisibilité d'un Sprint à l'autre. La DoD protège la qualité du produit et permet aux parties prenantes de faire confiance au fait que le travail marqué « done » répond véritablement aux standards de l'équipe. Bien que le Product Goal fournisse une direction et que le Sprint Goal concentre un Sprint unique, aucun des deux ne constitue un engagement envers l'Incrément lui-même. Le Release Burnup suit la progression mais ne définit pas les critères de complétude.

Réponse : La valeur, le risque, l'apprentissage.
Explication : Le Product Owner ordonne le Backlog afin de maximiser la livraison de valeur tout en gérant les risques et en intégrant les apprentissages issus des Sprints précédents.

Concept clé : La responsabilité du Product Owner en matière d'engagement des parties prenantes. Le Product Owner est explicitement responsable d'inviter les parties prenantes à la Sprint Review, car cet événement constitue une opportunité clé d'inspection et d'adaptation permettant de recueillir des retours sur l'Incrément du produit. Le Product Owner gère les relations avec les parties prenantes et détermine qui doit y assister en fonction de la pertinence par rapport au produit, de la valeur métier et des besoins en retours. Bien que le Scrum Master facilite l'événement et que les Développeurs présentent leur travail, ni l'un ni l'autre n'est responsable de l'invitation des parties prenantes. Les managers ne font pas partie du cadre Scrum et n'ont aucun rôle formel dans cette décision.

Réponse : C'est le plan des Developers pour le Sprint.
Explication : Le Sprint Backlog appartient à l'équipe de développement et représente leur plan pour atteindre le Sprint Goal. Il est hautement visible et mis à jour quotidiennement au fur et à mesure que de nouvelles informations émergent.

Le domaine Mesure et Performance du PMBOK 7 : Ce domaine de performance représente l'ensemble des processus permettant de collecter, mesurer et analyser les données de projet pour évaluer l'avancement et les performances. Le suivi de l'avancement par rapport au plan en est l'élément fondamental car il constitue l'activité centrale : comparer continuellement ce qui a été réalisé contre ce qui était planifié (délais, coûts, scope, qualité). Cette comparaison systématique permet au chef de projet d'identifier rapidement les écarts et de déclencher des actions correctives. Les autres options, bien que liées à la gestion de projet, ne correspondent pas à ce domaine spécifique : l'analyse des écarts (option 2) est une technique, non un élément du domaine lui-même ; la communication (option 3) relève du domaine Parties prenantes ; la création de nouveaux livrables (option 4) appartient au domaine Planification ; et la définition du périmètre initial (option 5) relève du domaine Planification également. Le suivi constitue ainsi le cœur du domaine Mesure, car sans cette activité continue de comparaison réel/prévu, aucune mesure de performance réelle n'est possible et aucun contrôle du projet ne peut être exercé efficacement.

Contrats à coûts remboursables (CR) : le fournisseur facture tous les coûts réels engagés plus une marge. L'acheteur assume le risque financier principal car il n'y a pas de plafond de dépenses préalablement fixé. Contrairement aux contrats à prix fixe qui protègent l'acheteur, les CR offrent peu d'incitation au contrôle budgétaire du prestataire.

Confiance et leadership serviteur : La confiance se construit par la transparence (clarté des décisions) et le respect des engagements (fiabilité). L'écoute active soutient aussi la confiance, mais seule la combinaison transparence + respect des engagements figure comme réponse correcte. À l'inverse, ignorer les préoccupations ou favoriser la compétition interne détruisent la confiance et l'cohésion d'équipe selon le PMBOK7.

Concept clé : La planification est un processus continu et itératif qui s'étend tout au long du cycle de vie du projet. Dans le PMBOK 7e édition, ce domaine de performance ne se limite pas à la phase initiale, mais accompagne le projet depuis sa conception jusqu'à sa clôture, en s'adaptant constamment aux changements, aux risques émergents et aux apprentissages acquis. Contrairement aux approches traditionnelles en cascade (waterfall), où la planification s'effectuait principalement en amont, les méthodologies modernes (agile, hybride) reconnaissent que la planification reprend régulièrement lors de chaque itération, sprint ou phase de projet. Cette vision reflète la réalité des projets complexes : les hypothèses initiales évoluent, de nouveaux risques apparaissent, et les livrables se précisent progressivement. La deuxième option est fausse car elle suggère une vision rigide où la planification cesserait avec le lancement, ce qui est incompatible avec la gestion moderne des projets. La troisième option est incorrecte car la planification s'applique aussi aux projets agiles et adaptatifs, pas seulement aux projets prédictifs. Enfin, la quatrième option méconnaît le rôle du chef de projet, qui reste responsable de la plan

Fast-tracking : technique de compression d'échéancier consistant à chevaucher ou paralléliser des activités normalement séquentielles, permettant de réduire la durée du projet sans diminuer le périmètre ni la qualité. Dans ce contexte critique, le fast-tracking optimise le chemin critique en exécutant simultanément des tâches dépendantes (par exemple, commencer les tests avant la fin complète du développement), ce qui accélère la livraison tout en conservant tous les livrables requis. Contrairement au crash (ajout de ressources coûteux), cette approche réorganise simplement la séquence des travaux. C'est pourquoi les autres options sont inadéquates : éviter des tâches réduirait le périmètre (inacceptable), réduire la qualité compromettrait les standards du projet, et ajouter des marges n'accélère rien. Le fast-tracking s'aligne avec les principes du PMBOK 7e édition qui priorisent la livraison de valeur et la gestion adaptative des risques inhérents au chevauchement des activités.

Réponse : Réaligner le projet avec la stratégie de l’organisation en consultant le sponsor et les parties prenantes clés.

Approche Agile pour un MVP : L'agilité privilégie les itérations courtes et la livraison progressive de valeur. Un MVP nécessite rapidité et adaptabilité face aux retours clients. L'approche prédictive demande planification exhaustive incompatible avec les délais serrés. L'hybride convient à projets complexes nécessitant phases prévisibles.

Engagement et motivation des parties prenantes : selon le PMBOK 7e édition et les principes de gestion moderne, l'engagement efficace repose sur trois piliers fondamentaux. La communication régulière établit un flux d'informations constant, permettant aux parties prenantes de comprendre l'évolution du projet, les défis rencontrés et les décisions en cours. L'implication dans les décisions clés transforme les parties prenantes de simples spectateurs en acteurs responsables, augmentant leur sentiment d'appartenance et leur investissement émotionnel dans la réussite du projet. La transparence de l'information crée un climat de confiance essentiel, où chacun dispose des mêmes données factuelles pour contribuer de manière constructive. Ces trois éléments travaillent en synergie pour renforcer l'engagement. Les autres options sont contreproductives : réduire les interactions crée de l'isolement et des frustrations ; centraliser l'information génère des goulots d'étranglement et des incompréhensions ; limiter l'accès aux données suscite méfiance et désengagement. Le PMBOK 7e insiste particulièrement sur la gestion collaborative et l'approche orientée "people-first", où les parties prenantes motivées deviennent les meilleurs garants de la livraison réussie du projet.

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.

Cette question correspond à l’objectif d’apprentissage FL-5.3.1 (K1) – Rappeler des métriques utilisées dans les tests.

● a) Faux → C’est une métrique de gestion de projet, pas de test.
● b) Faux → Utile à l’analyse des exigences, mais pas une métrique standard de test.
● c) Correct → Le taux de réussite des cas de test est une métrique clé pour suivre la progression et la qualité.
● d) Faux → Ce n’est ni pertinent ni représentatif de la qualité du produit.

Cette question correspond à l\'objectif d\'apprentissage FL-4.1.1 (K2) - Distinguer les techniques de test boîte noire, boîte blanche et basées sur l\'expérience.

● a) Faux → Cette description correspond aux techniques de test boîte blanche, qui examinent la structure interne du code pour concevoir des tests couvrant différents
chemins d\'exécution. Les tests boîte noire ne s\'intéressent pas au code source.
● b) Faux → Cette description correspond aux techniques de test basées sur l\'expérience, qui s\'appuient sur les connaissances et l\'expérience des testeurs pour
identifier les défauts potentiels. Les tests boîte noire sont basés sur des spécifications documentées plutôt que sur l\'expérience seule.
● c) Faux → Cette description correspond également aux techniques de test boîte blanche, qui analysent la structure interne et mesurent la couverture (instructions, branches, chemins). Les tests boîte noire ne s\'intéressent pas à la structure interne.
● d) Correct → Cette description caractérise précisément les techniques de test boîte noire. Ces techniques considèrent le système comme une \"boîte noire\" dont le fonctionnement interne est inconnu ou ignoré. Les cas de test sont dérivés des spécifications, des exigences et des comportements attendus, sans connaissance de l\'implémentation.

Cette question correspond à l’objectif d’apprentissage FL-5.1.3 (K2) – Comparer et opposer
les critères d\'entrée et les critères de sortie.
La bonne réponse est a) et c)
● a) Correct → L’exécution complète des cas de test prévus (comme ceux de non-régression) est un critère de sortie standard indiquant l’exhaustivité des tests.
● b) Faux → La validation de l’environnement de recette est une préparation au test et relève donc des critères d’entrée.
● c) Correct → Un seuil de couverture des exigences critiques est un indicateur objectif pour déterminer si les tests peuvent être considérés comme suffisants.
● d) Faux → L’approbation du plan de test concerne la préparation des activités de test, donc un critère d’entrée.
● e) Faux → L’outillage opérationnel est une condition préalable au bon déroulement des tests, donc là encore, un critère d’entrée.

Cette question correspond à l\'objectif d\'apprentissage FL-5.1.7 (K2) - Résumer les quadrants du test et leurs relations avec les niveaux et les types de tests.

● a) Faux → Ces caractéristiques correspondent plutôt aux quadrants Q1 et Q3.
● b) Faux → Ces tests sont typiques des quadrants Q2.
● c) Correct→ Le quadrant Q4 (support de l\'équipe) inclut les tests de programmation, de configuration et les outils qui soutiennent l\'équipe de développement.
● d) Faux → Les tests de charge et de sécurité appartiennent principalement au
quadrant Q3.

Cette question correspond à l’objectif d’apprentissage FL-3.1.2 (K2) – Expliquer la valeur du test statique.

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

● 1A) Correct : Moins de défauts en production = moins de coûts en fin de cycle.
● 2B) Correct : Le test statique permet d’identifier les erreurs avant que le code soit écrit.
● 3C) Correct : Les revues statiques aident l’équipe à mieux comprendre les exigences.
● 4 D) Correct : Le test statique n’exécute pas le code, il l’analyse.

Cette question correspond à l’objectif d’apprentissage FL-2.1.2 (K1) – Rappeler les bonnes
pratiques de test applicables à tous les cycles de vie.
● a) Faux → Cela correspond à une approche tardive (type Waterfall rigide), et va àl’encontre des bonnes pratiques modernes.
● b) Faux → Les testeurs doivent être impliqués dès les phases d’analyse et de conception.
● c) Correct → Tester dès que possible (shift-left) est une bonne pratique universelle qui réduit les coûts de détection de défauts.
● d) Faux → Collaboration entre test et développement est essentielle, peu importe le cycle.

Cette question correspond à l\'objectif d\'apprentissage FL-2.2.3 (K2) – Distinguer les tests de confirmation des tests de régression.

La bonne réponse est c) 1A, 2B, 3A, 4B.

● 1A) Correct → Le test de confirmation (ou \"retest\") vérifie qu’un défaut corrigé est effectivement résolu.
● 2B) Correct → Le test de régression s’assure que la correction ou une nouvelle fonctionnalité n’a pas causé d’effets secondaires indésirables.
● 3A) Correct → Les tests de confirmation ciblent spécifiquement la correction appliquée et ne testent pas d’autres parties du système.
● 4B) Correct → Les tests de régression sont exécutés à une échelle plus large pourvérifier que le reste du système fonctionne toujours correctement.

Cette question correspond à l’objectif d’apprentissage FL-4.5.2 (K2) – Classer les différentes options pour la rédaction des critères d’acceptation.
● a) Faux → Bien que la forme Given/When/Then soit très répandue et efficace, il n’existe pas d’obligation stricte dans les projets de test d’acceptation de toujours utiliser ce format.
● b) Correct → format dépend du contexte du projet, du public cible, et de la maturité de l’équipe. Selon la complexité du projet et les habitudes de l’organisation, on peut utiliser plusieurs formats.
● c) Faux → Les critères d’acceptation doivent généralement être élaborés en collaboration avec les parties prenantes clés : Product Owner, utilisateurs métiers, testeurs et développeurs. Se limiter à l’équipe de développement peut conduire à des critères trop techniques ou peu alignés sur les attentes métiers.
● d) Faux → Les critères d’acceptation peuvent effectivement comporter des exigences de performance, mais ils ne se limitent pas à cet aspect. Ils doivent également couvrir la fonctionnalité, la facilité d’utilisation, la sécurité, la fiabilité, etc.

Cette question correspond à l’objectif d’apprentissage FL-5.4.1 (K2) – Résumer la manière dont la gestion de configuration soutient les tests.

● a) Faux → Ce serait insuffisant, et trop simpliste.
● b) Faux → Ce n’est ni lié à la vitesse ni au type de test.

● c) Correct → C’est l’essence même de la gestion de configuration dans un contexte de test multi-version.

● d) Faux → Cela relève du contrôle de version de code, pas du test.

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.

Le risque lié à la chaîne d'approvisionnement : les fournisseurs tiers introduisent des vulnérabilités en cascade à travers l'ensemble de leur écosystème — des fournisseurs compromis, des pratiques de sécurité insuffisantes ou des dépendances violées peuvent impacter directement vos systèmes. Contrairement aux correctifs (gérables) ou aux identifiants (contrôlables), les faiblesses de la chaîne d'approvisionnement existent au-delà de votre périmètre de sécurité et nécessitent une vérification des fournisseurs, et pas seulement des contrôles réseau.

Chiffrement : transforme les données en texte chiffré illisible à l'aide d'algorithmes cryptographiques, garantissant la confidentialité même si des personnes non autorisées obtiennent un accès physique au stockage cloud. Les pare-feux et les antivirus protègent le périmètre réseau et les systèmes, mais ne protègent pas la confidentialité des données. La mise à jour des correctifs corrige les vulnérabilités, mais ne traite pas l'exposition des données au repos.

Destruction sécurisée de documents : Le déchiquetage détruit les informations sensibles de manière irréversible, prévenant ainsi les fuites de données. Contrairement au recyclage (traçable), à l'incinération (dangereuse/illégale) ou à la mise au rebut (accessible), le déchiquetage est la méthode standard, conforme aux exigences légales, pour les documents papier confidentiels.

Le RTO (Recovery Time Objective) est le délai maximal acceptable pour restaurer une fonction métier ou un système informatique après une interruption. Si le RTO d'une organisation pour une base de données critique est de 4 heures, le plan de reprise après sinistre doit restaurer ce système dans les 4 heures suivant la défaillance. Le RPO (Recovery Point Objective) est la quantité maximale acceptable de perte de données (quelle est l'ancienneté maximale tolérée de la sauvegarde la plus récente). Le RTO oriente les décisions d'infrastructure (serveur de secours à chaud vs. sauvegarde à froid). Un RTO élevé = des solutions moins coûteuses sont acceptables. Un RTO faible = nécessite un basculement à chaud ou une architecture active-active.

L'authentification multifacteur (MFA) : nécessite deux facteurs d'authentification différents ou plus — quelque chose que vous connaissez (mot de passe), quelque chose que vous possédez (téléphone pour recevoir un SMS) ou quelque chose que vous êtes (biométrie). Un mot de passe associé à un code SMS combine deux facteurs distincts. L'utilisation de plusieurs mots de passe ou l'ajout d'un code PIN statique ne repose que sur un seul facteur (la connaissance) ; ces méthodes ne constituent donc pas une véritable MFA.

RSA est correct car c'est un algorithme de chiffrement asymétrique qui utilise deux clés différentes : une clé publique pour chiffrer et une clé privée pour déchiffrer.

Les autres réponses sont toutes des algorithmes de chiffrement symétrique : AES-256, 3DES et Blowfish utilisent une seule clé secrète partagée pour les opérations de chiffrement et de déchiffrement.

Attaque par force brute : méthode systématique consistant à tester de multiples combinaisons de mots de passe pour obtenir un accès non autorisé. De nombreuses tentatives de connexion échouées depuis une adresse IP externe indiquent qu'un attaquant essaie des identifiants de façon répétée. Contrairement au phishing (ingénierie sociale), à l'injection SQL (exploitation de base de données) ou au XSS (injection de code côté client), l'attaque par force brute cible spécifiquement l'authentification par la persistance.

Réponse correcte : Le test d'intrusion (penetration testing) simule des attaques réelles pour identifier les vulnérabilités avant que des acteurs malveillants ne les exploitent. Il s'agit d'un test proactif et contrôlé qui permet aux organisations de corriger leurs failles de sécurité.

Pourquoi les autres réponses sont incorrectes : Le déploiement de correctifs (patches) concerne la remédiation (après identification des failles), la surveillance du trafic réseau relève du monitoring continu (et non d'un test ponctuel), et tester les performances du matériel sous charge appartient au domaine des tests de performance, et non de la sécurité.

Désactivation des ports USB : bloquer physiquement ou administrativement les ports USB élimine entièrement le vecteur d'attaque lié aux supports amovibles, empêchant tout transfert de données non autorisé quelles que soient les vulnérabilités logicielles. Bien que l'antivirus détecte les logiciels malveillants et que le chiffrement protège les données au repos, seule la désactivation des ports supprime la voie directe d'exfiltration. La mise à jour des correctifs et le chiffrement traitent les vulnérabilités mais n'empêchent pas l'accès aux périphériques amovibles.

Le ransomware chiffre les données de la victime (documents, bases de données) à l'aide d'un chiffrement asymétrique — la clé de déchiffrement est détenue par l'attaquant. Les victimes doivent payer (généralement en cryptomonnaie) pour récupérer leurs données. Les ransomwares modernes exfiltrent également les données avant de les chiffrer (double extorsion). Le Spyware collecte silencieusement des informations. Le Rootkit dissimule la présence de logiciels malveillants au système d'exploitation. Le Keylogger enregistre les frappes au clavier. La protection nécessite des sauvegardes hors ligne (règle 3-2-1), une détection au niveau des terminaux et une segmentation du réseau pour empêcher la propagation du ransomware.

SQL (Structured Query Language) : langage standard conçu spécifiquement pour interroger, modifier et gérer les données dans les bases relationnelles. Il utilise des commandes comme SELECT, INSERT, UPDATE et DELETE pour interagir avec les tables et leurs relations. Contrairement à HTML (langage de balisage), Python (langage de programmation généraliste) ou JSON (format de données), SQL est le seul optimisé pour les requêtes de bases de données relationnelles.

CREATE TABLE : commande SQL fondamentale qui définit une nouvelle table avec ses colonnes, types de données et contraintes. Contrairement à INSERT INTO (qui ajoute des lignes à une table existante), SELECT INTO (qui crée une table à partir de données existantes) ou ALTER TABLE (qui modifie une structure existante), CREATE TABLE est la seule commande permettant de créer une table vierge avec un schéma défini explicitement dès le départ.

Azure Synapse Analytics est un service d'analytique intégré qui combine : (1) Data warehousing avec Synapse SQL (pools dédiés pour OLAP à grande échelle), (2) Big Data avec Apache Spark intégré, (3) ETL/ELT avec des pipelines intégrés (similaire à Azure Data Factory), (4) Exploration avec Synapse Link (requêtes directes sur Cosmos DB et Azure SQL sans ETL). Il offre un workspace unifié où data engineers, data scientists et analystes collaborent. C'est la solution analytique de bout en bout d'Azure.

Azure Databricks est une plateforme Spark managée développée en collaboration avec Databricks (créateurs de Delta Lake, MLflow). Elle excelle dans les cas avancés : ML/MLOps, feature engineering complexe, streaming Delta. Azure Synapse Analytics Spark est intégré dans le workspace Synapse, facilitant la collaboration entre SQL et Spark au sein d'un même outil. Databricks est souvent préféré pour les data scientists avancés ; Synapse Spark pour les équipes data engineering qui travaillent déjà dans l'écosystème Synapse. Les deux supportent Python, Scala et R.

Réponse : Azure Data Lake Storage. Explication : Azure Data Lake Storage Gen2 fournit un espace de noms hiérarchique et des ACL conformes à POSIX au niveau des fichiers et des dossiers, permettant un contrôle d'accès granulaire pour les charges de travail d'analyse du Big Data. Le stockage Blob Azure standard utilise Azure RBAC mais pas les ACL POSIX.

Rôles des professionnels de la donnée : L'ingénieur de données conçoit et construit les pipelines ETL/ELT qui extraient, transforment et chargent les données. L'analyste de données exploite ces données préparées pour l'analyse et la visualisation. L'administrateur BD gère l'infrastructure et la sécurité, tandis que le développeur front-end crée les interfaces utilisateur. Seul l'ingénieur maîtrise l'architecture complète des flux de données.

Azure Synapse Analytics : plateforme intégrée qui combine entrepôt de données (SQL Data Warehouse), analyses Big Data (Spark) et orchestration ETL. Contrairement à Data Lake Storage (stockage seul), Data Factory (intégration seule) ou Cosmos DB (base NoSQL), Synapse unifie ces trois capacités dans un écosystème cohérent pour analyser massivement les données.

GROUP BY : clause SQL qui regroupe les lignes partageant les mêmes valeurs dans une ou plusieurs colonnes, permettant d'appliquer des fonctions d'agrégation (COUNT, SUM, AVG...). À distinguer de ORDER BY (qui trie) et PARTITION BY (qui divise les données pour des calculs analytiques sans fusionner les lignes).

Clé étrangère : colonne qui référence la clé primaire d'une autre table, créant ainsi une relation entre elles. Elle garantit l'intégrité référentielle en s'assurant que chaque valeur existe réellement dans la table liée. Contrairement à la clé primaire (identifie les enregistrements) ou à l'index (optimise les requêtes), la clé étrangère établit des liens logiques entre tables.

Azure SQL Database : service PaaS qui offre une base de données relationnelle SQL entièrement managée. Microsoft gère les mises à jour, sauvegardes et haute disponibilité, vous concentrant sur les données. À distinguer de Cosmos DB (NoSQL documentaire), Blob Storage (stockage objet) et Files (partages réseau).

Réponse : Financial Statement Version (FSV)
La Financial Statement Version (FSV) structure la présentation des états financiers (bilan, compte de résultat) pour la clôture. Elle définit la hiérarchie des postes du bilan et du P&L en regroupant les comptes G/L selon les exigences légales et normatives.

Réponse : Client ; type de cours de change. Explication : Le choix entre cotation directe et cotation indirecte est configuré au niveau du client (paramètre système global) et peut également être défini par type de cours de change, permettant différentes méthodes de cotation pour différents types de taux (M, G, B, etc.).

Réponse : Classe d'immobilisation ; détermination des comptes. Explication : Le compte de clearing technique peut être défini à deux niveaux : au niveau de la classe d'immobilisation (pour les comptes de clearing spécifiques à la classe) et au niveau de la détermination des comptes (pour une affectation plus généralisée à travers plusieurs classes d'immobilisations).

Le groupe de tolérance fournisseur définit les limites acceptables pour le traitement automatique des différences lors du rapprochement des factures (MIRO) avec les bons de commande. Il paramètre : la tolérance absolue en montant (ex. : différence max 10 EUR), la tolérance en pourcentage, et le traitement des petites différences (comptabilisation automatique ou blocage). Sans groupe de tolérance, toute différence entre la facture et le bon de commande bloquerait le paiement automatique, nécessitant une intervention manuelle.

Réponse : Équilibrer les documents par segment ou centre de profit
Le Document Splitting permet de générer des états financiers équilibrés par entité de reporting (segment, centre de profit). Chaque document comptable est divisé de sorte que chaque ligne soit attribuée à une entité spécifique, permettant un reporting IFRS 8 précis.

La société (Company Code) est l'entité juridique autonome pour laquelle une comptabilité complète est établie — elle dispose de son propre plan comptable, exercice fiscal et devise de référence. Le groupe de sociétés (Company) est une entité de consolidation regroupant plusieurs sociétés pour les reportings de groupe (consolidation légale). Dans S/4HANA, une Company Code appartient à exactement un Client (mandant) et peut être rattachée à une Company pour la consolidation. Controlling Area est distinct : il regroupe des Company Codes pour la comptabilité analytique (CO).

Dans S/4HANA, l'intégration FI-AA est totale : chaque transaction d'actif (acquisition, cession, amortissement) génère simultanément un document d'immobilisation (dans le sous-module AA) ET un document comptable FI avec les écritures sur les comptes de bilan. Il n'y a plus de réconciliation périodique nécessaire comme en ECC — les deux modules sont synchronisés en temps réel. Le document d'immobilisation contient les données spécifiques (zone d'évaluation, clé d'amortissement) ; le document FI contient les imputations comptables.

Réponse : L'imputation s'effectue dans FI-AA et dans FI-GL en ligne et en temps réel. Explication : SAP S/4HANA utilise une intégration en temps réel entre FI-AA et FI-GL (via le Journal universel). L'amortissement extraordinaire s'impute directement dans la comptabilité des immobilisations et le grand livre simultanément sans nécessiter une exécution de rapprochement séparée.

Réponse : Vrai
Explication : Les espaces/pages offrent une navigation structurée par rôle et scénario ; les groupes sont considérés comme héritage et peuvent coexister durant la transition.

Réponse : Dans la commande d’achat avec une imputation par « catégorie A – Actif » et le numéro d’actif/numéro de poste d’actif.
Explication : L’affectation comptable de type A oriente la valorisation vers l’actif concerné.

Concept clé : Tests de discrimination en AI. Les testeurs doivent comparer les taux d'approbation entre les groupes démographiques en utilisant des profils financiers équivalents. Si les taux d'approbation diffèrent significativement entre des groupes ayant des références similaires, une discrimination est identifiée. Ce test axé sur l'équité garantit un traitement égal indépendamment des attributs protégés.

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 : Il peut fournir un appariement automatisé des incidents aux problèmes ou aux erreurs connues.
Explication : Les outils ITSM peuvent automatiquement associer de nouveaux incidents aux problèmes ou erreurs connus, accélérant ainsi le diagnostic et permettant d\'appliquer des solutions de contournement documentées.

Réponse : Progresser par itérations avec des retours.
Explication : Le principe \'Progresser par itérations avec des retours\' recommande de diviser le travail en petites étapes gérables avec des boucles de feedback fréquentes pour s\'adapter et corriger rapidement.

Réponse : Elle permet de diriger l\'incident vers la zone de support appropriée.
Explication : La catégorisation des incidents permet de les acheminer rapidement vers la bonne équipe de support, ce qui accélère leur résolution et améliore l\'efficacité du processus.

Réponse : Les centres de services doivent comprendre l\'organisation dans son ensemble.
Explication : Les centres de services doivent avoir une compréhension globale de l\'organisation pour orienter correctement les utilisateurs, comprendre les impacts des incidents et prioriser les demandes.

Réponse : Des procédures détaillées pour diagnostiquer les incidents.
Explication : La gestion des incidents vise une résolution rapide, pas la documentation détaillée de procédures de diagnostic. Les procédures détaillées relèvent de la gestion des problèmes et de la base de connaissances.

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 : 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.

Réponse : Le système de valeur des services.
Explication : Le système de valeur des services (SVS) est le concept ITIL 4 qui décrit comment tous les composants et activités, y compris la gouvernance, fonctionnent ensemble pour créer de la valeur.

Réponse : Le problème conserve l\'état d\'erreur connue.
Explication : Lorsqu\'une solution de contournement devient permanente car le problème ne peut être résolu définitivement, le problème reste dans l\'état \'erreur connue\' : documenté mais non résolu.

• PaaS fournit un environnement cloud prêt à l’emploi pour développer, exécuter et gérer des applications ou traitements, sans gérer l’infrastructure sous-jacente (VM, stockage, réseau).

• Dans ce scénario :

  • L’équipe peut créer et exécuter des jobs big-data

  • Tout l’environnement est géré par le fournisseur (ex. Azure Synapse Analytics, Azure Databricks)
    
    

    🎯 À retenir pour l’examen MS-900 :

    • PaaS = plateforme gérée pour créer et exécuter des applications ou jobs sans gérer l’infrastructure

    • IaaS = gérer l’infrastructure

    • SaaS = utiliser l’application

    • Hybrid = combinaison cloud et on-prem

• Les abonnements Microsoft 365 peuvent être renouvelés automatiquement avec des méthodes de paiement directes comme :

  • Carte de crédit

  • Prélèvement bancaire

  • PayPal

• La facturation par invoice (facture) nécessite un paiement manuel pour chaque période, donc le renouvellement automatique n’est pas possible.

Pour protéger l’accès aux données d’entreprise sur les appareils mobiles :

1. Intune App Protection Policies (politiques de protection d’application) :

   • Permettent de protéger les applications professionnelles (ex : Outlook, Teams) même sur des appareils personnels.

   • Restreignent l’accès aux applications si l’appareil ne respecte pas les règles de conformité (ex : pas de chiffrement, jailbreak détecté).

2. Conditional Access (Accès conditionnel) :

   • Applique des conditions pour accéder aux ressources cloud (ex : Exchange Online).

   • Peut bloquer l’accès aux e-mails si l’appareil est non conforme ou compromis selon les signaux d’Intune.

✅ Ensemble, ces deux fonctionnalités permettent de sécuriser l’accès aux e-mails sur mobiles sans recourir à des solutions tierces.

• Privileged Identity Management (PIM) permet :

  • D’attribuer des rôles à durée limitée (ex : Intune Service Administrator)

  • De respecter le principe du moindre privilège, car le technicien n’a les droits élevés que pendant le dépannage

• Les autres options ne donnent pas un accès temporaire contrôlé :

  • Conditional Access → contrôle l’accès, pas la durée des droits

  • Defender for Endpoint → gère la sécurité des appareils, pas les permissions

  • Access Reviews / Global Reader permanent → donne un accès permanent, contraire au principe du moindre privilège

🎯 À retenir pour l’examen MS-900 :

• PIM = droits élevés temporaires pour dépannage ou administration

• Toujours attribuer des permissions limitées dans le temps, plutôt que permanentes, pour sécuriser les comptes administrateurs.

• La Timeline view (vue Chronologie) permet :

  • D’afficher les tâches ou phases sur une ligne de temps

  • De visualiser clairement les dates de début et de fin

  • D’avoir une vue simple et synthétique adaptée à un partage dans Teams

Elle est idéale pour donner une vue globale rapide du projet.

❌ Pourquoi les autres réponses sont incorrectes :

• A. Gantt Chart view → Plus détaillée et orientée gestion avancée (dépendances, planification complexe). Moins “simple” pour un aperçu rapide.

• B. Project Roadmap → Sert à consolider plusieurs projets, pas juste à afficher un planning simple d’un projet.

• D. Calendar view → Affiche les tâches par date dans un calendrier, mais ne donne pas une vision linéaire claire des phases.

🎯 À retenir pour l’examen MS-900 :

• Timeline view = vue simple et visuelle des dates de début et fin

• Gantt = gestion avancée

• Calendar = vue mensuelle/journalière
  Roadmap = consolidation multi-projets
  
  

• 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.

• Cette méthode permet d’installer l’application sur les appareils Windows 10.

• Le Configuration Profile configure certains paramètres de l’appareil, mais ne garantit pas la configuration des paramètres internes spécifiques à l’application.

• Convient pour des applications MSI simples, mais pas pour des applications personnalisées nécessitant des paramètres préconfigurés.

✅ En résumé : C installe l’app, mais A est nécessaire pour installer + configurer les paramètres internes de l’application.

• 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.

• Par défaut, les journaux d’audit Microsoft 365 ont une durée de conservation limitée.

• Pour les conserver plus longtemps (ex. 1 an ou plus), il faut configurer une Audit log retention policy dans Microsoft Purview.

• Cela permet de répondre aux exigences réglementaires et de conformité.

❌ Pourquoi les autres réponses sont incorrectes :

• B. Litigation Hold (Exchange) → Concerne la conservation des emails, pas les journaux d’audit globaux.

• C. Sensitivity label retention → Gère la protection et la conservation des documents/emails, pas des logs d’audit.

• D. Azure Information Protection → Sert à classifier et protéger les données, pas à gérer la durée des logs d’audit.

🎯 À retenir pour l’examen MS-900 :

• Audit logs = Microsoft Purview (Audit log retention policy)

• Litigation Hold = emails

• Sensitivity labels = protection des données

• Identity Protection sign-in risk policy permet :

  • Détecter automatiquement les connexions suspectes ou compromises

  • Appliquer des actions automatisées comme blocage d’accès ou réinitialisation de mot de passe selon le niveau de risque configuré

• Les autres options ne remplissent pas ce rôle spécifique :

  • A : Conditional Access contrôle l’accès basé sur les conditions, mais ne déclenche pas automatiquement en fonction du risque de connexion.

  • B : Smart Lockout protège contre les tentatives de mot de passe incorrectes, mais pas contre les risques détectés par analyse des sign-ins.

  • C : Password Protection empêche l’utilisation de mots de passe faibles ou compromis, mais ne réagit pas automatiquement à un risque de connexion.

• Principe MCRA : « Protect data wherever it resides » → protéger les données indépendamment de l’endroit où elles sont stockées ou partagées.

• Microsoft Purview Information Protection (MIP) permet :

  • Classifier les données sensibles (PII, données financières, propriété intellectuelle…)

  • Appliquer des labels de sensibilité qui suivent les données, peu importe qu’elles soient stockées dans :

    • Azure Storage, SharePoint, OneDrive

    • Emails Microsoft 365

    • Applications tierces intégrées

• Ainsi, MIP fournit une protection centrée sur les données, alignée avec le principe MCRA.

• Microsoft Defender for Cosmos DB fournit :

  • Détection en temps réel des activités suspectes sur les bases Cosmos DB

  • Alertes pour :

    • Accès depuis des localisations géographiques inhabituelles

    • Tentatives de connexion ou d’exfiltration de données

    • Activités anormales des comptes ou clés d’accès

• Avantages clés :

  • Intégration avec Microsoft Sentinel pour investigations et réponses automatisées

  • Complète les mesures de chiffrement et d’accès, mais ajoute la détection comportementale

• DLP (Data Loss Prevention) dans Microsoft Purview :

  • Permet d’identifier automatiquement les informations sensibles, y compris les PHI

  • Empêche le partage accidentel ou non autorisé dans Teams, SharePoint, OneDrive et Outlook

  • Fonctionne en temps réel, donc même si Copilot est utilisé, les données sensibles ne sont pas exposées

• C’est la solution la plus efficace pour protéger les données sensibles tout en autorisant l’usage normal de Copilot.

Microsoft Defender for IoT (anciennement Azure Defender for IoT) permet de :

• Surveiller passivement le trafic réseau des PLC et autres équipements industriels

• Détecter des anomalies de protocole, mouvements latéraux et comportements suspects

• Ne nécessite pas d’installation directe sur les PLC → aucune perturbation des lignes de production

• Utilise port mirroring sur les switchs pour analyser le trafic réseau de manière non intrusive

Pourquoi c’est adapté :

• Les PLC sont souvent systèmes propriétaires où l’installation d’agents est risquée ou impossible

• La surveillance passive permet de détecter les menaces sans interrompre la production

• Hotpatch :

  • Fonctionnalité Azure-only pour Windows Server

  • Applique les mises à jour de sécurité critiques sans redémarrage complet

  • Réduit les interruptions de service pour les workloads sensibles (ex : santé, finance)

  • Permet un contrôle administratif, mais avec automatisation pour les correctifs critiques

• Cette approche est le compromis idéal entre patching manuel (risque faible mais effort élevé) et automatisation complète (risque de redémarrage inattendu).

• MCAS / Defender for Cloud Apps :

  • Fournit visibilité complète sur les applications SaaS connectées à Entra ID

  • Identifie les applications non approuvées ou risquées

  • Permet de :

    • Appliquer des politiques d’accès

    • Restreindre ou contrôler l’usage des applications

    • Surveiller les activités et détecter les risques liés aux utilisateurs et aux sessions

• C’est la solution Microsoft recommandée pour le Shadow IT et la gouvernance SaaS.

• Contexte : en cas de panne régionale Azure, les utilisateurs critiques ne peuvent plus s’authentifier via Entra ID.

• Break-glass accounts (comptes de secours) :

  • Comptes hors des dépendances normales d’Azure AD

  • Permettent aux administrateurs et opérateurs critiques d’accéder aux systèmes essentiels

  • Généralement cloud-only, non soumis aux politiques Conditional Access complexes

  • Doivent être audités, sécurisés et testés régulièrement

• C’est une bonne pratique Microsoft pour la continuité et la résilience :

  • Garantit que les opérations critiques peuvent continuer même si Entra ID ou Azure rencontre une panne

• LSASS (Local Security Authority Subsystem Service) stocke les hashes et tokens d’authentification Windows.

• Les attaquants peuvent utiliser des techniques comme Mimikatz pour voler des credentials depuis LSASS.

• Windows Defender Credential Guard :

  • Utilise la virtualisation basée sur le hardware pour isoler les secrets Windows (NTLM, Kerberos, LSA secrets)

  • Empêche les logiciels malveillants et les attaquants ayant un accès administrateur local de voler les credentials

  • Protège spécifiquement les domain controllers et endpoints sensibles

• C’est la meilleure pratique Microsoft pour sécuriser les contrôleurs de domaine contre le vol de credentials.

Microsoft Defender for Cloud – multi-cloud capabilities :

• Permet de centraliser la gestion de la posture de sécurité sur plusieurs clouds

• Offre assessments, recommandations et alertes de sécurité pour Azure, AWS et GCP

• Les connecteurs multi-cloud :

  • Onboard facilement les comptes AWS/GCP

  • Surveillent les configurations, vulnérabilités et risques

  • Fournissent des recommandations cohérentes à travers les environnements

• Intune Device Compliance Reports permettent de :

  • Voir exactement quelles règles ne sont pas respectées pour chaque appareil

  • Identifier si le problème vient de BitLocker, antivirus, ou autre

  • Prendre des mesures correctives précises plutôt que de contourner la politique

• Cette approche assure que :

  • La conformité et la sécurité restent intactes

  • Les utilisateurs bloqués obtiennent une explication et un correctif ciblé

Le calculateur de prix GCP est l'outil officiel pour estimer les coûts mensuels sans provisionner réellement les ressources. Examiner les pages de tarification garantit d'utiliser les prix actuels et exacts pour chaque produit.

La façon recommandée est de spécifier le compte de service lors de la création de chaque instance. Une fois créée, l'instance utilise ce compte de service pour toutes les appels APIs. Les métadonnées ne définissent pas le compte de service actif.

La bonne pratique est d'utiliser des groupes Cloud Identity (facilement maintenables) et le rôle BigQuery jobUser (permet d'exécuter des requêtes). dataViewer seul ne permet pas d'exécuter des jobs. Gérer des entrées IAM individuelles est inefficace avec une équipe changeante.

La commande BigQuery dry-run estime les octets lus (scannés depuis les tables) sans exécuter la requête. Attention : la facturation est basée sur les octets lus, pas sur les octets retournés — une requête `SELECT *` sur une table de 1 To coûte la même chose qu'elle retourne 1 ligne ou 1 million. Le calculateur de prix convertit ensuite ce volume en dollars.

Accorder le rôle Compute Storage Admin dans le projet proj-vm au compte de service de proj-sa lui donne les permissions nécessaires pour créer des snapshots. C'est la méthode recommandée : pas de clés privées à gérer, les permissions sont données au niveau IAM.

Les journaux d'accès aux données Cloud Storage (activés au niveau du bucket) enregistrent qui a accédé à quels objets. Le visualiseur de journaux avec filtre Cloud Storage permet à l'auditeur de consulter exactement ces accès.

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.

L'export de facturation vers BigQuery est automatique et inclut les nouvelles données en quasi-temps réel. Data Studio peut se connecter à BigQuery pour créer des visualisations dynamiques couvrant tous les projets et comptes de facturation en une seule vue.

Le navigateur décide d'afficher ou de télécharger un fichier selon l'en-tête Content-Type. En définissant les métadonnées Content-Type à application/pdf sur les objets, le navigateur recevra cet en-tête et affichera le PDF directement.

La bonne pratique est d'ajouter un tag réseau à l'instance puis de créer une règle de pare-feu ingress qui autorise UDP 636 sur ce tag. Simplement ajouter un tag sans règle de pare-feu n'ouvre aucun port. Les routes ne contrôlent pas les ports.

Les rôles corrects au sein d'une Scrum Team sont le Development Team, le Scrum Master et le Product Owner (option 1). Ces trois rôles sont explicitement définis dans le Scrum Guide. Les autres options introduisent des rôles non-Scrum tels que Project Manager, Business Analyst, ou considèrent les Parties Prenantes comme un rôle à part entière — or, les parties prenantes sont externes à la Scrum Team.

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.

Ces trois facteurs ont un impact sur les résultats du Sprint. Le Guide Scrum souligne que les résultats d'un Sprint dépendent de la composition de l'équipe, des compétences, des relations de travail, de la complexité technologique et de la clarté des exigences. Ce sont des variables interdépendantes qui déterminent collectivement ce qu'une équipe peut accomplir au cours d'un Sprint donné.

Une équipe de développement auto-organisée décide collectivement de la manière d'accomplir son travail et est responsable de la création de son Sprint Backlog en tenant compte de la Définition of Done. Les options C et E sont correctes : L'option C illustre une replanification collaborative tout au long du Sprint (auto-organisation), et l'option E montre l'équipe créant son propre Sprint Backlog en respectant la Definition of Done. L'option A reflète des silos basés sur les rôles (absence d'auto-organisation), l'option B implique une optimisation par le management (direction externe), et l'option D introduit des personnes extérieures (ce qui nuit à l'autonomie de l'équipe).

La Development Team est responsable de toutes les estimations dans Scrum. Le Scrum Master ne doit pas imposer le format (Story Points ou autres unités relatives) ni l'ordre d'estimation — seule la Development Team est propriétaire du processus d'estimation. Cela protège l'autonomie et la responsabilité de l'équipe.

Correct : Options 2, 3 et 5 - Les Scrum Masters efficaces utilisent le coaching, la formation et la sensibilisation des parties prenantes pour aider les organisations à adopter Scrum de manière durable. L'option 1 viole les principes de conduite du changement ; l'option 4 contredit les valeurs collaboratives de Scrum ; l'option 6 prolonge les événements au-delà de leur objectif initial, ce qui dilue leur efficacité.

Donner le meilleur de soi-même et soutenir ses coéquipiers incarne la valeur Scrum d'Engagement—s'engager à atteindre le Sprint Goal et à soutenir l'équipe. Bien que cela puisse contribuer à la performance, la question demande quelle valeur cela illustre le plus directement, à savoir l'engagement envers l'excellence et la réussite collective.

Organiser une réunion de triage avec les chefs de projet serait le moins utile, car cela retire la prise de décision à la Scrum Team et à la gouvernance appropriée de l'organisation. Le Scrum Master devrait plutôt consulter le Development Team, prioriser les obstacles et escalader auprès de la direction concernant l'impact — en maintenant d'abord la responsabilité au sein de la Scrum Team.

Le rôle du management dans Scrum est de créer un environnement favorable, et non de microgérer ou de surveiller les performances individuelles. Selon le Guide Scrum, le management doit fournir des informations et des ressources qui soutiennent les Scrum Teams. Les options concernant le renvoi de personnes, la surveillance des niveaux de compétences ou le suivi de la vélocité représentent des comportements de type commande-et-contrôle qui vont à l'encontre des principes empiriques et auto-organisationnels de Scrum.

La bonne réponse (option 2) identifie que le manque de transparence du Scrum Master et du Product Owner, combiné au désengagement des parties prenantes lors des Sprint Reviews, a conduit à des attentes mal alignées. Le pilier de transparence de Scrum exige une inspection régulière par les parties prenantes lors des Sprint Reviews. Les autres options attribuent incorrectement les responsabilités ou se concentrent sur des facteurs non pertinents tels que la vélocité ou les diagrammes de Gantt.

Réponse : Définir les attentes concernant les tâches et les livrables / Canaux de communication clairs / Cultures possiblement différentes.
Explication : BCD est correct. L\'externalisation introduit des ambiguïtés contractuelles sur les livrables, nécessite des canaux de communication robustes et expose le projet à des différences culturelles. La définition précise des attentes, des critères d\'acceptation et des SLA est essentielle pour éviter les dérives de périmètre et les litiges.

Réponse : Portabilité.
Explication : C est correct car la portabilité est un attribut non-fonctionnel de faible priorité pour un système de surveillance médicale critique pour la sécurité, normalement lié à des piles matériel/système d\'exploitation certifiées. La disponibilité, la sécurité et la fiabilité ont un impact direct sur le risque patient et les preuves réglementaires.

Réponse : Gestion et pilotage de projet.
Explication : B est correct car la gestion et le pilotage de projet sont des préoccupations transversales à tous les cycles de vie, non spécifiques au test en RAD. Les attributs distinctifs du RAD—prototypage itératif, exigences évolutives, délais serrés—créent des problèmes centrés sur le test : exigences instables, régressions fréquentes, cycles de test compressés.

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 : 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 : 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 : Cela peut servir à renforcer leur confiance dans le système.
Explication : C est correct car impliquer les utilisateurs lors de l\'exécution renforce principalement leur confiance et leur acceptation en validant le comportement du système par rapport aux attentes opérationnelles réelles. D\'un point de vue avancé de gestion des tests, la participation des utilisateurs est une intervention d\'engagement des parties prenantes qui réduit le risque de déploiement.

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 : Une approche des tests de régression.
Explication : Le plan directeur de test est un document stratégique de haut niveau qui définit l\'approche globale, la portée, les objectifs et les risques. L\'approche des tests de régression est une décision stratégique appropriée à couvrir en détail, contrairement aux détails tactiques comme les valeurs limites ou l\'organisation des cas de test.

Réponse : Un aperçu détaillé de l\'approche de test basée sur les risques utilisée pour assurer la réalisation des critères de sortie..
Explication : D est correct car les cadres supérieurs non-spécialistes ont besoin d\'informations concises et orientées résultats, non d\'une exposition détaillée opérationnelle de l\'approche basée sur les risques. Un rapport doit prioriser l\'état versus objectifs, risques clés et atténuations, tendances et actions managériales recommandées pour décisions efficaces.

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. 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. Des URLs sur lesquelles les utilisateurs peuvent cliquer pour ouvrir le document dans leur navigateur. Incorrect. Les URLs sont utiles pour les utilisateurs, mais ne sont pas idéales pour les agents effectuant des workflows en plusieurs étapes nécessitant un référencement fiable et des opérations supplémentaires. B. Des données structurées contenant les identifiants de documents et les métadonnées pour chaque résultat. Correct. Cela permet à l'agent de référencer de manière programmatique des documents spécifiques (via des identifiants) à travers plusieurs étapes, rendant les workflows tels que les requêtes de suivi ou la récupération de documents précis et fiables. C. Un tableau JSON de titres de documents extraits des résultats de recherche. Incorrect. Les titres seuls sont ambigus et ne constituent pas des identifiants stables, ce qui rend difficile pour les agents d'agir de manière fiable sur des documents spécifiques. D. Des descriptions plus détaillées et lisibles par l'humain, incluant la taille et les auteurs. Incorrect. Utile pour les utilisateurs, mais toujours non structuré et non adapté à des opérations précises d'agents en plusieurs étapes.

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.

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. Définir la température à 0 pour éliminer la variabilité des sorties et garantir un formatage cohérent — Incorrect. Cela réduit l'aléatoire mais ne corrige pas les erreurs d'extraction systématiques comme la mauvaise interprétation des plages (« 2 à 3 »). B. Envoyer une requête de suivi incluant l'erreur de validation, en demandant au modèle de corriger sa sortie — Correct. Fournir un retour de validation précis permet au modèle de corriger le problème exact (par exemple, convertir « 2 à 3 » en un nombre flottant valide), rendant la récupération très efficace. C. Pré-traiter les documents sources pour standardiser les formats problématiques avant de les envoyer à l'extraction — Incorrect. Utile dans certains cas, mais pas évolutif ni suffisant pour gérer la diversité des variations du monde réel. D. Mettre en place un pipeline secondaire utilisant un modèle de niveau supérieur pour retraiter les documents qui échouent à la validation — Incorrect. Plus coûteux et inutile — la correction ciblée est plus efficace et plus performante.

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. 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.

A. Créer une nouvelle playlist « Focus » avec des titres sélectionnés et notifier l'utilisateur qu'elle est prête. Incorrecte. Cette option suppose une intention et risque d'effectuer la mauvaise action, ce qui frustre les utilisateurs. B. Poser une question de clarification sur le type d'action : écouter maintenant ou configurer pour plus tard. Correcte. Cela minimise les frictions tout en résolvant l'ambiguïté, permettant à l'assistant d'effectuer rapidement la bonne action. C. Lancer immédiatement des titres populaires de concentration et laisser l'utilisateur rediriger si nécessaire. Incorrecte. Agit prématurément et peut ne pas correspondre à l'intention de l'utilisateur. D. Démarrer la configuration des préférences en posant des questions sur les genres, le tempo et les artistes. Incorrecte. Trop lourd en amont — ajoute des frictions inutiles avant de confirmer l'intention.

A. Persister l'intégralité de l'historique de conversation et des réponses aux outils dans une base de données, puis appeler escalate_to_human avec un identifiant de référence — Incorrect. Utile sur le plan opérationnel, mais l'agent humain a tout de même besoin d'un résumé concis et exploitable plutôt que de simples journaux bruts. B. Appeler escalate_to_human en ne transmettant que le message original du client — Incorrect. Cela perd le travail d'investigation déjà effectué et oblige l'agent humain à répéter les étapes. C. Tenter le remboursement avec process_refund quoi qu'il arrive, en escaladant uniquement si le système rejette la transaction — Incorrect. Cela viole les limites d'autorisation et la politique métier. D. Compiler une passation de contexte structurée incluant les détails du client, les informations de commande et le problème identifié avant d'appeler escalate_to_human — Correct. Une passation structurée préserve le contexte, réduit les répétitions et permet à l'agent humain de continuer efficacement.