Ne découvrez pas l'examen
le jour J

Réponse : Des clés d’accès.
Explication : L’utilisation de la CLI nécessite l’authentification par des clés d’accès générées pour chaque utilisateur IAM.

Réponse : Vous remplacez de gros investissements initiaux par de faibles paiements variables.
Explication : Le modèle pay-as-you-go d’AWS supprime l’investissement de départ et facture uniquement à l’utilisation.

Inspector : scanne les instances EC2 et conteneurs pour identifier les vulnérabilités logicielles et les écarts de configuration réseau. Fournit un rapport de sévérité avec recommandations.

Réponse : Automatiser autant que possible. / Éliminer les points uniques de défaillance.
Explication : L’automatisation et l’élimination des SPOF sont des pratiques clés pour la robustesse et l’efficacité de l’architecture cloud.

Réponse : Portée mondiale (Global reach).
Explication : La portée mondiale d’AWS, via ses régions et ses Edge Locations, permet d’améliorer les temps de réponse pour les utilisateurs dispersés géographiquement.

Réponse : Contrôles environnementaux / Contrôles physiques.
Explication : AWS gère l’environnement physique et les contrôles associés, le client n’a pas à s’en soucier.

Réponse : AWS CloudTrail. Explication : AWS CloudTrail enregistre les appels API effectués aux services AWS, fournissant une piste d'audit complète de qui a fait quelle demande, d'où et quand. C'est l'outil principal pour la gouvernance, la conformité et l'audit de sécurité.

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éponse : AWS Direct Connect. Explication : AWS Direct Connect fournit une connexion réseau dédiée et privée entre l'infrastructure locale et AWS, contournant l'internet public. Il offre des performances réseau cohérentes et peut réduire les coûts de bande passante pour les transferts de données à haut volume.

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

Claude 3 + CodeWhisperer : Claude est un LLM hautement capable pour la génération de code structuré et documenté. CodeWhisperer complète avec des suggestions intelligentes en temps réel. Ensemble, ils couvrent la génération et l'amélioration du code source en production.

Traduction automatique neural : Amazon Translate utilise la traduction neuronale massive pour 15+ langues avec contexte préservé. Scalable en temps réel, moins cher et plus rapide que modèles fondations génériques pour ce cas d'usage spécifique.

Bedrock Invocation Logging : service dédié qui capture automatiquement les prompts (inputs) et réponses (outputs) des appels API aux modèles Bedrock pour audit, conformité et amélioration qualité. CloudTrail enregistre seulement les appels API métadonnées, non les contenus détaillés. Audit Manager et EventBridge ne permettent pas ce suivi granulaire des invocations.

