Ne découvrez pas l'examen
le jour J

Réponse : Augmentation de la vitesse et de l’agilité, et sécurité physique prise en charge.
Explication : AWS offre une rapidité accrue pour déployer des applications et prend en charge la sécurité physique et réseau.

Réponse : AWS Auto Scaling.
Explication : AWS Auto Scaling ajuste dynamiquement le nombre d’instances EC2 en fonction de la charge réelle.

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 : Amazon Inspector. Explication : Amazon Inspector est un service automatisé de gestion des vulnérabilités qui analyse continuellement les instances EC2 pour détecter les vulnérabilités de logiciels et l'exposition réseau non intentionnelle. Il contrôle également le respect des bonnes pratiques de sécurité AWS.

Réponse : Gestion des correctifs de l’infrastructure sous-jacente / Chiffrement du système de fichiers.
Explication : En tant que client, vous êtes responsable de la gestion des correctifs sur vos ressources et du chiffrement des données, alors qu’AWS gère la couche physique et l’hyperviseur.

Réponse : A) Coût des licences logicielles d'application. Lors de la migration vers AWS, les clients conservent la responsabilité de leurs propres licences logicielles d'application. AWS gère les coûts du matériel, de la mise en réseau et de l'hyperviseur, mais les frais de licence au niveau de l'application restent la responsabilité directe du client selon le modèle de responsabilité partagée.

Detective : analyse les logs VPC Flow, CloudTrail et GuardDuty pour investiguer les incidents. Crée des graphes d'entités et timelines pour identifier rapidement la cause racine des alertes.

Réponse : Réduction des dépenses d’investissement (CapEx).
Explication : En migrant vers AWS, les coûts initiaux (CapEx) sont réduits au profit de dépenses variables (OpEx).

Réponse : Accroître la disponibilité de l’application.
Explication : Répartir une application sur plusieurs AZ la rend plus résiliente en cas de panne locale (c’est un principe clé d’architecture cloud AWS).

Réponses : AWS Cost Explorer et AWS Compute Optimizer. AWS Cost Explorer analyse les modèles d'utilisation et de dépenses historiques pour identifier les instances sous-utilisées. AWS Compute Optimizer utilise l'apprentissage automatique pour analyser les métriques d'utilisation EC2 et recommander les types et tailles d'instances optimaux.

SageMaker Serverless Inference : service AWS qui déploie des modèles sans gérer manuellement les instances EC2. AWS provisionne et scale automatiquement les ressources selon la demande, réduisant la complexité opérationnelle. Contrairement à SageMaker Hosting traditionnel (instances EC2 dédiées), Serverless facture à l'usage et élimine le surprovisionnement.

OpenSearch k-NN : capacité native de recherche par k-plus proches voisins sur vecteurs d'embeddings. Essentiel pour RAG car permet de retrouver rapidement documents sémantiquement similaires sans requête textuelle exacte. Contrairement aux recherches textuelles traditionnelles (Elasticsearch), k-NN compare les embeddings dans l'espace vectoriel pour capturer le sens contextuel.