SageMaker Feature Store : référentiel centralisé pour stocker, versionner et partager les features (variables d'entraînement). Permet aux équipes de réutiliser les mêmes données préparées, garantissant cohérence entre entraînement et inférence. Data Wrangler prépare les données, Clarify détecte biais, Model Cards documente les modèles — aucun ne gère le versionning et partage de features.

Un modèle de fondation est un large modèle de machine learning pré-entraîné sur des quantités massives de données (texte, images, code, etc.) qui peut être adapté à de nombreuses tâches via fine-tuning ou prompting. Contrairement aux modèles spécialisés entraînés pour une tâche unique, les modèles de fondation sont polyvalents. Claude (Anthropic), Titan (Amazon), Llama (Meta) sont des exemples. Leur taille et leur coût d'entraînement les rendent inaccessibles à la plupart des organisations sans services cloud.

Asynchronous Inference : mode optimal pour payloads volumineux (jusqu'à 1 Go) et inférences longues (~1h). Le client soumet la requête et reçoit une URL S3 pour récupérer le résultat ultérieurement, sans timeout. Real-time suppose des réponses rapides, Serverless a des limites de durée (15 min), Batch Transform convient aux données statiques, pas aux requêtes en temps quasi-réel.

Défense en profondeur contre l'injection de prompts : Les templates sécurisés et délimiteurs explicites créent une barrière structurelle entre instructions système et données utilisateur, empêchant leur fusion malveillante. L'IAM least-privilege limite les dégâts post-injection, mais ne prévient pas l'attaque elle-même. La température affecte la créativité, non la sécurité. L'accès public aux données aggrave les risques.

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

Knowledge Base Bedrock (RAG) : Injecte uniquement les documents pertinents dans le prompt via recherche sémantique, réduisant les tokens utilisés et donc les coûts. Contrairement à inclure tout le corpus (coûteux et lent), au fine-tuning (investissement initial élevé), ou au zéro contexte (perte de précision), RAG optimise le rapport coût-qualité en récupérant dynamiquement l'information nécessaire.

Prompt Engineering : technique de formulation précise des instructions au LLM pour contrôler directement longueur, langue et style de réponse. C'est l'action immédiate et efficace car elle ne requiert aucun changement d'infrastructure. Contrairement à augmenter la température (qui augmente l'aléatoire) ou Top-K (qui élargit les choix de tokens), ajuster le prompt cible spécifiquement vos contraintes. Changer la taille du modèle est coûteux et lent comparé à optimiser les instructions.

Réponse : Développer au moins une fonctionnalité ; créer un Increment de logiciel potentiellement livrable.
Explication : Le premier Sprint doit produire un logiciel réellement fonctionnel — et non de simples documents de planification ou des conceptions d'architecture. Scrum exige un Increment Done dès le tout premier Sprint.

Rôle du Scrum Master dans la facilitation des événements : Le Scrum Master veille activement à ce que les cinq événements Scrum se déroulent dans leurs timeboxes respectives et lève les impediments qui nuisent à leur efficacité. Contrairement à un chef de projet traditionnel, le Scrum Master ne donne pas d'ordres, mais favorise la productivité de l'équipe grâce au servant leadership et au respect du processus.

Leadership au service de l'équipe dans Scrum : Le Scrum Master sert la Scrum Team en supprimant les impediments, en facilitant les processus et en favorisant l'auto-organisation, plutôt qu'en donnant des directives. Contrairement aux chefs de projet qui pilotent le travail, ou aux managers qui évaluent les performances, les leaders au service de l'équipe soutiennent l'autonomie et la croissance de celle-ci tout en veillant au respect des pratiques Scrum.

Réponse : Présentations de l'équipe ; compréhension de la Definition of Done ; le Product Owner présente le contexte du produit.
Explication : Une nouvelle équipe a besoin de tisser des liens (présentations), de comprendre les exigences de qualité (Definition of Done), et d'obtenir du Product Owner le contexte relatif aux objectifs et à l'historique du produit, afin d'aborder le premier Sprint dans les meilleures conditions.

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.

Le Scrum Master comme bouclier : Le Scrum Master supprime activement les obstacles et protège les Développeurs des interruptions externes, leur permettant de maintenir leur concentration et leur flux de travail durant le Sprint. Ce rôle protecteur est essentiel pour assurer un rythme soutenable et l'atteinte du Sprint Goal, distinguant ainsi le servant-leadership d'une simple facilitation passive.

Réponse : Le travail restant en fonction du temps.
Explication : Les graphiques Burndown suivent la quantité de travail restant (sur l'axe Y) au fil du temps (axe X). Ils permettent de visualiser si l'équipe est en bonne voie pour compléter le Sprint Backlog ou le Product Backlog avant la date cible.

Réponse : Jamais. Tous les éléments du Sprint Backlog appartiennent à l'ensemble de l'équipe Scrum.
Explication : Les éléments du Sprint Backlog ne sont pas la propriété individuelle de qui que ce soit. La Development Team possède collectivement le Sprint Backlog et collabore en tant qu'unité auto-organisée pour réaliser le travail.

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

Concept clé : Le Scrum Master en tant que Facilitateur et Suppresseur d'obstacles. Le Scrum Master est responsable de la facilitation de tous les événements Scrum (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) et du service rendu à la Scrum Team en supprimant les obstacles organisationnels et techniques qui bloquent la progression. Tandis que le Product Owner priorise le Backlog et que l'équipe exécute le travail, seul le Scrum Master détient la responsabilité explicite de la facilitation et de la suppression des obstacles. Les chefs de projet et les architectes ont des rôles différents en dehors du cadre Scrum et ne disposent pas de cette responsabilité.

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.

Réponse : Maximiser la valeur du produit grâce à une gestion efficace du Product Backlog.
Explication : Le Product Owner est responsable de la maximisation de la valeur du produit résultant du travail de la Scrum Team, ainsi que de la gestion efficace du Product Backlog.

Réponse : Taux d'adoption, rétention, résultats métier.
Explication : La valeur se mesure à travers des indicateurs d'utilisation, des résultats et des impacts (par exemple, le cadre EBM) — et non à travers la vélocité ou le nombre d'heures passées.

Composition et objectif du Daily Scrum : Le Daily Scrum est un événement timboxé de 15 minutes conçu spécifiquement pour permettre aux Developers de synchroniser leur travail et d'élaborer un plan pour les 24 heures suivantes. Bien que le Product Owner puisse optionnellement y assister pour écouter et apporter des clarifications sur les éléments du Backlog, sa présence n'est pas obligatoire. Le Daily Scrum est axé sur la coordination interne de l'équipe et la levée des impediments — des responsabilités fondamentales des Developers. L'implication principale du Product Owner se fait lors des événements de Refinement et de Review, où la priorisation du Backlog et la livraison de valeur sont abordées. Confondre cette exigence traduit une incompréhension des frontières des rôles Scrum et de la distinction entre les participants aux événements et les observateurs optionnels.

Réponse : Suffisamment pour que le PO soit confiant que l'Increment atteindra la valeur attendue.
Explication : Scrum ne prescrit pas de pourcentage fixe de temps pour le PO. Celui-ci doit investir suffisamment de temps pour maintenir le Product Backlog prêt, répondre aux questions durant les Sprints et s'assurer que l'équipe comprend ce qui constitue de la valeur.

L'ordonnancement du Product Backlog est la seule responsabilité du Product Owner. Bien que les Developers puissent fournir des informations sur les dépendances techniques et que le Scrum Master puisse accompagner l'équipe sur les valeurs Scrum, la décision finale d'ordonnancement appartient exclusivement au Product Owner. Les parties prenantes peuvent influencer les priorités lors de la Sprint Review ou lors de conversations directes, mais elles ne peuvent pas outrepasser l'ordonnancement du PO. Cette responsabilité unique évite que des priorités conflictuelles ne bloquent l'équipe.

Réponse : La Scrum Team est composée de personnes qualifiées qui possèdent collectivement toutes les compétences nécessaires pour créer de la valeur à chaque Sprint.
Explication : Pluridisciplinaire signifie que l'équipe dans son ensemble (et non chaque individu) dispose de toutes les compétences requises. Aucun spécialiste externe ni aucune autre équipe ne devrait être nécessaire pour livrer un Increment complet.

Concept clé : Les indicateurs de valeur mesurent l'impact réel sur le client et les résultats métier, et non les activités internes ou les métriques intermédiaires. Le nombre d'heures enregistrées est un mauvais indicateur car il mesure l'effort fourni, et non la valeur livrée. Une équipe peut enregistrer de nombreuses heures tout en produisant des fonctionnalités à faible impact ou du gaspillage. De même, la vélocité (points de story complétés par Sprint) mesure la capacité de production, et non la valeur client — les équipes peuvent maintenir une vélocité élevée tout en développant des fonctionnalités dont personne n'a besoin. En revanche, le taux d'adoption reflète l'engagement réel des clients avec le produit, et le chiffre d'affaires récurrent démontre directement la valeur monétisée. En tant que Product Owner, vous devez vous concentrer sur les métriques de résultats (impact client, résultats métier) plutôt que sur les métriques d'activité ou de production (heures, vélocité) lors de l'évaluation de la véritable livraison de valeur et des décisions de priorisation du Backlog.

Participation au Sprint Planning : Le Sprint Planning est un événement Scrum au cours duquel toute la Scrum Team collabore pour définir le Sprint Goal et sélectionner les éléments du Product Backlog pour le Sprint à venir. Le Product Owner présente les priorités et clarifie les exigences, les Developers estiment l'effort et s'engagent sur les livrables, et le Scrum Master facilite l'événement et lève les obstacles. Cette participation collective garantit une compréhension partagée, des engagements réalistes et un alignement sur la livraison de valeur. L'exclusion des managers préserve l'autonomie de l'équipe, tandis que l'exclusion des parties prenantes maintient le pouvoir de décision focalisé de la Scrum Team durant la planification.

Plan de gestion des risques : Le seul livrable officiel du processus de planification de la gestion des risques (Plan Risk Management) selon le PMBOK 7e édition. Ce document définit comment les risques seront identifiés, analysés, répondus et surveillés tout au long du projet. Il établit les politiques, procédures, outils et responsabilités pour la gestion des risques, incluant les seuils de tolérance, les catégories de risques, et les rôles assignés. Contrairement aux autres options : la matrice probabilité/impact est un OUTIL d'analyse créé lors du processus d'analyse qualitative des risques (étape ultérieure), les stratégies de réponse aux risques sont des éléments du plan de réponse aux risques (un livrable différent généré plus tard), et le business case appartient à la phase d'initiation du projet. Le plan de gestion des risques est donc le seul résultat tangible et documenté directement produit par le processus Plan Risk Management, servant de fondation à tous les processus de gestion des risques qui suivront.

Un cycle de vie hybride combine des éléments prédictifs et adaptatifs pour tirer parti de la stabilité et de la flexibilité selon le contexte.

Gestion des parties prenantes opposées : Il faut identifier leurs préoccupations légitimes et les engager stratégiquement plutôt que les ignorer. Un plan de communication ciblé réduit leur influence négative en démontrant la valeur du projet. Contrairement à l'exclusion (contraire à l'éthique PMBOK) ou à l'ignorance (risque d'escalade), cette approche transforme les obstacles en opportunités d'amélioration.

La manière la plus efficace de reconnaître les performances élevées d\'une équipe établie de longue date est d\'adapter la récompense aux objectifs personnels de chaque membre (D). Si une reconnaissance publique (A) ou privée (B) offre une reconnaissance immédiate, elle risque de manquer d\'impact durable. Une simple demande de prime (C), bien que potentiellement appréciée, risque de ne pas répondre aux facteurs de motivation plus profonds.

Une gestion de projet efficace repose sur la motivation des membres de l\'équipe, et la meilleure motivation réside dans la compréhension des besoins et aspirations de chacun. Une récompense personnalisée témoigne de l\'intérêt du chef de projet pour le développement et les objectifs individuels de chaque membre de l\'équipe. Cette approche peut stimuler le moral et renforcer l\'engagement envers le projet et l\'organisation.

Choisir une récompense en adéquation avec les objectifs personnels peut inclure des opportunités de développement de compétences, la participation à une conférence, la direction d\'une nouvelle initiative ou la découverte d\'un domaine d\'intérêt spécifique. Cela démontre que le chef de projet reconnaît et soutient les objectifs de carrière à long terme du membre de l\'équipe. La reconnaissance publique peut faire partie de la récompense, mais ne doit pas être la seule forme de reconnaissance.

De plus, dans un projet de deux ans, supposer que le sponsor puisse facilement accorder une prime revient à ignorer les contraintes et politiques potentielles déjà en place. Une récompense adaptée aux objectifs individuels peut être mise en place sans nécessairement nécessiter de contrepartie financière. Privilégier les opportunités de développement personnalisées produit souvent de meilleurs résultats à long terme qu\'une simple prime financière. Une récompense ciblée renforce les comportements positifs et favorise l\'amélioration continue, ce qui améliore la performance globale de l\'équipe.

Références :

• Institut de gestion de projet (PMI) : https://www.pmi.org/
• « Motivation des équipes de projet » - American Management Association : https://www.amanet.org/ (Rechercher « Motivation des équipes de projet »)

Gouvernance de projet et rôles/responsabilités clairs : Selon le PMBOK 7e édition, la gouvernance de projet constitue le cadre qui guide, supervise et contrôle les initiatives de l'organisation. Un système de gouvernance efficace repose sur des fondations essentielles : des rôles et responsabilités clairement définis pour tous les intervenants (sponsor, chef de projet, équipe, comité de gouvernance). Cette clarté évite les chevauchements, les conflits de pouvoir et les ambiguïtés décisionnelles qui paralysent les projets. Bien que les mécanismes d'escalade et de décision soient importants, ils sont secondaires sans rôles explicites. L'alignement stratégique est crucial mais découle d'une gouvernance bien structurée avec responsabilités claires. La suppression de toute supervision du sponsor est dangereuse et contraire aux bonnes pratiques : le sponsor doit rester impliqué pour valider les décisions majeures et l'alignement. Le reporting uniquement en fin de projet viole le principe de gouvernance continue du PMBOK 7, qui exige une surveillance régulière. Les rôles et responsabilités explicites constituent donc le pilier fondateur sur lequel s'édifient tous les autres éléments d'