Amazon Bedrock Invocation Logging : service dédié qui capture automatiquement chaque prompt envoyé et chaque réponse générée par les modèles. Contrairement à CloudTrail (logs API uniquement), EventBridge (routage d'événements) ou Trusted Advisor (optimisation), seul Bedrock Invocation Logging offre la traçabilité complète des contenus pour auditer, déboguer et améliorer la qualité des applications GenAI.

Guardrails for Amazon Bedrock : service de sécurité qui implémente des politiques de filtrage personnalisables pour les modèles d'IA. Il détecte et bloque le contenu toxique, les thèmes sensibles (violence, langage adulte) et applique des listes de blocage (deny lists). Cela protège les applications destinées aux enfants en garantissant que les réponses générées respectent les normes de sécurité définies par l'entreprise, indépendamment du modèle utilisé.

PDPs vs SHAP/LIME : Les Partial Dependence Plots montrent l'effet global moyen d'une variable sur les prédictions, idéaux pour comprendre les tendances générales. SHAP et LIME, méthodes locales, expliquent chaque prédiction individuelle en détaillant la contribution de chaque feature. PDPs ne révèlent pas les interactions complexes ni les explications instance-spécifiques que demandent les stakeholders pour auditer les décisions critiques.

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 SageMaker Feature Store : gestionnaire centralisé de features avec deux stores (online/offline). L'ordre logique est : d'abord définir le feature group (schéma, métadonnées), puis ingérer les données (avec versioning et gouvernance), ensuite requête offline pour training (historique complet), enfin servir online pour inférence (latence faible). Les distracteurs inversent cet ordre : ingérer avant de définir le groupe échouerait (pas de schéma), servir online avant l'ingestion manquerait de données.

AWS Artifact + Amazon SNS : AWS Artifact fournit les rapports de conformité (SOC, ISO), tandis qu'Amazon SNS gère les notifications par email automatiques lors de leur publication. SNS est le service de notification d'événements, contrairement à SES (envoi transactionnel), CloudTrail (audit d'API) ou EventBridge (routage d'événements métier).

L'IA générative transforme de nombreux processus métier. La génération de résumés automatiques de documents longs (contrats, rapports) réduit le temps d'analyse. Les chatbots intelligents pour le service client répondent de manière contextuelle. La génération de code accélère le développement logiciel. La maintenance prédictive classique ou la détection de fraude reposent généralement sur du ML supervisé, pas sur de la GenAI.

CloudTrail pour le contrôle d'accès Bedrock : CloudTrail enregistre toutes les appels API AWS (InvokeModel, CreateAgent, etc.) avec identité de l'appelant, timestamp et résultat. Cela permet de tracer les tentatives d'invocation non autorisées et de générer des alertes de sécurité. Contrairement à CloudWatch Logs (métriques de performance) ou IAM Policies (contrôle préventif), CloudTrail fournit l'audit rétrospectif nécessaire pour la conformité.

Réponse : Participer en tant que membre de la Scrum Team.
Explication : La Sprint Retrospective est un événement impliquant toute l'équipe. Le Product Owner y participe en tant que membre à part entière de l'équipe pour réfléchir sur la collaboration, les processus et les relations — et non dans son rôle de Product Owner gérant le Backlog.

Les cinq valeurs Scrum sont l'Engagement, le Courage, la Focalisation, l'Ouverture et le Respect. Ces valeurs donnent une direction au travail, aux actions et aux comportements de la Scrum Team. Lorsqu'elles sont incarnées et vécues par la Scrum Team, les piliers que sont la Transparence, l'Inspection et l'Adaptation prennent vie et instaurent la confiance. Sans ces valeurs, Scrum n'est qu'un ensemble d'événements et d'artefacts dénués de sens.

Réponse : La Development Team.
Explication : La Development Team gère et suit sa propre progression durant le Sprint. Elle met à jour le Sprint Backlog, suit le travail restant et adapte son plan quotidiennement. Le Scrum Master ou le Product Owner ne gère pas la progression de l'équipe.

Réponse : La Scrum Team, dans un effort collaboratif.
Explication : L'ensemble de la Scrum Team crée la Definition of Done de manière collaborative. Si l'organisation dispose de standards, ceux-ci constituent le minimum. L'équipe peut uniquement renforcer ces standards organisationnels, jamais les affaiblir.

Réponse : Une durée de Sprint constante tout au long du développement ; tous les Sprints doivent durer un mois ou moins.
Explication : Scrum impose une durée maximale d'un mois calendaire pour un Sprint. Des durées de Sprint constantes établissent un rythme de développement prévisible et rendent les prévisions basées sur la vélocité fiables.

Objectif de la Sprint Retrospective : Elle inspecte le processus et les résultats du Sprint afin d'identifier des améliorations. L'équipe réfléchit aux personnes, aux interactions, aux processus et aux outils — et non aux fonctionnalités du produit. Contrairement à la Sprint Review (retours des parties prenantes sur l'Increment) ou à la Sprint Planning (création du Sprint Backlog), la Retrospective se concentre sur la performance de l'équipe et l'amélioration continue du processus.

Réponse : L'événement ne peut pas dépasser une durée maximale fixée.
Explication : Une time-box est une durée maximale fixe pour un événement Scrum. L'événement doit se terminer lorsque son objectif est atteint, même si le temps maximum n'a pas été écoulé. Il ne peut pas être prolongé au-delà de cette durée maximale.

Réponse : En fonction des besoins, en tenant compte d'une réduction temporaire de la productivité.
Explication : Les Scrum Teams doivent être stables afin de construire la collaboration et la confiance. Les changements d'équipe doivent être effectués de manière réfléchie et uniquement lorsqu'il existe un bénéfice clair qui l'emporte sur la perte temporaire de productivité liée à la reformation de la dynamique d'équipe.

L'inspection d'un artefact non transparent est trompeuse et constitue un gaspillage, et une adaptation basée sur des informations incomplètes conduit à de mauvaises décisions. Les trois piliers sont séquentiels et interdépendants : il faut d'abord disposer de la transparence (visibilité sur le processus), puis inspecter ce qui est visible, et seulement alors il est possible d'adapter de manière pertinente. Une transparence incomplète crée une illusion de contrôle tout en masquant les problèmes réels.

Taille limite de la Scrum Team : Le Guide Scrum recommande de limiter les Scrum Teams à 10 personnes maximum (Scrum Master et Product Owner inclus) afin de maintenir l'agilité, de réduire la charge de communication et de favoriser une collaboration et une prise de décision efficaces.

Concept clé : Objectif de Sprint vs. Périmètre fixe. Dans Scrum, les Développeurs s'engagent à atteindre l'Objectif de Sprint — un objectif commun qui offre une certaine flexibilité — plutôt qu'une liste figée et immuable d'éléments du Product Backlog. Au cours du Sprint, l'équipe peut négocier des ajustements de périmètre avec le Product Owner afin de mieux servir l'Objectif de Sprint tout en s'adaptant aux nouvelles informations ou aux obstacles rencontrés. Cette approche adaptative distingue Scrum des méthodes traditionnelles en cascade. L'Objectif de Sprint reste constant ; les éléments qui le soutiennent peuvent évoluer, garantissant ainsi que l'équipe délivre un maximum de valeur tout en maintenant sa concentration et sa responsabilité.

Explication de la réponse correcte : Le Product Goal est un objectif à long terme qui définit ce que le produit aspire à devenir et fournit une cible stratégique vers laquelle l'équipe Scrum travaille. Il guide le développement du produit dans le temps et aide l'équipe à comprendre la finalité globale au-delà des Sprints individuels.

Pourquoi les autres réponses sont incorrectes : Les critères d'acceptation concernent des user stories spécifiques, et non la direction globale du produit. Un plan de projet détaillé va à l'encontre de la nature adaptative de Scrum et de la flexibilité du Product Owner. L'engagement du Sprint fait référence au Sprint Goal, qui est un objectif à plus court terme pour un seul Sprint, et non au Product Goal dans son ensemble.

Réponse : Il dure 15 minutes ou moins ; le lieu et l'heure restent constants.
Explication : Le Daily Scrum est limité dans le temps à 15 minutes et se tient chaque jour à la même heure et au même endroit afin de réduire la complexité et d'ancrer l'habitude d'inspection et d'adaptation quotidiennes.

Concept clé : Résultats (outcomes) versus livrables (outputs). Les résultats représentent les véritables bénéfices métier et l'impact utilisateur générés par les fonctionnalités du produit (par exemple, une meilleure engagement des utilisateurs, la croissance des revenus, la réduction des coûts de support), tandis que les livrables correspondent simplement aux fonctionnalités développées. Le Product Owner mesure la valeur réelle à travers les résultats — les effets concrets et les bénéfices obtenus — plutôt qu'en comptabilisant simplement le travail accompli. Cela s'aligne avec les principes de la Gestion Basée sur les Preuves (Evidence-Based Management, EBM), qui mettent l'accent sur la prise de décision fondée sur les données et le suivi des résultats métier mesurables. En se concentrant sur les résultats, le Product Owner peut valider si le produit résout effectivement les problèmes des utilisateurs et apporte de la valeur à l'organisation, ce qui permet de meilleures décisions de priorisation et une amélioration continue de la stratégie produit. Les propositions suggérant que la mesure de la valeur se limite à la vélocité, au nombre de User Stories complétées ou au nombre de fonctionnalités ignorent le principe fondamental de Scrum selon lequel livrer des Incréments n'a de valeur que s'ils génèrent des résultats significatifs pour les utilisateurs et l'entreprise.

La transparence du Product Backlog requiert deux choses : il doit être accessible à toutes les parties prenantes (pas de backlog caché) et il doit être ordonné (afin que les priorités soient sans ambiguïté). L'utilisation d'un outil spécifique, l'attribution de priorités MoSCoW ou la limitation à 2 Sprints de travail sont des pratiques optionnelles qui peuvent ou non favoriser la transparence. C'est l'ordonnancement qui transforme une simple liste en un Product Backlog priorisé que chacun peut inspecter.

Concept clé : La Definition of Done (DoD) représente l'engagement formel qui définit ce que signifie « terminé » pour tout Increment. Selon le Guide Scrum 2020, la DoD est l'engagement explicite de l'équipe concernant les standards de qualité et les critères d'acceptation qui doivent être satisfaits avant qu'un travail soit considéré comme achevé. Chaque élément de l'Increment doit respecter la DoD afin de garantir la transparence, de réduire les reprises de travail et de maintenir une qualité constante. Cette compréhension partagée évite tout désalignement entre la Scrum Team et les parties prenantes quant à ce qui constitue un Increment de produit potentiellement livrable. La DoD n'est pas simplement une liste de contrôle — c'est l'engagement fondamental qui permet à l'équipe de livrer de la valeur de manière prévisible et de maintenir l'intégrité du produit tout au long du processus de développement.

L'Ouverture et le Respect sont les valeurs correctes, car des décisions transparentes sur le Product Backlog témoignent d'ouverture en partageant clairement les informations avec l'équipe et les parties prenantes, et de respect en valorisant leurs contributions et leur compréhension des priorités. Bien que l'Engagement et la Focalisation soient des valeurs Scrum importantes, elles ne sont pas directement soutenues par la transparence en elle-même — la transparence est le fondement qui permet à ces valeurs de s'épanouir. Le Courage seul ne reflète pas la nature collaborative d'une prise de décision transparente.

Réponse : Intégré au Product Backlog.
Explication : Les bugs sont des éléments du Product Backlog et sont gérés comme n'importe quel autre élément — ordonnancés par le Product Owner.

Concept clé : Propriété et finalité du Sprint Backlog. Le Sprint Backlog appartient aux Developers car ils le créent lors du Sprint Planning pour définir leur travail pour le Sprint en cours. Cet artifact représente l'engagement des Developers à atteindre l'Objectif du Sprint grâce aux éléments du Product Backlog sélectionnés et aux tâches nécessaires pour les réaliser. Les Developers maintiennent et mettent à jour le Sprint Backlog tout au long du Sprint, ce qui en fait leur plan, et non celui du management ou un mandat du Product Owner. Cette appropriation garantit la transparence, la responsabilité et l'autonomie — des principes fondamentaux de Scrum. Contrairement au Product Backlog (appartenant au Product Owner) ou à l'Increment (le résultat de leur travail), le Sprint Backlog est exclusivement le document de travail des Developers.

Réponse : Collaborer pour définir un Sprint Goal et clarifier le contenu.
Explication : Le Product Owner présente l'objectif du produit, propose un ou plusieurs Sprint Goals, et collabore avec l'équipe pour clarifier les éléments du Product Backlog et négocier le périmètre.

Le principe d'adaptabilité dans le PMBOK 7e édition : L'adaptabilité est un principe fondamental du PMBOK 7 qui reconnaît que les projets opèrent dans des environnements complexes et changeants. Ce principe encourage les chefs de projet à évaluer régulièrement les pratiques, les processus et les approches utilisées pour s'assurer qu'ils restent pertinents et efficaces face à l'évolution du contexte du projet, des exigences des parties prenantes et des conditions externes. Contrairement au PMBOK 5e édition qui séparait les approches prédictives et adaptatives, la 7e édition reconnaît que la plupart des projets modernes bénéficient d'une combinaison d'approches. L'adaptabilité n'est pas un changement constant et impulsif, mais une révision réfléchie et régulière des stratégies de gestion. Elle s'applique à TOUS les types de projets, qu'ils soient traditionnels, agiles ou hybrides. Les autres réponses proposées sont incorrectes car : maintenir un plan initial rigide contredit directement ce principe ; limiter l'adaptabilité aux seuls projets Agile ignore que tous les projets modernes doivent s'adapter ; changer d'approche à chaque sprint sans justification va à l'encontre de la nature réfléchie

Livraison de valeur comme paradigme central du PMBOK 7ème édition : Le PMBOK 7 marque un tournant majeur en plaçant la création et la livraison de valeur au cœur de la gestion de projet, dépassant l'approche traditionnelle basée sur le respect rigide du triangle fer (délai, coût, qualité). La valeur ne se limite pas aux livrables tangibles, mais englobe les bénéfices tangibles et intangibles apportés aux parties prenantes. Cette affirmation est exacte car elle reflète le changement de paradigme : un projet peut respecter parfaitement son plan initial (budget, calendrier, spécifications) sans pour autant créer la valeur attendue pour le client ou l'organisation. À l'inverse, une déviation stratégique du plan peut générer une valeur supérieure si elle répond mieux aux besoins réels du client. Cette approche s'applique à tous les types de projets, indépendamment de la méthodologie (Waterfall, Agile ou hybride). Contrairement à l'option 2, la conformité au plan n'est qu'un moyen, non une fin. Contrairement à l'option 3, la valeur évolue tout au long du projet via les retours des parties prenantes. Contrairement à l'option 4, ce principe s'applique universellement, pas seulement en

Vrai. Le domaine Mesure et l’orientation valeur promeuvent des décisions éclairées par des données, des indicateurs et des retours factuels.

Matrice de traçabilité des exigences : document qui crée un lien bidirectionnel entre chaque exigence, sa source, priorité, statut et les livrables correspondants (WBS, tests). Elle assure que toute exigence est couverte et testée. Contrairement au plan de communication (canaux) ou au registre des risques (menaces), elle lie directement les exigences aux éléments de projet.

Rôle du Product Owner : Le Product Owner est responsable de la vision produit et maximise la valeur métier en gérant le backlog produit, en définissant les priorités et en clarifiant les exigences. Contrairement au Scrum Master (facilitateur des cérémonies), il n'assigne pas les tâches : c'est l'équipe auto-organisée qui s'engage. Il ne valide pas les estimations, mais collabore avec l'équipe pour affiner les user stories.

L’approche valeur-contraintes privilégie la re-priorisation basée sur la valeur (scope thinning), en préservant les éléments à plus forte valeur.

Analyse des écarts de performance : EV (100k) < PV (110k) indique un retard d'exécution. EV (100k) < AC (120k) révèle un dépassement budgétaire. Le projet consomme plus de ressources (120k) que la valeur produite (100k), confirmant une double dégradation par rapport au plan initial.

Analyse de la valeur acquise (EVM) : technique de contrôle qui mesure la performance en comparant le travail réalisé (valeur acquise) au coût réel et au planning prévu. Elle fournit des indicateurs (EV, PV, AC) permettant d'évaluer simultanément les écarts de coûts et délais. Contrairement au Gantt (suivi visuel), à la RACI (allocation) ou à l'analyse SWOT (risques), seule l'EVM quantifie précisément la performance globale du projet.

Gérance responsable et transparence : La gérance responsable (stewardship) selon le PMBOK 7e édition représente l'obligation éthique du chef de projet d'agir dans l'intérêt de l'organisation, des parties prenantes et de l'équipe, tandis que la transparence exige de partager ouvertement les informations pertinentes. En dissimulant des problèmes sous prétexte de protéger l'équipe du stress, le chef de projet viole ces deux principes fondamentaux : il prive l'équipe des informations nécessaires pour s'adapter et contribuer aux solutions, il érode la confiance, et il assume seul des responsabilités qui devraient être partagées. La transparence crée un environnement psychologiquement sûr où les problèmes peuvent être abordés collectivement, ce qui renforce réellement la résilience plutôt que de la compromettre. Cette approche diffère de la résilience (capacité à rebondir face aux défis), de la pensée système (vision holistique des interdépendances), et de la qualité (conformité aux exigences), car elle s'ancre directement dans l'éthique et la responsabilité du leadership de projet.

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-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.4.3 (K2) – Expliquer le test basé
sur des checklists.
● a) Faux → Une checklist ne garantit pas une couverture exhaustive.
● b) Correct → Les checklists servent à structurer le travail et éviter d’oublier des
éléments essentiels.
● c) Faux → Elles ne remplacent pas les tests exploratoires, mais peuvent être
complémentaires.
● d) Faux → Elles ne permettent pas d’automatiser entièrement le test