Communication optimisée en équipes distribuées : La gestion efficace de la communication dans un contexte distribué repose sur l'établissement de working agreements clairs, fondamentaux selon le PMBOK 7e édition et les pratiques agiles modernes. Cette approche consiste à co-construire avec l'équipe des règles explicites définissant les objectifs de chaque réunion, les durées maximales respectées et surtout la distinction entre les communications synchrones (réunions) et asynchrones (email, wiki, documentation). Le pourquoi de cette stratégie : les réunions synchrones épuisent les équipes distribuées sur différents fuseaux horaires et créent une illusion productive sans décision concrète. En privilégiant les canaux asynchrones pour les échanges non-critiques (partage d'information, mises à jour, documentation), on préserve les réunions synchrones pour ce qui demande vraiment de la collaboration en temps réel (décisions complexes, résolution de blocages, alignement stratégique). Cette approche respecte aussi les principes du Manifeste Agile en valorisant la documentation et la communication directe. Pourquoi les autres options échouent : interdire complètement les réunions crée des malentendus et freine la collaboration réelle ; augmenter la fréquence et la durée aggrave le problème initial ; central

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.

Intégration progressive et structurée des ressources humaines : L'onboarding efficace d'un nouveau membre suit une logique pédagogique et psychologique rigoureuse, alignée avec les principes de gestion des ressources humaines du PMBOK 7e édition. La séquence correcte commence par l'Accueil, qui établit un climat de confiance et d'appartenance essentiels à l'engagement du collaborateur. Vient ensuite la Présentation du contexte, permettant au nouvel arrivant de comprendre les objectifs du projet, sa stratégie, ses enjeux et sa position dans l'organisation. Cette compréhension du "pourquoi" est indispensable avant d'apprendre le "comment". La Formation aux outils intervient alors logiquement, car le nouvel membre dispose désormais du cadre intellectuel pour assimiler les technologies, méthodes et processus spécifiques. Enfin, l'Intégration aux activités concrétise cet apprentissage par une mise en pratique progressive, avec mentoring et suivi. Cette progression respecte la courbe d'apprentissage humaine et minimise la surcharge cognitive. Les autres options échouent car elles inversent cette logique : Former avant de contextualiser crée de la confusion ; commencer par les activités sans préparation

Indices de performance (CPI et SPI) : CPI = 1,2 signifie 20% d'économies de coûts (>1 = en avance), SPI = 0,9 indique 10% de retard calendaire (<1 = en retard). Le projet maîtrise ses dépenses mais accumule des délais, nécessitant une accélération sans surcharge budgétaire.

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-3.2.1 (K1) – Identifier les
avantages d’un feedback précoce et fréquent de la part des parties prenantes.

● a) Faux → L’automatisation des tests est indépendante du moment où le feedback est reçu.
● b) Correct → Obtenir des retours rapides des parties prenantes permet d’identifier plus tôt les erreurs, les imprécisions ou les malentendus liés aux exigences ou aux spécifications → cela réduit le coût de correction.
● c) Faux → Le feedback n’a pas pour but de réduire le besoin d’exploration, mais d’améliorer la compréhension dès le début.
● d) Faux → Le retour d’information ne supprime pas les changements, mais facilite leur gestion en les identifiant plus tôt.

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

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-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-5.1.4 (K3) - Utiliser des techniques d\'estimation pour calculer l\'effort de test requis.

L\'estimation à 3 points utilise la formule : (Optimiste + 4 × Plus probable + Pessimiste) ÷ 6

Donc : (6 + 4 × 15 + 24) ÷ 6 = (6 + 60 + 24) ÷ 6 = 90 ÷ 6 = 15

● a) Correct → 15 jours-personnes est le résultat correct de la formule d\'estimation à trois points.
● b) Faux → 16 jours-personnes n\'est pas le résultat correct.
● c) Faux → 17 jours-personnes n\'est pas le résultat correct.
● d) Faux →18 jours-personnes n\'est pas le résultat correct.

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.

La bonne réponse est c) i, ii, iv ont une influence significative ; iii non.

● i) Correct → DevOps nécessite un équilibre entre tests automatisés et manuels.
● ii) Correct → Les cycles de livraison rapides imposent des tests rapides et efficaces.
● iii) Faux → DevOps ne se limite pas aux tests de non-régression, d’autres types de tests sont nécessaires.
● iv) Correct → Assurer la stabilité de l’environnement de test est crucial en intégration continue.

Cette question correspond à l’objectif d\'apprentissage FL-6.1.1 (K2) – Expliquer comment différents types d\'outils de test soutiennent les tests.

● a) Faux → Les outils d’exécution et de couverture des tests sont conçus pour automatiser et mesurer l’exécution des tests, mais ne gèrent pas l’organisation des cas de test et des défauts.
● b) Faux → Les outils de test de non-régression sont utilisés pour vérifier que les modifications apportées au code n’introduisent pas de nouveaux défauts, mais ils ne gèrent pas directement les cas de test et les défauts.
● c) Correct → Les outils de gestion des tests permettent de structurer, suivre et centraliser les cas de test, les défauts détectés et les configurations de test.
● d) Faux → Les outils d’analyse statique examinent le code source sans exécuter le programme, mais ne permettent pas de suivre la gestion des tests et des défauts.

Cette question correspond à l’objectif d’apprentissage FL-1.2.1 (K2)- Donner des exemples montrant la nécessité des tests.
● a) Faux → Les tests dynamiques détectent des défauts, mais ils ne garantissent pas qu’ils provoquent uniquement des comportements anormaux impossibles à reproduire par les utilisateurs.