Cette question correspond à l’objectif d’apprentissage FL-1.5.2 (K1) – Rappeler les avantages de l’approche équipe intégrée.
● a) Faux → Une équipe intégrée favorise la collaboration, et non l’indépendance totale des testeurs.

● b) Correct → L’approche équipe intégrée facilite les échanges entre développeurs, testeurs et autres parties prenantes, améliorant ainsi la qualité du produit final.
● c) Faux → Même dans une équipe intégrée, la planification des tests reste essentielle pour garantir une couverture adéquate.
● d) Faux → Les tests de régression restent nécessaires pour s’assurer que les corrections n’ont pas introduit d’autres défauts.

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-3.2.3 (K1) – Rappeler quelles sont les responsabilités attribuées aux rôles principaux lors des revues.
● a) Faux → Le modérateur organise la revue, mais ne corrige pas les défauts.
● b) Correct → L’auteur est la personne qui a produit l’artefact analysé et qui doit corriger les défauts détectés.
● c) Faux → Le lecteur examine les documents, mais n’effectue pas de corrections.
● d) Faux → Le responsable qualité veille au respect du processus, mais n’intervient pas directement dans la correction des défauts.

Cette question correspond à l’objectif d\'apprentissage FL-2.1.1 (K2) – Expliquer l\'impact du cycle de vie du développement logiciel choisi sur le test.

● a) Correct → Dans le modèle en V, les tests sont planifiés dès le début, mais ils ne sont exécutés qu’après la phase de développement.
● b) Faux → En Agile, les tests sont intégrés tout au long des sprints et ne sont pas uniquement réalisés en fin de projet.
● c) Faux → Dans un modèle en cascade, les tests sont généralement exécutés après la phase de développement, pas à tout moment.
● d) Faux → Le cycle de vie influence fortement la manière dont les tests sont planifiés, exécutés et intégrés au projet.

Cette question correspond à l’objectif d’apprentissage FL-1.4.3 (K2) – Différencier les composants du testware qui soutiennent les activités de test.
La bonne réponse est a) 1B, 2B, 3C, 4D

● 1A (Faux) → Le cahier des charges appartient à la documentation des exigences, car il définit les attentes des utilisateurs.
● 2B (Correct) → Les spécifications détaillées sont une partie de la documentation
des exigences, car elles précisent les aspects fonctionnels et non fonctionnels.
● 3C (Correct) → Le plan de test appartient à la documentation de test, car il définit la stratégie et l’organisation des tests.
● 4D (Correct) → Le rapport de test fait partie de la documentation des résultats, car il synthétise les observations et les anomalies détectées.

Cette question correspond à l\'objectif d\'apprentissage FL-2.1.4 (K2) - Résumer la façon dont DevOps pourrait avoir un impact sur le test.
● a) Faux → Dans DevOps, les tests deviennent plus critiques, pas moins importants, car les déploiements fréquents augmentent le besoin de détection rapide des
problèmes.
● b) Faux → DevOps encourage la collaboration et le partage des responsabilités, mais n\'élimine pas le besoin d\'expertise en test. Les compétences spécialisées en test restent valorisées.
● c) Faux → DevOps ne préconise pas de tester principalement en production. Au contraire, il encourage le test approfondi avant le déploiement, mais dans des
environnements qui reflètent fidèlement la production.
● d) Correct → Cette réponse décrit correctement l\'impact principal de DevOps : l\'automatisation des tests et l\'intégration continue permettent un feedback plus rapide et facilitent les déploiements fréquents et fiables.

Cette question correspond à l\'objectif d\'apprentissage FL-4.4.2 (K2) - Expliquer le test exploratoire.

● a) Faux → Les tests basés sur des listes de contrôle nécessitent généralement que les exigences soient connues à l\'avance pour créer les listes appropriées.
● b) Faux → L\'estimation d\'erreur est utile pour anticiper les défauts basés sur l\'expérience, mais n\'est pas la meilleure approche dans cette situation où une couverture systématique est nécessaire rapidement.
● c) Correct → Les tests exploratoires sont idéaux quand le temps est limité et que les exigences ne sont pas complètement disponibles. Cette technique s\'appuie sur
les connaissances du domaine et les compétences analytiques du testeur pour explorer le système de manière structurée mais flexible.
● d) Faux → Les tests de branche sont une technique de test de structure \"boîte blanche\" qui nécessite l\'accès au code source, ce qui n\'est pas mentionné dans le scénario et ne résout pas le problème du manque d\'exigences.

Cette question correspond à l’objectif d’apprentissage FL-3.1.2 (K2) - Expliquer la valeur du test statique.
● a) Correct → Les tests statiques permettent d’identifier des défauts sans exécuter le logiciel, via des revues ou des analyses statiques.
● b) Faux → Tester le logiciel en l’exécutant relève des tests dynamiques.
● c) Faux → Tester la performance du logiciel sous charge relève des tests de performance, qui sont des tests dynamiques.
● d) Faux → Les tests statiques ne concernent pas l’implémentation des tests automatisés.