● b) Correct → Les tests statiques permettent d’identifier des défauts dans le code source avant même l’exécution, ce qui réduit les coûts de correction.
● c) Faux → L’analyse statique ne garantit pas qu’un composant est prêt pour la production, elle identifie uniquement des erreurs structurelles.
● d) Faux → Les revues améliorent la qualité des spécifications, mais ne remplacent pas les tests

La segmentation réseau : consiste à diviser un réseau en zones distinctes afin de contenir les violations de sécurité. Si un segment est compromis, l'attaque ne peut pas se propager facilement aux autres segments, ce qui limite les déplacements latéraux. Cela se distingue de l'optimisation de la bande passante (B), de l'amélioration du signal (C) ou des méthodes de chiffrement (D), qui constituent des préoccupations réseau distinctes.

Motivation du crime organisé : Les cybercriminels opérant au sein de groupes organisés ciblent les systèmes financiers, le vol de données et les rançongiciels dans un but de gain monétaire direct. Contrairement aux hacktivistes (motivés par l'idéologie), aux menaces internes (basées sur les accès) ou au Shadow IT (contournements opérationnels), le crime organisé poursuit exclusivement le profit à travers des activités cybercriminelles illégales.

Registre des risques : document complet qui répertorie les risques identifiés, attribue la responsabilité aux parties concernées, établit les seuils et niveaux de tolérance au risque, et assure le suivi des stratégies d'atténuation. Contrairement à la tolérance au risque (niveaux de risque acceptables), au transfert de risque (délégation du risque à des tiers) ou à l'analyse des risques (processus d'évaluation), le registre des risques constitue le référentiel central pour documenter et gérer l'ensemble des risques organisationnels tout au long de leur cycle de vie.

Réponse : Contrôle compensatoire.
Explication : Un contrôle compensatoire offre une protection alternative lorsque le contrôle principal ne peut pas être mis en œuvre comme prévu. Un système Linux legacy ne pouvant pas être mis à jour avec des outils de sécurité modernes, une liste d'autorisation par adresse IP est mise en place en tant que contrôle compensatoire pour restreindre les accès.

Les listes de contrôle d'accès (ACLs) : définissent des permissions granulaires directement sur les ressources, en précisant quels utilisateurs ou groupes peuvent accéder à des fichiers spécifiques. Les ACLs permettent une restriction immédiate au niveau du fichier sans nécessiter le déploiement d'une politique à l'échelle du système. Contrairement à la stratégie de groupe (qui requiert un temps de configuration du domaine) ou au RBAC (qui nécessite une restructuration des rôles), les ACLs permettent les modifications de permissions directes les plus rapides. La DLP prévient l'exfiltration de données mais ne restreint pas l'accès en tant que tel.

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.

Facteur humain de dissuasion sécuritaire : Les agents de sécurité assurent une surveillance active en temps réel et une prise de décision que les caméras, les badges d'accès et les lecteurs biométriques ne peuvent pas égaler. Bien que les contrôles technologiques détectent et enregistrent les tentatives d'accès non autorisées, les agents empêchent activement l'entrée grâce au jugement humain, peuvent réagir immédiatement aux menaces et s'adapter aux situations évolutives. Les agents constituent à la fois un élément de dissuasion visible et un mécanisme d'intervention — essentiels pour une sécurité physique complète.

Transfert de Risque : Déléguer la responsabilité financière des pertes potentielles à un tiers par le biais d'assurances ou de contrats. Une cyber-assurance transfère la charge des coûts liés à une violation à un assureur, plutôt que d'accepter, d'éviter ou d'atténuer le risque en interne. Contrairement à la mitigation (réduction de la probabilité ou de l'impact) ou à l'acceptation (conservation du risque), le transfert délègue les conséquences financières à une autre entité.

Évaluation des risques : Un processus systématique d'identification, d'analyse et d'évaluation des menaces potentielles et des vulnérabilités pesant sur les actifs d'une organisation. Cette activité fondamentale permet de prioriser les contrôles de sécurité en déterminant la probabilité et l'impact. Contrairement à la modélisation des menaces (analyse théorique), aux tests de pénétration (validation pratique) ou à la gestion des incidents (gestion réactive), l'évaluation des risques constitue le fondement stratégique de la planification de la sécurité.

Attaque par Force Brute : Une tentative systématique d'obtenir un accès non autorisé en essayant plusieurs combinaisons de mots de passe de manière répétée jusqu'à réussir. De multiples tentatives de connexion échouées enregistrées de manière séquentielle indiquent une tentative automatisée de deviner des identifiants. Cela diffère d'un mot de passe oublié (erreur isolée d'un utilisateur), d'une élévation de privilèges (exploitation post-authentification) ou d'audits échoués (contrôles de conformité), qui laissent tous des signatures distinctes dans les journaux.

Base NoSQL orientée documents : stocke des données semi-structurées (JSON, XML) sans schéma fixe, idéale pour les structures variables comme les profils utilisateurs. Contrairement aux bases relationnelles (rigides avec clés étrangères), elle offre flexibilité. Différente du stockage multimédia (Blob Storage) et des transactions bancaires (bases ACID relationnelles obligatoires).

Azure Stream Analytics est un service de traitement de flux en temps réel (streaming). Il ingère des données en continu depuis des sources comme Azure Event Hubs (millions d'événements/seconde), Azure IoT Hub (appareils connectés) ou Azure Blob Storage. Il applique des requêtes SQL-like sur les données en mouvement pour détecter des anomalies, calculer des agrégations temporelles (fenêtres temporelles : sliding, tumbling, session), et déclencher des alertes. Les résultats sont envoyés vers Power BI, Azure SQL, Cosmos DB ou Event Hubs. Cas d'usage : détection de fraude, monitoring IoT, analyse de logs en temps réel.

Azure Cosmos DB est une base de données NoSQL multi-modèles qui supporte : (1) Document (API SQL/Core et MongoDB) — données JSON semi-structurées, (2) Clé-valeur (API Table) — paires clé/valeur simples, (3) Colonne large (API Cassandra) — familles de colonnes, (4) Graphe (API Gremlin) — nœuds et arêtes pour les relations complexes. Cosmos DB garantit une latence inférieure à 10ms au 99e percentile et une disponibilité de 99,999% avec réplication multi-région.

Clé primaire : colonne ou ensemble de colonnes qui identifie de manière unique chaque enregistrement dans une table. Elle empêche les doublons et les valeurs NULL, garantissant l'intégrité des données. Contrairement à une clé étrangère (qui référence une autre table), à un index (qui accélère les recherches) ou à un trigger (qui exécute des actions), la clé primaire est la seule qui assure l'unicité absolue.

Azure SQL Managed Instance offre la compatibilité la plus élevée avec SQL Server on-premises (surface d'API proche de 100%). Il prend en charge les fonctionnalités avancées comme SQL Agent, le Service Broker, les linked servers, et les CLR assemblies — fonctionnalités souvent indispensables aux applications existantes. Azure SQL Database offre moins de compatibilité mais plus d'élasticité. Azure Database Migration Service (DMS) est l'outil de migration (pas une base de données). Pour les migrations lift-and-shift, SQL MI est la cible recommandée.

Une clé étrangère (Foreign Key) est une contrainte référentielle qui lie une colonne d'une table à la clé primaire d'une autre table. Elle garantit l'intégrité référentielle : on ne peut pas insérer une valeur dans la colonne FK si elle n'existe pas dans la table référencée, ni supprimer une ligne référencée sans gérer les dépendances. Exemple : une table Commandes avec un CustomerID (FK) référençant la table Clients (PK=CustomerID). Sans FK, on pourrait avoir des commandes orphelines sans client associé.

Azure SQL Managed Instance : service PaaS qui émule SQL Server on-premise avec compatibilité quasi-totale (T-SQL, Agent SQL, linked servers). Contrairement à Azure SQL Database qui impose des adaptations de code, Managed Instance accepte les bases existantes sans modification majeure, minimisant les risques et délais de migration. MySQL et Cosmos DB nécessitent une refonte complète de l'architecture.

Données non structurées : données sans schéma fixe ni organisation tabulaire prédéfinie, comme les vidéos, images, fichiers audio et documents texte libres. Contrairement aux données relationnelles (colonnes/lignes) ou aux CSV (format tabulaire), elles ne suivent pas une structure rigide et nécessitent des outils spécialisés pour être analysées et indexées.

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

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

Réponse : Les éléments primaires et secondaires sont des comptes G/L
Dans S/4HANA, la frontière entre FI et CO a été supprimée. Les éléments de coût (primaires et secondaires) sont désormais des comptes G/L dans le plan de comptes. Toutes les écritures CO sont directement reflétées dans ACDOCA, assurant la réconciliation en temps réel.

Réponse : Le segment apparaît dans la configuration d'affectation supplémentaire des comptes ; le segment apparaît dans la disposition d'écran pour la fiche immobilisation. Explication : L'activation de la présentation par segment dans FI-AA ajoute le champ segment à deux zones : la configuration de l'affectation des comptes (pour la dérivation automatique du segment dans les comptabilisations) et la disposition d'écran de la fiche immobilisation (pour l'affectation manuelle ou l'affichage).

Réponse : Stockage en colonnes ; Base de données in‑memory ; Forte compression ; Exécution des calculs côté base (push‑down).
Explication : HANA combine colonnes, compression et parallélisation ; les calculs sont poussés au moteur HANA via CDS/SQLScript pour des performances temps réel.

Réponse : Core Data Services
Explication : Les vues CDS définissent sémantique, associations et annotations (UI/analytique) consommées par Fiori et l’analytique embarquée.

Réponse : Vrai
Explication : Les ledgers parallèles peuvent utiliser des variantes distinctes pour répondre à des normes différentes.

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

Réponse : L’affectation d’un plan de comptes opérationnel au code société.
Explication : Le plan de comptes (chart of accounts) est requis pour créer les segments plan de comptes et étendre les comptes au code société.

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

Réponse : Assignez un ordre interne réel dans les données de base d'immobilisation et réglez périodiquement à deux centres de coûts. Explication : Pour répartir les coûts d'amortissement à plusieurs centres de coûts, utilisez un ordre interne comme collecteur intermédiaire dans les données de base d'immobilisation. L'ordre interne est ensuite réglé périodiquement à l'aide de règles de distribution pour allouer les coûts à chaque centre de coûts.

Concept clé : Test de confidentialité dans l'apprentissage fédéré. L'apprentissage fédéré vise à préserver la confidentialité en maintenant les données d'entraînement décentralisées. Les testeurs doivent valider que les données individuelles ne quittent jamais les appareils locaux et que seules les mises à jour agrégées du modèle sont transmises, prévenant ainsi toute exposition non autorisée des données pendant le processus d'apprentissage.

Réponse : En choisissant quelques méthodes clés pour les types d\'améliorations gérées par l\'organisation.
Explication : Plutôt que d\'adopter toutes les méthodes existantes, une organisation doit sélectionner quelques approches adaptées aux types d\'améliorations qu\'elle gère, pour rester cohérente et efficace.

Réponse : Flux de valeur et processus.
Explication : La dimension \'Flux de valeur et processus\' se concentre sur les activités et leur coordination pour créer de la valeur. Elle définit comment les différentes parties d\'une organisation collaborent pour livrer des services.

Réponse : Offre de service.
Explication : Une offre de service est un ensemble de produits et services proposé à un consommateur. Le package (ordinateur + logiciels + licences + support) constitue une offre de service complète et packagée.

Réponse : Le centre de services.
Explication : Le centre de services est le point d\'entrée unique pour les utilisateurs. Il inclut la classification et la propriété de toutes les questions et demandes, qu\'il redirige vers les équipes appropriées.

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

Réponse : 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 : Habilitation des changements.
Explication : En ITIL 4, l\'habilitation des changements est responsable du déplacement des composants vers les environnements de production, garantissant que les changements sont correctement contrôlés et autorisés avant mise en production.

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 : 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 : Ajouter, modifier ou supprimer tout ce qui pourrait avoir un effet direct ou indirect sur les services.
Explication : En ITIL 4, un changement est l\'ajout, la modification ou la suppression de tout élément pouvant avoir un effet direct ou indirect sur les services, qu\'il soit matériel, logiciel ou organisationnel.

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

👉 Elle permet notamment :

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

• De changer la couleur du texte

• D’ajouter des icônes

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

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

• Monthly Enterprise Channel (canal mensuel pour entreprises) :

  • Fournit les mises à jour de fonctionnalités mensuelles dès qu’elles sont disponibles pour le grand public.

  • Convient aux organisations qui veulent un équilibre entre rapidité et stabilité.

• Ce canal est idéal pour déployer rapidement de nouvelles fonctionnalités aux groupes pilotes ou à certaines machines, sans attendre les canaux plus longs comme le Semi-Annual Channel.

  🎯 À retenir pour l’examen MS-900 :

  • Monthly Enterprise Channel = mises à jour mensuelles officielles pour entreprises, avec déploiement rapide

  • Semi-Annual Channel = déploiement lent, deux fois par an

  • Insider / Default Channel = pas adapté pour un déploiement contrôlé en entreprise

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

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

  • Gérer les prospects et clients

  • Suivre les opportunités commerciales

  • Centraliser les interactions avec les clients

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

  🎯 À retenir pour l’examen MS-900 :

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

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

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

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.

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

• La section Token Usage :

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

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

• Les autres sections ne fournissent pas cette information :

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

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

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

    🎯 À retenir pour l’examen MS-900 :

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

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

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

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

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

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

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

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

• Office 365 Message Encryption (OME) permet de :

  • Chiffrer automatiquement les emails selon des politiques définies

  • Protéger le contenu même si le destinataire n’utilise pas Office 365

• Les autres options ne répondent pas entièrement au besoin :

  • A : S/MIME nécessite que l’expéditeur configure manuellement le certificat et le chiffrement.

  • B : TLS sécurise la transmission, mais ne chiffre pas le contenu de manière persistante.

  • C : IRM contrôle l’utilisation et l’accès aux messages mais ne déclenche pas le chiffrement automatique basé sur des règles.

• Lorsqu’une application PaaS comme Azure App Service présente des problèmes de connectivité intermittents, il est important de vérifier d’abord la connectivité côté client et réseau interne :

  • Problèmes avec le réseau de l’entreprise ou l’ISP peuvent provoquer des interruptions intermittentes.

• Microsoft support intervient si le problème vient de la plateforme Azure elle-même.

• Commencer par le réseau interne permet de localiser rapidement la source avant de contacter Microsoft.

• Le pilier Security du WAF couvre :

  • La protection des données (chiffrement au repos et en transit)

  • La gestion des identités et des accès

  • La rotation et protection des clés

  • La gestion des vulnérabilités et la gouvernance des configurations

• Ici :

  • L’absence de rotation de clés et de chiffrement au repos constitue un manquement direct aux pratiques de sécurité recommandées par Microsoft

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

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

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

• Dans cet exemple :

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

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

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

• Immutable vaults (coffres immuables) dans Azure Backup :

  • Empêchent toute modification ou suppression des points de récupération pendant une période définie

  • Garantissent la récupération fiable après ransomware ou suppression accidentelle

  • Permettent de fournir une preuve de conformité aux audits et metrics MCSB

• Complément :

  • MCSB (Microsoft Cloud Security Benchmark) recommande des backups immuables pour les données critiques, en particulier pour le secteur de la santé

• ISO 27001 exige, entre autres :

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

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

• Azure AD PIM :

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

  • Chaque activation est journalisée et auditable

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

• Fusion detection :

  • Fonctionnalité native de Sentinel pour corréler automatiquement les alertes provenant de différentes sources

  • Regroupe des alertes apparemment indépendantes mais liées à un même incident ou attaquant

  • Réduit le bruit (alert fatigue) et facilite le triage rapide par les analystes SOC

• Avantages :

  • Détecte des attaques avancées persistantes (APT) et chaînes d’attaques multi-sources

  • Crée des incidents uniques regroupant plusieurs alertes, plutôt que d’avoir des centaines d’alertes isolées

• Azure Key Vault :

  • Permet de centraliser tous les certificats TLS/SSL

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

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

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

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

Dans Microsoft Purview Insider Risk Management, la fonctionnalité de gestion des cas avec contrôles de confidentialité intégrés permet :

• De restreindre l’accès aux cas uniquement aux enquêteurs assignés

• D’anonymiser certains utilisateurs pendant l’analyse (selon la configuration)

• De garantir la confidentialité des investigations

• De limiter la visibilité des informations sensibles

Cette fonctionnalité est spécifiquement conçue pour répondre aux exigences de confidentialité et de conformité liées aux enquêtes internes.

👉 Elle va au-delà du simple RBAC général en offrant des mécanismes dédiés aux enquêtes Insider Risk.

• 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

• Objectif d’un tabletop exercise :

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

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

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

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

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

• Cette approche :

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

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

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

La bonne méthode est de créer deux configurations (une par compte/région) puis d'activer la configuration appropriée avant de lancer les commandes. gcloud configurations list affiche seulement les configurations sans les activer.

Data Catalog est le service GCP de découverte et de gestion des métadonnées. Une simple recherche de 'employee_ssn' trouve instantanément toutes les tables contenant cette colonne dans tous les projets, sans écrire de scripts.

Les alertes budgétaires GCP s'appliquent au projet entier, pas à un seul serveur. La seule solution pour cibler les coûts réseau d'un serveur spécifique est d'exporter la facturation vers BigQuery et d'interroger les données avec une Cloud Function planifiée.

Un health check sur le port 443 (HTTPS) permet au MIG de détecter les instances défaillantes et de les recréer automatiquement. C'est la seule option qui configure réellement l'autohealing. Les labels et heartbeats ne font pas de recréation automatique.

La bonne approche est de créer deux configurations gcloud (une par projet/compte), puis un script qui active chaque configuration et exécute gcloud compute instances list. gsutil est pour Cloud Storage, pas pour les instances Compute Engine.

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.

La solution entièrement automatisée est : Cloud Monitoring → webhook → Cloud Function qui ajuste le nombre de noeuds Spanner. Cela réagit automatiquement aux variations de charge dans les deux sens (scale up/down) sans intervention humaine.

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

La protection contre la suppression (deletion protection) empêche toute suppression accidentelle de l'instance, même pour les utilisateurs avec des droits d'administration. Il faut explicitement désactiver cette protection avant de pouvoir supprimer l'instance.

Google Cloud Directory Sync (GCDS) est l'outil officiel Google pour synchroniser automatiquement les utilisateurs et groupes depuis Active Directory (ou LDAP) vers Cloud Identity. Il maintient AD comme source de vérité et synchronise de façon continue.

Correct : Option 2 - L'ajout d'une deuxième équipe entraîne généralement une baisse initiale de la vélocité de l'équipe d'origine, en raison de la surcharge de communication accrue, du changement de contexte et de la complexité de coordination liée à l'intégration avec la nouvelle équipe. La vélocité mesure la capacité de l'équipe, qui est souvent mise à rude épreuve par les effets du passage à l'échelle avant que des améliorations ne se manifestent.

Une ligne de tendance sur un graphique de burndown de release projette la date à laquelle le travail sera terminé en se basant sur le rythme de progression actuel, en supposant que le Product Backlog et la capacité de l'équipe restent constants. L'option 2 est correcte car elle reflète cette projection conditionnelle. L'option 1 est incorrecte — les burndowns ne déclenchent pas la création de nouveaux Product Backlogs. L'option 3 simplifie à l'excès en ignorant la nature conditionnelle de la projection. L'option 4 n'a pas de rapport avec le fonctionnement des burndowns.

Scrum est un framework, non une méthodologie ni un processus défini. Il fournit des rôles, des événements et des artefacts, mais ne prescrit pas un processus unique de développement logiciel. Cela s'aligne avec l'objectif de Scrum : aborder la complexité dans des environnements imprévisibles par l'empirisme, plutôt que par le respect de procédures prédéfinies.

Réponses correctes : Options 2 et 4. L'option 2 explique correctement que les time-boxes permettent à ceux qui sont au plus près des problèmes de prendre les meilleures décisions dans les contraintes imposées — un principe fondamental de l'auto-organisation. L'option 4 montre correctement que les time-boxes alignent la concentration et la compréhension partagée au sein de l'équipe. L'option 1 confond engagement et contrainte, et l'option 3 représente de manière erronée le rôle du time-boxing dans la planification prévisionnelle.

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.

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.

L'option C est correcte. L'implication du Product Owner doit être calibrée en fonction de l'autonomie de l'équipe — une clarté suffisante lors du Sprint Planning permet l'indépendance de l'équipe durant le Sprint. Cet équilibre se mesure à la capacité de l'Increment à répondre aux attentes, et non à la présence physique à chaque événement. L'option A confond l'observation avec l'implication, l'option B est réactive plutôt que préventive, et l'option D constitue une interprétation extrémiste et erronée de Scrum.

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.

Les options B et C sont correctes. Une dette technique imprévue rencontrée en cours de Sprint réduit la vélocité (B), et les équipes peuvent artificiellement gonfler leur vélocité en accumulant de la dette plutôt qu'en complétant pleinement le travail (C). L'option A est incorrecte car elle les sépare artificiellement — la dette technique impacte directement la capacité à développer de nouvelles fonctionnalités. L'option D est fausse : la dette technique consomme tout de même de la capacité et masque les tendances réelles de la vélocité.

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.

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

Réponse : Les critères d\'entrée et de sortie pour chaque phase de test / Les techniques de conception de test à utiliser.
Explication : AC est correct car une stratégie de test défendable prescrit explicitement les techniques de conception de test pour atteindre la couverture et l\'atténuation des risques (C) et les critères d\'entrée/sortie qui gouvernent la progression des phases et les barrières qualité (A). Une stratégie de test robuste est un cadre décisionnel de haut niveau qui détermine comment les objectifs de test seront atteints et comment les risques informent la priorisation et la portée.

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 : 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 : 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 : TMMi ne peut être utilisé qu\'avec le modèle V traditionnel, tandis que TPI peut être utilisé avec tous les types de cycles de vie logiciels..
Explication : D est incorrect car TMMi n\'est pas limité au modèle V ; il est indépendant du cycle de vie et applicable aux modèles V, itératifs et agiles. TPI l\'est aussi, contredisant l\'affirmation d\'une dichotomie entre les deux approches.

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

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

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

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

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