Réponse : Un attaquant tente de forcer par brute force le compte de jsmith.
Explication : De multiples tentatives de connexion échouées contre le même compte, provenant d'une ou plusieurs adresses IP, sont caractéristiques d'une attaque par force brute. Les journaux afficheraient des échecs d'authentification répétés pour jsmith sur une courte période.

Réponse : Sanitisation.
Explication : La sanitisation des données consiste à effacer de manière sécurisée les disques afin d'empêcher toute récupération des données. Les méthodes incluent l'écrasement des données, la démagnétisation ou la destruction physique. Les politiques de sanitisation garantissent que les données sensibles ne peuvent pas être récupérées depuis du matériel mis hors service.

L'évaluation des vulnérabilités identifie et catégorise les failles de sécurité dans les systèmes (correctifs manquants, mauvaises configurations, mots de passe faibles). L'évaluation des risques va plus loin — elle évalue la probabilité et l'impact d'une menace exploitant chaque vulnérabilité, produisant un score de risque (Risque = Probabilité × Impact). Toutes les vulnérabilités ne représentent pas un risque égal : une vulnérabilité critique dans un système isolé du réseau présente moins de risque qu'une vulnérabilité moyenne sur un serveur exposé à Internet. L'évaluation des risques guide la priorisation et l'allocation des ressources pour la remédiation.

Contrôle compensatoire : mesure de sécurité alternative mise en œuvre lorsqu'un contrôle principal est indisponible ou inefficace. Les caméras de sécurité remplacent les agents de surveillance physique en assurant une fonction de surveillance et de dissuasion. Contrairement aux contrôles préventifs (pare-feu, chiffrement) ou aux contrôles détectifs (antivirus), les contrôles compensatoires comblent les lacunes des mesures de sécurité principales.

La formation à la sensibilisation à la sécurité réduit le facteur humain du risque — le vecteur d'attaque le plus courant. Les simulations de phishing envoient de faux e-mails de phishing réalistes aux employés ; ceux qui cliquent sont redirigés vers une formation. Cela développe des réflexes pour reconnaître le phishing. Les sessions de sensibilisation à l'ingénierie sociale apprennent aux employés à reconnaître le prétexting, le tailgating et le vishing. La gestion des correctifs est un contrôle technique. La configuration des pare-feux est un contrôle technique. La formation cible les comportements et la sensibilisation, et non les systèmes techniques.

SFTP (SSH File Transfer Protocol) est le seul protocole parmi les options qui fournit à la fois l'authentification et le chiffrement pour les transferts de fichiers sécurisés, en utilisant SSH comme couche de transport.

FTP transmet les identifiants en clair sans chiffrement, TFTP n'offre ni authentification ni chiffrement, et HTTP est destiné au web et n'est pas conçu pour les transferts de fichiers sécurisés (bien qu'HTTPS soit chiffré).

La conformité réglementaire dans le secteur bancaire : les institutions financières opèrent dans des cadres réglementaires stricts (Bâle III, Dodd-Frank, RGPD) imposant des audits de sécurité réguliers pour protéger les données des clients et la stabilité systémique. Les régulateurs font respecter ces exigences par la loi, et non par des politiques internes. Bien que les politiques internes, les demandes des clients et les SLA soient importants, ils ne disposent pas du pouvoir d'application légale qui impose des calendriers d'audit obligatoires.

Réponse : Créer une demande de contrôle des changements.
Explication : Les modifications apportées aux systèmes de production — même les correctifs urgents — doivent suivre le processus de gestion des changements. La création d'une demande de contrôle des changements garantit une approbation, une documentation, une planification du retour arrière et une communication appropriées avant l'application du correctif.

Le password spraying (pulvérisation de mots de passe) : une attaque utilisant des mots de passe courants sur plusieurs comptes à partir d'une seule adresse IP source. Contrairement aux attaques par force brute qui ciblent intensivement un seul compte, le password spraying distribue les tentatives sur de nombreux comptes afin d'éviter la détection et les verrouillages. Le pass-the-hash et la falsification de certificats impliquent une réutilisation d'identifiants, et non un test de mots de passe.

Protection des données en transit : Le chiffrement transforme les données sensibles en texte chiffré illisible lors de leur transmission, empêchant ainsi leur interception par des parties non autorisées. Bien que les mots de passe protègent l'accès et que les pare-feux bloquent les connexions non autorisées, seul le chiffrement sécurise les données en cas d'interception. Les antivirus traitent les logiciels malveillants, et non la confidentialité des données lors de leur transmission.

Limites transactionnelles de Cosmos DB : Cosmos DB excelle dans les charges NoSQL distribuées, mais ne supporte pas les transactions ACID multi-documents complexes ni les jointures élaborées entre entités. Les systèmes financiers exigent une cohérence stricte et des opérations multi-tables que les bases relationnelles (SQL Server, PostgreSQL) garantissent mieux. Les trois autres scénarios (web mondial, documents JSON, IoT temps réel) correspondent exactement aux forces de Cosmos DB : scalabilité horizontale, flexibilité schéma et performance distribuée.

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.

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.

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.

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.

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 Data Lake Storage : solution de stockage massif et hautement scalable conçue pour les données brutes non structurées. Contrairement à Azure SQL Database (structuré) ou Azure Queue Storage (messages), ADLS supporte l'analyse Big Data avec Synapse Analytics et Databricks via un système de fichiers hiérarchique (HNS) optimisé pour les charges analytiques complexes.

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

Réponse : Azure SQL Database. Explication : Azure SQL Database est une base de données relationnelle entièrement gérée en tant que PaaS qui minimise la maintenance continue. Microsoft gère les mises à jour du système d'exploitation, les mises à jour de SQL Server, les sauvegardes et la haute disponibilité. C'est le choix recommandé pour les nouvelles charges de travail de bases de données relationnelles dans Azure.

La clé de partition est l'attribut utilisé par Cosmos DB pour distribuer les données sur plusieurs partitions physiques. Un bon choix est critique car : (1) il doit assurer une distribution uniforme des données et des requêtes pour éviter les partitions chaudes (hot partitions), (2) les requêtes sans la clé de partition sont des cross-partition queries — plus lentes et coûteuses. Idéalement, la clé de partition est souvent utilisée dans les filtres WHERE. Exemple : CustomerID pour une app e-commerce (millions de clients répartis uniformément).

Réponse : Le nombre de périodes et de périodes spéciales
La Fiscal Year Variant détermine le nombre de périodes comptables (généralement 12) et le nombre de périodes spéciales (jusqu'à 4) utilisées pour les ajustements de clôture. Elle définit aussi si l'exercice est calé sur l'année civile ou décalé.

Réponse : La Financial Statement Version (FSV).
Explication : La FSV agrège les comptes GL et calcule les sous‑totaux pour la publication des états.

Réponse : F.14
Explication : FBD1 crée les documents récurrents ; F.14 exécute leur comptabilisation périodique.

Réponse : Tolérances + reason codes + comptes d'écart configurés
La gestion des écarts de paiement AR nécessite : (1) la configuration des groupes de tolérance, (2) l'affectation de reason codes aux écarts (ex. escompte non déduit, litige), et (3) la définition des comptes G/L cibles pour comptabiliser automatiquement les différences. Transaction : OBA3, OB57.

Ordre correct clôture mensuelle FI :

1. OB52 : ouvrir la nouvelle période / fermer l'ancienne
2. Accruals/deferrals : écritures de régularisation
3. Valorisation de change : réévaluation des postes en devises
4. Nettoyage GR/IR (MR11) et lettrage OI (F.13)
5. Revue des comptes et publication des états

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 : Vrai
Explication : Le report est réexécutable pour refléter d’éventuels ajustements tardifs avant l’ouverture définitive de l’exercice suivant.

Réponse : ABUMN
La transaction ABUMN (Transfer within Company Code) permet d'effectuer un transfert d'immobilisation au sein d'un même code société, par exemple pour changer de classe d'immobilisation, de numéro d'actif ou d'objet de coût imputé.

Réponse : Type et code de retenue à la source.
Explication : Paramétrés par société et BP, ils déterminent le calcul et le timing (à la facture ou au paiement).

Réponse : FAGLGVTR
Le programme FAGLGVTR (Balance Carryforward for New GL) effectue le report de soldes GL à la fin d'un exercice fiscal. Il transfère les soldes des comptes de bilan vers l'exercice suivant et solde les comptes de résultat vers le compte de report à nouveau.

Réponse : Déterminer qui est le consommateur du service dans chaque situation.
Explication : Lors de l\'application du principe \'Privilégier la valeur\', la première étape est d\'identifier qui est le consommateur, car la valeur est toujours définie du point de vue du consommateur du service.

Réponse : Commencer là où vous êtes.
Explication : Le principe \'Commencer là où vous êtes\' recommande d\'évaluer l\'existant avant de décider ce qui peut être réutilisé, plutôt que de repartir de zéro sans connaître ce qui fonctionne déjà.

Réponse : Un changement préautorisé qui est bien compris et intégralement documenté.
Explication : Un changement standard est préautorisé, bien compris et intégralement documenté. Son faible risque lui permet d\'être implémenté sans passer par le processus d\'approbation habituel.

Réponse : Une autorité de changement doit être assignée pour chaque type et chaque modèle de changement.
Explication : Chaque type et modèle de changement doit avoir une autorité de changement désignée, garantissant une gouvernance claire et des décisions prises par les personnes appropriées selon le risque et l\'impact.

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 : La gestion des mises en production.
Explication : La gestion des mises en production a pour but de mettre à disposition des services et fonctionnalités nouveaux ou modifiés, en coordonnant le packaging et le déploiement des releases.

Réponse : Les coûts supprimés par le service et les coûts imposés par le service.
Explication : Le consommateur d\'un service doit évaluer les coûts supprimés (ce qu\'il n\'a plus à gérer) et les coûts imposés (ce qu\'il doit payer), pour déterminer si la valeur nette est positive.

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 : L\'amélioration continue.
Explication : L\'amélioration continue est la responsabilité de chacun dans l\'organisation, pas seulement d\'une équipe dédiée. Chaque employé doit contribuer à l\'identification et à la mise en oeuvre des améliorations.

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.

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

• Une attaque Golden Ticket consiste à forger des Ticket Granting Tickets (TGT) pour obtenir un accès illimité aux services Active Directory.

• Defender for Identity déclenche une alerte spécifique Golden Ticket attack detection lorsqu’il détecte ce type de manipulation du compte KRBTGT.

• Les autres alertes :

  • Pass-the-Ticket detection : utilisation frauduleuse d’un ticket existant, pas sa création.

  • DCSync attack detection : vol des informations d’Active Directory via des requêtes LDAP sur le contrôleur de domaine.

  • Lateral movement path mapping : cartographie des déplacements latéraux dans le réseau, pas la création de tickets.

• e contrôle Require multi-factor authentication (MFA) oblige l’utilisateur à :

  • Fournir son mot de passe

  • Puis valider un second facteur (code SMS, application Authenticator, notification push, etc.)

Cela correspond exactement à une vérification en deux étapes avant d’accéder aux services Microsoft 365.

🎯 À retenir pour l’examen MS-900 :

• MFA = authentification en deux étapes

• Conditional Access peut combiner plusieurs contrôles (MFA + conformité appareil), mais pour la double vérification, la réponse est toujours Require multi-factor authentication.

• Windows 365 Cloud PC fournit des PC persistants dans le cloud :

  • Chaque utilisateur obtient son propre environnement desktop

  • Les applications et paramètres sont conservés entre les sessions

  • Toujours disponible et indépendant des autres utilisateurs

• Les autres options ne répondent pas exactement au besoin :

  • A : Pooled session hosts partagent les sessions, donc l’environnement n’est pas persistant.

  • C : Single-session desktop dans AVD peut être persistant, mais nécessite plus de gestion et de configuration.

  • D : Azure App Service Web App héberge des applications web, pas un desktop complet persistant.

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

• Dans Microsoft Teams, une app setup policy (politique de configuration d’applications) permet :

  • De définir quelles applications apparaissent par défaut dans la barre d’applications Teams de chaque utilisateur.

  • D’ajouter, supprimer ou réorganiser les applications pour tous les utilisateurs ciblés.

• En configurant cette politique pour tous les utilisateurs, Forms sera automatiquement visible dans la barre d’applications, sans action supplémentaire de leur part.
  
  

  🎯 À retenir pour l’examen MS-900 :

  • App setup policy = déploiement automatique d’applications dans Teams

  • Catalogue ou Azure AD = visibilité et gestion, mais pas déploiement automatique dans la barre d’applications.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) est un protocole d’authentification des e-mails qui :

• S’appuie sur SPF (Sender Policy Framework) pour vérifier que l’expéditeur est autorisé à envoyer des e-mails pour un domaine donné.

• Utilise DKIM (DomainKeys Identified Mail) pour valider l’intégrité du message grâce à une signature numérique.

• Ajoute une politique (policy) permettant au propriétaire du domaine d’indiquer aux serveurs destinataires quoi faire si l’authentification échoue :

  • Ne rien faire (monitoring)

  • Mettre en quarantaine

  • Rejeter le message

👉 DMARC joue donc un rôle clé dans la lutte contre le phishing, l’usurpation d’identité (spoofing) et la fraude par e-mail.

• Audio Conferencing permet aux participants de rejoindre une réunion Teams via un numéro de téléphone PSTN, même si l’entreprise n’a pas de système téléphonique local.

• Disponible en add-on pour les licences qui n’incluent pas déjà cette fonctionnalité (ex. E1 ou E3).

• Couplé à Teams, cela permet d’organiser des réunions mondiales avec des accès téléphoniques standards.

  🎯 À retenir pour l’examen MS-900 :

  • Audio Conferencing add-on = accès PSTN aux réunions Teams

  • Teams Phone System = gère les appels entrants/sortants dans Teams

  • Calling Plan = permet d’appeler depuis Teams, mais pas nécessairement rejoindre une réunion

• Azure Virtual Desktop permet de configurer l’autoscaling des session host VMs selon la demande :

  • Réduire les VMs pendant les heures creuses

  • Augmenter automatiquement pendant les périodes de forte utilisation

• Les autres options ne fournissent pas d’autoscaling intégré :

  • B : Windows 365 Cloud PCs fournit des PC persistants, mais l’autoscaling n’est pas automatique.

  • C : Microsoft Endpoint Manager gère la configuration et les mises à jour, pas l’autoscaling.

  • D : Azure Automation peut automatiser des tâches, mais nécessite une configuration manuelle pour l’autoscaling.

Insider Risk Management est une solution avancée de Microsoft Purview permettant de :

• Détecter les risques liés aux utilisateurs internes (fuites de données, comportements à risque, exfiltration d’informations sensibles).

• Utiliser l’intelligence artificielle et des modèles prédéfinis pour analyser les activités suspectes.

• Aider les organisations à répondre aux exigences réglementaires et de conformité.

👉 Ces fonctionnalités avancées font partie des capacités de Microsoft 365 E5 Compliance (ou incluses dans les suites Microsoft 365 E5 complètes).

Les licences comme E3, Business Premium ou F3 ne comprennent pas les fonctionnalités complètes d’Insider Risk Management.

• Microsoft Intune Device Compliance Policies permet de :

  • Appliquer le chiffrement FileVault sur macOS

  • Contrôler l’exécution des applications via des règles de conformité et d’application

  • Reporter la posture de sécurité des endpoints à Microsoft Entra Conditional Access, permettant de bloquer l’accès aux ressources si le poste n’est pas conforme

• Cette solution couvre tous les objectifs de sécurité demandés pour les postes macOS.

• Microsoft Sentinel Playbooks (basés sur Logic Apps) permettent de :

  • Automatiser la réponse aux incidents (SOAR – Security Orchestration, Automation, and Response)

  • Déclencher des workflows de restauration depuis les backups dès qu’un incident est détecté

  • Réagir rapidement et de manière cohérente face à un ransomware

• Cela offre un processus automatique de containment et de récupération, exactement ce que demande le SOC.

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

• 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 indique officiellement que pour un RPO très court sur Blob Storage, il faut utiliser Azure Backup avec des snapshots fréquents (option D)

• Continuous backup est utile mais dans certains contextes / préversions, et n’est pas la configuration par défaut pour répondre aux SLA stricts d’entreprise.

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

• Air-gapped backups : sauvegardes isolées du réseau principal pour empêcher toute attaque ransomware ou accès malveillant

• Recovery Services Vault dans une souscription séparée :

  • Sépare physiquement la gestion des backups de l’environnement de production

  • Permet RBAC strict et contrôle d’accès granulaire

  • Empêche les attaques réseau ou les utilisateurs compromis dans la souscription principale d’atteindre les sauvegardes

• Approche recommandée par Microsoft pour Protection contre ransomware et menaces internes sur les données critiques opérationnelles

• Prompt injection : manipulation du modèle via des entrées malveillantes → peut révéler des données sensibles ou modifier le comportement attendu.

• Data exfiltration : sortie involontaire de données sensibles dans les réponses du modèle.

• Microsoft recommande pour Azure OpenAI :

  • Placer API Management (APIM) devant le service OpenAI

  • Valider toutes les entrées (ex : rejeter caractères, commandes ou prompts suspects)

  • Filtrer et contrôler la sortie pour éviter l’exfiltration de données sensibles

• Cela fournit une barrière de sécurité en amont et en aval du modèle et suit la baseline Zero Trust et Microsoft Security.

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.

• Microsoft Secure Score :

  • Mesure la posture de sécurité de l’organisation en comparant les configurations actuelles avec les recommandations de Microsoft

  • Indique des opportunités d’amélioration, mais ne garantit pas l’absence d’incident ou de violation

  • Permet de suivre la progression dans le temps et prioriser les actions de sécurité

• Il s’agit d’un indicateur de tendance, pas d’une mesure absolue ou d’un score de risque parfait.

Les journaux d'audit d'accès aux données pour Cloud Storage enregistrent toutes les opérations de lecture (GetObject, etc.) avec l'identité du demandeur, l'horodatage et les détails de l'objet accédé. C'est exactement ce qui est requis pour la conformité légale.

La bonne pratique est d'attribuer les rôles à des groupes (pas à des individus) et d'utiliser le rôle roles/accessapproval.approver qui permet d'approuver/refuser les accès du support Google. IAM roleAdmin donne des permissions trop larges.

Créer un nouveau projet séparé est la seule façon de garantir qu'il n'y a aucune route réseau entre les environnements (les projets séparés sont isolés par défaut). Un Shared VPC créerait justement des routes entre projets, violant l'exigence de sécurité.

Activer l'autoscaling avec min=1 et max=1 garantit qu'une seule instance tourne en permanence et qu'elle sera automatiquement recréée si elle tombe en panne. Avec autoscaling Off, la réparation automatique n'est pas activée de la même manière.

Pour modifier la mémoire d'une VM Compute Engine, il faut l'arrêter, augmenter la mémoire à 8 Go (modification personnalisée), puis la redémarrer. Changer le type vers n1-standard-8 serait incorrect : ce type impose 8 vCPU et 30 Go de RAM — bien plus que nécessaire et donc beaucoup plus coûteux.

Cloud IAP (Identity-Aware Proxy) Tunnel permet l'accès SSH sécurisé sans exposer les IPs publiques ni nécessiter de comptes Google. Le partenaire s'authentifie via IAP, qui peut utiliser diverses méthodes d'identité.

Dans GCP, les règles de pare-feu s'appliquent par ordre de priorité (lower = higher priority). Une règle deny-all basse priorité (65534) bloque tout par défaut, et une règle allow haute priorité (1000) ouvre uniquement les ports nécessaires — principe du moindre accès.

Dans Cloud Run, le fractionnement du trafic se fait entre révisions du même service (pas entre services différents). Créer une nouvelle révision et diviser le trafic est la méthode native recommandée pour les déploiements canary sur Cloud Run.

Un node pool GPU avec autoscaling (minimum 1) permet d'avoir des noeuds GPU disponibles quand nécessaire tout en les minimisant quand l'équipe ne travaille pas. Les VMs préemptibles avec GPUs ne conviennent pas pour des jobs non redémarrables.

La combinaison Redémarrage automatique = On (redémarre si crash) + Maintenance hôte = Migrer (live migration pendant maintenance) dans un MIG est la configuration recommandée pour une haute disponibilité maximale pendant les maintenances GCP.

Réponses correctes : Options 2 et 3. La Définition of Done décrit le travail nécessaire pour produire un Increment potentiellement publiable (option 2), et englobe l'ensemble du travail réalisé tel que défini en son sein (option 3). Les options 0 et 1 sont trop restrictives (elles mentionnent des phases de test spécifiques). L'option 4 est incorrecte car la Definition of Done est un engagement de l'équipe, non limité par les compétences actuelles. Le Guide Scrum souligne que « Done » signifie que le produit est prêt à être publié.

Le rôle du Scrum Master est de coacher l'équipe sur les principes Scrum plutôt que de dicter des décisions. L'objectif du Daily Scrum est de permettre à l'équipe de développement de synchroniser son travail et de planifier la journée — et non de rendre compte de l'avancement au Product Owner. En facilitant la compréhension du véritable objectif de cet événement, Steven donne à l'équipe les moyens de s'auto-organiser pour trouver la solution, incarnant ainsi le servant-leadership et la transparence.

Incertain — observer d'abord est la bonne réponse, car un Daily Scrum dépassant 15 minutes révèle des causes profondes (objectifs peu clairs, mauvaise communication, impediments non résolus ou problèmes de périmètre) plutôt qu'un simple problème de taille d'équipe. Diviser l'équipe sans diagnostic préalable risque de fragmenter la collaboration et de passer à côté du vrai problème. Il est nécessaire d'observer et d'accompagner l'équipe avant d'envisager des changements structurels.

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

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.

Correct : Vrai - Le Guide Scrum stipule explicitement que, quelle que soit l'échelle ou la configuration des équipes, tous les artefacts, événements et rôles Scrum doivent être maintenus afin de préserver l'intégrité du cadre de travail. Plusieurs équipes travaillant sur le même Product Backlog constituent toujours Scrum et doivent se conformer au Guide Scrum.

Scrum est fondé sur l'empirisme — la philosophie selon laquelle la connaissance provient de l'expérience et de l'observation réelles. Scrum aborde la complexité grâce à ses trois piliers : la transparence, l'inspection et l'adaptation. Cela contraste avec les processus définis qui supposent une prévisibilité dans des environnements complexes.

Les principaux bénéfices de l'auto-organisation sont une créativité accrue, la responsabilité individuelle et l'engagement (option 4). Les équipes auto-organisées ressentent un sentiment d'appartenance et d'autonomie, ce qui favorise l'innovation et la motivation intrinsèque. Les options 1 à 3 mettent l'accent sur la conformité ou les résultats, qui sont des effets secondaires et non des bénéfices primaires. L'auto-organisation s'appuie fondamentalement sur les valeurs Scrum que sont l'engagement et le focus.

Le Scrum Master doit accompagner l'équipe pour améliorer les outils et l'infrastructure de manière incrémentale, tout en établissant une Definition of Done réaliste pour le moment présent. Interrompre le Sprint (option 1) fait perdre de l'élan ; accepter un travail incomplet (option 2) compromet la qualité. L'équipe travaille dans les contraintes existantes et s'améliore progressivement, en respectant à la fois la transparence et l'amélioration continue.

Les trois piliers de l'empirisme dans Scrum sont la Transparence, l'Inspection et l'Adaptation. Ces piliers permettent une prise de décision fondée sur des données probantes dans des environnements complexes. La planification, la démonstration et la rétrospective sont des événements du Sprint ; le Respect des personnes et le Kaizen proviennent du Lean—et non des piliers fondateurs de Scrum.

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 : La qualité de l\'estimation du développement peut être médiocre. / Utiliser le même pourcentage chaque fois ne tient pas compte du niveau de risque de l\'application à tester. / La maturité de l\'organisation, par exemple la qualité de la base de test, la qualité des tests de développement, la gestion de configuration, la disponibilité des outils de test, influencent également l\'effort requis pour le test..
Explication : Les réponses A, D et E désignent des sources distinctes de variance qu\'un simple pourcentage du développement ne peut pas capturer. A: les estimations de développement peuvent être inexactes, propageant l\'erreur d\'estimation. D: un pourcentage fixe ignore le risque spécifique, la criticité métier et les profils d\'impact des défauts. E: la maturité organisationnelle (qualité de la base de test, tests unitaires du développement, gestion de configuration, outils disponibles) influence directement l\'effort de test.

Réponse : Exécution des tests.
Explication : L\'exécution des tests représente la portion la plus importante et la moins prévisible de la variabilité (taux de découverte de défauts, disponibilité de l\'environnement, productivité humaine, boucles de rework). C\'est donc la partie la plus difficile à estimer.

Réponse : Les préoccupations concernant l\'interface utilisateur augmentent la probabilité d\'un risque dans ce domaine et augmentent la quantité d\'effort de test nécessaire pour l\'interface utilisateur, limitant ainsi l\'effort de test disponible pour d\'autres parties de l\'outil de gestion de test..
Explication : L\'option B est correcte car elle modifie explicitement à la fois la probabilité évaluée et l\'impact basé sur les ressources (couverture de test), ce qui altère l\'exposition au risque produit et force une réévaluation des priorités. Le risque augmente (probabilité × conséquence) avec la réallocation des ressources.

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 : 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 : 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 : Pourcentage de couverture des exigences.
Explication : B est correct car le pourcentage de couverture des exigences quantifie directement l\'adéquation des tests par rapport à l\'objectif déclaré de valider que le système satisfait ses exigences. L\'efficacité du test dans un contexte piloté par les exigences repose sur la mesure objective de la complétude de la couverture des exigences et de la détection des non-conformités.

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

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

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