Ne découvrez pas l'examen
le jour J

Réponses : Détecter les ressources sous-utilisées pour économiser les coûts et améliorer la sécurité en surveillant de manière proactive l'environnement AWS. AWS Trusted Advisor fournit des conseils en temps réel dans cinq catégories : optimisation des coûts (détection des ressources inutilisées), sécurité, tolérance aux pannes, performance et limites de service, aidant les équipes à améliorer proactivement leur environnement AWS.

Réponse : Construire des architectures multi-régions / Utiliser des architectures serverless.
Explication : Les architectures multi-régions et serverless contribuent à l’efficacité et à la performance.

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 : Tous les comptes bénéficient de la remise horaire sur les instances réservées.
Explication : Grâce à la facturation consolidée, tous les comptes d’une organisation bénéficient des remises sur les instances réservées achetées.

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.

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 : Amazon RDS.
Explication : Amazon RDS gère les tâches d’administration de base de données : backups, patching, réplication, pour vous laisser vous concentrer sur la structure et l’optimisation.

Réponse : Implémenter l’élasticité.
Explication : L’élasticité permet d’ajuster automatiquement les ressources selon la demande, ce qui réduit les coûts.

Réponse : Éliminer les points de défaillance unique et infrastructure distribuée.
Explication : Le cloud favorise la résilience (SPOF éliminés) et offre une infrastructure distribuée mondialement.

Réponse : Amazon Aurora. Explication : Amazon Aurora est une base de données relationnelle entièrement gérée, compatible avec MySQL et PostgreSQL, conçue pour le cloud. Elle offre jusqu'à 5 fois la performance du MySQL standard avec la simplicité et la rentabilité des bases de données open source.

On-Demand : modèle de tarification à l'usage sans engagement contractuel ni volume minimum. Vous payez uniquement pour les tokens consommés, idéal pour les charges variables. Contrairement à Provisioned Throughput (débit garanti) ou Committed Use Discount (contrats longs), On-Demand offre la flexibilité maximale.

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

Vrai. Une grande fenêtre permet d’inclure davantage de texte (ou de contextes RAG), contrairement à des paramètres comme la température.

Les bases de données vectorielles (ex. : Amazon OpenSearch Service, Aurora pgvector, Pinecone) stockent les embeddings — représentations numériques de textes sous forme de vecteurs. Dans un pipeline RAG, les documents sont d'abord transformés en embeddings puis stockés. Lors d'une requête, la question de l'utilisateur est aussi transformée en embedding, et une recherche de similarité cosinus identifie les documents les plus pertinents à passer au LLM. Elles ne stockent pas les images directement ni les poids du modèle.

SageMaker Clarify : outil spécialisé pour l'explicabilité et l'audit de modèles ML. Il génère des rapports détaillés sur l'interprétabilité des prédictions (SHAP, LIME) et quantifie les biais potentiels par démographie. Contrairement à Inspector (conformité infrastructure), Macie (données sensibles) et Rekognition (détection visuelle), Clarify cible spécifiquement l'évaluation et la transparence algorithmique en santé.

LLM texte-à-texte : modèle entraîné sur corpus massif (texte + code SQL) capable de traduire instructions naturelles en requêtes SQL exécutables via compréhension contextuelle. SVM/ResNet/WaveNet sont spécialisés en classification/vision/audio respectivement, inadaptés au text-to-SQL.

Évaluation humaine contextuelle : Les préférences stylistiques (ton, clarté, pertinence métier) ne peuvent être mesurées par des métriques automatiques. Une équipe humaine avec des prompts personnalisés au contexte métier capture les nuances qualitatives. Les benchmarks publics par défaut manquent de spécificité métier, les leaderboards ne reflètent pas vos besoins réels, et la latence n'évalue pas la qualité du rendu.

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.

Fenêtre de contexte : limite maximale de tokens (mots/sous-mots) qu'un modèle peut traiter en entrée et en sortie combinées. Elle détermine directement la longueur du prompt accepté. Contrairement au batch size (nombre de requêtes parallèles), à la température (créativité) ou à la taille fichier (format), seule la fenêtre de contexte contrôle la capacité textuelle du modèle Bedrock.

Narrativisation de données : Les modèles fondations excèlent à transformer données brutes en proses naturelles, insight business et explications. Bedrock avec prompt structuré (templates, exemples) crée rapports cohérents, scalables et professionnels à bas coût.

Réponse : L'équipe de développement devrait rappeler au Product Owner de trouver un financement pour des Sprints de livraison afin de couvrir le travail restant.
Explication : Lorsque la vélocité est constamment inférieure aux prévisions, l'équipe doit communiquer de manière transparente l'impact sur les plans de livraison. Le Product Owner doit ajuster le plan ou obtenir une capacité supplémentaire, plutôt que de faire pression sur l'équipe pour qu'elle gonfle artificiellement sa vélocité.

Engagements des artefacts : chaque artefact Scrum possède un engagement spécifique garantissant la transparence et la responsabilité. L'engagement du Product Backlog est le Product Goal — un objectif à long terme guidant le refinement du Backlog et la planification des Sprints. Cela diffère du Sprint Goal (engagement du Sprint Backlog) et de la Definition of Done (engagement de l'Incrément), chacun servant des objectifs distincts au sein du framework Scrum.

Réponse : Tous les membres de la Dev Team sont responsables de la qualité ; Scrum ne prévoit pas de rôle de testeur.
Explication : Scrum définit uniquement trois rôles et aucune spécialisation au sein de la Development Team. La qualité est une responsabilité partagée — chaque membre de l'équipe contribue aux tests, quelle que soit sa compétence principale.

Les engagements des artefacts dans Scrum : Chaque artefact Scrum est associé à un engagement spécifique garantissant la transparence. La Definition of Done engage l'Incrément en définissant les standards de qualité et les critères d'achèvement. Cela empêche qu'un travail incomplet soit présenté comme terminé, ce qui la distingue du Sprint Goal (engagement lié aux éléments du Product Backlog) et du Product Goal (engagement lié au Product Backlog).

Flexibilité de l'estimation : Le Guide Scrum évite délibérément de prescrire des techniques d'estimation spécifiques, laissant aux équipes l'autonomie de choisir des méthodes telles que les Story Points, les heures ou les tailles de t-shirt. Cela reflète le principe d'empirisme de Scrum et l'auto-organisation de l'équipe, plutôt que l'imposition de cadres rigides.

Autorité du Product Owner : Seul le Product Owner détient l'autorité d'annuler un Sprint, car il contrôle les priorités en matière de valeur métier et peut décider si les objectifs du Sprint ne sont plus alignés avec les objectifs de l'organisation. Bien que le Scrum Master facilite le travail et que les Développeurs l'exécutent, aucun des deux ne dispose du pouvoir d'annulation. Les parties prenantes influencent les décisions, mais ne disposent d'aucun pouvoir formel.

Responsabilité et animation du Daily Scrum : Les Developers sont propriétaires du Daily Scrum et le conduisent en tant qu'événement auto-organisé. Le rôle du Scrum Master est de s'assurer qu'il a lieu et de lever les obstacles, mais il n'en assure pas l'animation à moins que les Developers ne le demandent explicitement. Cela préserve l'autonomie des Developers tout en permettant le soutien du Scrum Master si nécessaire, distinguant ainsi l'animation (assistance optionnelle) de la présence obligatoire ou du contrôle.

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

Réponse : S'assurer que chaque Incrément les respecte.
Explication : Les exigences non fonctionnelles (performance, sécurité, scalabilité) doivent être intégrées dans la Definition of Done et satisfaites par chaque Incrément, et non traitées ultérieurement ou séparément.

Équipes auto-organisées : Les Scrum Teams déterminent de manière autonome la répartition du travail, l'ordre d'exécution et les méthodes de réalisation, sans directive externe. Cela favorise la responsabilisation et l'adaptabilité. Contrairement à l'autonomie individuelle (éléments distracteurs : horaires de travail, contrôle du budget), l'auto-organisation repose sur une prise de décision collective au sein du périmètre de l'équipe.

La définition du Sprint Goal est une activité collaborative réalisée lors du Sprint Planning. Le Product Owner apporte un objectif métier — le « pourquoi » du Sprint — tandis que les Développeurs contribuent leur perspective technique sur ce qui est faisable. Le Product Owner ne définit pas le périmètre de manière unilatérale, et n'arrive pas non plus avec un Sprint Goal rédigé à l'avance. Cette collaboration garantit que le Sprint Goal reflète à la fois la valeur métier et la réalité du développement.

Réponse : DoD = engagement qualité pour l'Increment.
Explication : La Definition of Done établit le standard de qualité pour chaque Increment et garantit la transparence sur ce que signifie « Terminé ».

Les métriques de valeur sont basées sur les résultats, pas sur les livrables. Le délai de mise sur le marché indique à quelle vitesse le produit peut répondre aux besoins des clients et saisir les opportunités commerciales. La satisfaction client mesure directement si le produit atteint son objectif. La vélocité mesure le débit de l'équipe (pas la valeur), et le pourcentage de périmètre implémenté mesure le respect du plan — aucun de ces deux indicateurs ne montre si les clients bénéficient réellement du produit.

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 : Optionnelle (pratique courante, non prescrite).
Explication : Scrum ne prescrit pas de Définition de Prêt (Definition of Ready). Un niveau de clarté suffisant est tout ce qui est nécessaire pour permettre la sélection et l'engagement lors du Sprint Planning.

Réponse : Les opportunités d'inspection et d'adaptation sont perdues ; le Sprint Backlog devient inexact ; les impediments remontent plus lentement.
Explication : La cadence quotidienne du Daily Scrum est essentielle pour permettre une adaptation rapide dans un travail complexe. Des intervalles plus longs entre les inspections laissent les plans s'éloigner de la réalité et permettent aux impediments de s'accumuler avant d'être pris en charge.

Concept clé : La flexibilité du périmètre du Sprint dans les limites du Sprint Goal. Au cours d'un Sprint, la Development Team et le Product Owner peuvent affiner et négocier des éléments spécifiques du Sprint Backlog afin de mieux délivrer de la valeur et de s'adapter aux nouvelles informations qui émergent, à condition que le Sprint Goal reste protégé. Cela diffère du changement du Sprint Goal lui-même, qui est interdit. À mesure que le travail avance, l'équipe peut découvrir que certains éléments sont plus importants que prévu, nécessitent des approches différentes, ou que de nouvelles informations font surface. Le Product Owner peut remplacer des éléments de moindre priorité par des éléments à plus forte valeur, supprimer des éléments qui ne correspondent plus aux apprentissages réalisés, ou ajuster les critères d'acceptation en fonction des retours des parties prenantes — tout cela sans abandonner l'engagement du Sprint. Cette flexibilité favorise l'empirisme tout en maintenant la responsabilité, distinguant ainsi Scrum des approches waterfall rigides où le périmètre est figé. Cependant, les changements de périmètre ne doivent pas compromettre la capacité à atteindre le Sprint Goal.

Réponse : Faux.
Explication : La Sprint Review est une session de travail collaborative visant à inspecter l'Incrément et à adapter le Product Backlog — ce n'est pas un rapport d'avancement.

Concept clé : Le Daily Scrum est un événement de synchronisation des Developers. Le Daily Scrum est un événement timeboxé de 15 minutes qui se tient chaque jour ouvrable, au cours duquel les Developers inspectent la progression vers l'Objectif du Sprint et adaptent leur plan pour les 24 heures suivantes. Bien que le Product Owner et le Scrum Master puissent être présents, l'événement est structuré pour et destiné principalement aux Developers afin qu'ils s'auto-organisent dans leur travail. L'ensemble de l'organisation n'y assiste pas, et les clients ne font pas partie de cette réunion de coordination interne à l'équipe. Cette distinction est essentielle : le Daily Scrum est centré sur la collaboration des Developers et les ajustements tactiques, et non sur des mises à jour organisationnelles ou des interactions avec les clients.

Réponse : Le Product Owner (en collaboration avec l'organisation).
Explication : La décision de livraison est une décision métier. Le Product Owner décide en fonction de la valeur, de la transparence et du contexte organisationnel.

Réponse : Discuter avec le sponsor pour simplifier le rapport et s’assurer qu’il répond aux besoins réels de décision.

Responsabilité du Product Owner dans la priorisation du backlog : Le Product Owner est l'unique responsable de la priorisation du backlog produit. Cette responsabilité est fondamentale dans le cadre Scrum et découle directement du PMBOK 7e édition qui reconnaît les approches adaptatives. Le Product Owner priorise les éléments en fonction de la valeur métier, des besoins des stakeholders, du retour client et de la stratégie globale du produit. Cette décision ne peut pas être déléguée au Scrum Master, qui joue un rôle de facilitateur et de gardien des processus Scrum, ni à l'équipe de développement qui doit se concentrer sur l'exécution. Le Scrum Master ne priorise jamais en fonction de la vélocité (option 2 est fausse : la vélocité est un indicateur de capacité, non un critère de priorisation). L'équipe de développement ne décide pas collectivement la priorisation (option 3 est fausse : elle peut être consultée, mais c'est du ressort du PO). Enfin, bien que le commanditaire ait une influence, il ne valide pas la priorisation à chaque sprint (option 4 est fausse : c'est un processus continu du PO). Cette clarté de responsabilité est essentielle pour garantir l'alignement stratég

Processus de gestion des risques : Les quatre étapes suivent une logique causale incontournable. D'abord, identifier tous les risques potentiels. Ensuite, les analyser qualitativement et quantitativement pour évaluer leur impact. Puis, planifier des réponses (éviter, atténuer, accepter). Enfin, surveiller leur évolution. Inverser identification et analyse ou placer le suivi avant la planification violerait cette séquence logique fondamentale.

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

Gestion des risques techniques : Face à une technologie inconnue, il faut d'abord valider la faisabilité via formation ou proof of concept plutôt que d'ignorer le risque, de sous-traiter aveuglément ou de simplifier sans analyse. Cette approche réduit les incertitudes avant la mise en œuvre.

Concept clé : L'adaptabilité (Tailoring) dans le PMBOK 7 : L'adaptabilité, également appelée "tailoring", est un principe fondamental du PMBOK 7e édition qui consiste à ajuster délibérément les pratiques, les processus, les outils et l'approche de gestion de projet en fonction du contexte spécifique du projet. Cela signifie que le gestionnaire de projet doit évaluer les caractéristiques uniques du projet (taille, complexité, environnement organisationnel, culture, contraintes, risques) et sélectionner les méthodes les plus appropriées, qu'elles soient prévisionnelles, agiles, hybrides ou autres. L'adaptabilité n'est pas une phase ponctuelle mais un processus continu tout au long du cycle de vie du projet. Pourquoi cette réponse est correcte : Cette réponse capture l'essence du PMBOK 7, qui reconnaît qu'il n'existe pas de "taille unique" applicable à tous les projets. Le gestionnaire doit être flexible et intelligent dans ses choix méthodologiques. Distinction avec les autres options : La deuxième option est incorrecte car elle impose systématiquement l'Agile, ce qui contredit le principe d'adaptabilité. La troisième est fausse car l'adaptabilité s

Contrat T&M (Temps & Matériel) : le fournisseur facture les heures réelles travaillées plus les matériaux consommés. L'acheteur assume le risque de coût car il n'y a pas de plafond contractuel. Contrairement aux contrats à prix fixe (risque fournisseur) ou au prix unitaire, le T&M offre peu de protection budgétaire.

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-1.2.2 (K1) – Rappeler la relation entre les tests et l’assurance qualité.
● a) Correct → Les tests font partie des activités d’assurance qualité, qui incluent également l’amélioration des processus, la documentation et le respect des normes.
● b) Faux → Les tests ne remplacent pas l’ensemble de l’assurance qualité, qui couvre un périmètre bien plus large (gestion des risques, validation des exigences, etc.).
● c) Faux → L’assurance qualité ne se limite pas aux tests, elle englobe des pratiques préventives et correctives.
● d) Faux → Les tests et l’assurance qualité sont liés : l’assurance qualité vise à améliorer la qualité globale du produit, et les tests en sont un des moyens.

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-5.1.7 (K2) - Résumer les quadrants du test et leurs relations avec les niveaux et les types de tests.

La bonne réponse est b) :

1. Test d\'accessibilité - Orienté métier, critique du produit (C)
2. Test unitaire - Orienté technologie, support à l\'équipe de développement (A)
3. Test d\'acceptation utilisateur - Orienté métier, critique du produit (C)
4. Test de performance - Orienté technologie, critique du produit (D)
● a) Faux → Le test d\'acceptation utilisateur est en C (orienté métier, critique du produit), pas en B.
● b) Correct → Toutes les correspondances sont correctes.
● c) Faux →- Le test d\'accessibilité est en C, pas en D, et le test de performance est en D, pas en B.
● d) Faux → Le test d\'accessibilité est en C, pas en D, et le test unitaire est en A, pas en B.

Cette question correspond à l’objectif d\'apprentissage FL-2.1.6 (K2) – Expliquer comment les rétrospectives peuvent être utilisées comme mécanisme d\'amélioration des processus.
● a) Faux → Supprimer une activité essentielle n’est pas une amélioration mais une régression.
● b) Faux → Agrandir les sprints ne règle pas le problème d’origine.
● c) Correct → La rétrospective permet d’analyser, comprendre et agir sur les causes racines, ce qui est une véritable démarche d’amélioration continue.
● d) Faux → Cela aggraverait le manque de communication, au lieu de résoudre le problème.

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

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

Cette question correspond à l’objectif d’apprentissage FL-1.4.4 (K2) – Expliquer la valeur du maintien de la traçabilité.
● a) Faux → La traçabilité ne vise pas à optimiser la performance du logiciel, mais à assurer une couverture de test complète.
● b) Correct → Le maintien de la traçabilité permet d’établir un lien entre les exigences, les tests et les défauts détectés, garantissant ainsi qu’aucune exigence n’a été oubliée.
● c) Faux → Même avec la traçabilité, la documentation des tests reste nécessaire pour assurer un suivi efficace et une justification des validations effectuées.
● d) Faux → Les rapports de test restent nécessaires, la traçabilité vient en complément pour s’assurer que les tests couvrent bien les exigences.

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-4.4.1 (K2) - Expliquer l\'estimation d\'erreurs.

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

Phase d'analyse : Cette phase consiste à examiner les indicateurs d'incident afin de déterminer les causes profondes, les vecteurs d'attaque et l'étendue de la compromission. Comprendre l'origine d'une attaque nécessite un examen détaillé des journaux, des artefacts et du comportement des systèmes. La détection permet d'identifier qu'un incident s'est produit, le confinement en stoppe la propagation, et les retours d'expérience interviennent après l'incident — seule la phase d'analyse se concentre sur l'investigation de la source.

La défense en profondeur (également appelée sécurité en couches) utilise plusieurs contrôles de sécurité superposés afin que, si une couche est compromise, les couches supplémentaires protègent toujours l'actif. Exemples de couches : sécurité physique → pare-feu réseau → IDS/IPS → pare-feu hôte → antivirus → WAF applicatif → chiffrement → supervision. Cette approche s'inspire de la conception des châteaux médiévaux : remparts, douves, pont-levis, gardes, enceintes intérieures. Aucun contrôle unique n'est parfait — la superposition assure la redondance. C'est l'opposé de la sécurité par l'obscurité (qui repose sur le secret plutôt que sur des contrôles robustes).

Chiffrement intégral du disque (Full Disk Encryption) : chiffre l'intégralité des données présentes sur le disque, les rendant illisibles sans la clé appropriée — même si le disque est retiré et accédé depuis un autre appareil. Contrairement aux mots de passe BIOS (facilement contournables), aux antivirus (inefficaces contre le vol physique) ou aux permissions NTFS (contournées en démarrant un système d'exploitation alternatif), le chiffrement protège les données au niveau matériel, quelle que soit la manière dont l'appareil est accédé.

Ingénierie sociale : exploite la psychologie humaine plutôt que les systèmes techniques pour manipuler les utilisateurs et les amener à divulguer des données sensibles, des identifiants ou des accès. Contrairement aux pare-feux (A) ou aux logiciels malveillants (D), elle cible le maillon le plus faible : les personnes. Les exploits logiciels (C) sont de nature technique et ne relèvent pas de la manipulation sociale.

Sauvegarde et récupération : une sauvegarde est une copie de données stockée séparément de l'original, permettant la restauration après une suppression accidentelle ou une perte de données. Il s'agit du mécanisme principal de récupération des données. Les journaux antivirus détectent les logiciels malveillants mais ne peuvent pas restaurer les fichiers ; le chiffrement protège les données mais ne les récupère pas ; les permissions contrôlent les accès mais ne restaurent pas le contenu supprimé.

La confidentialité : garantit que les informations sensibles ne sont accessibles qu'aux personnes autorisées. L'accès non autorisé à des fichiers confidentiels viole directement ce principe en exposant des données restreintes à des utilisateurs non autorisés. Tandis que l'intégrité protège l'exactitude des données, la disponibilité assure l'accès aux utilisateurs autorisés, et l'authenticité vérifie l'identité — aucun de ces principes ne traite la divulgation non autorisée d'informations sensibles.

Les attaques de type Man-in-the-Middle (MitM) surviennent lorsqu'un attaquant se positionne entre deux parties en communication, interceptant et modifiant potentiellement les messages sans être détecté. Les méthodes courantes incluent l'empoisonnement ARP, les points d'accès Wi-Fi malveillants et le SSL stripping. Les défenses comprennent l'épinglage de certificats (certificate pinning), HTTPS avec HSTS et le TLS mutuel (mTLS). Les attaques par rejeu réutilisent des identifiants capturés. Le détournement de session vole une session déjà établie. L'écoute passive est une forme de MitM sans modification des données.

Un employé a cliqué sur un lien dans un e-mail frauduleux et a saisi ses identifiants sur un faux site. C'est typiquement une attaque de phishing, qui consiste à tromper la victime pour obtenir des informations sensibles via un site ou un message imitant une source légitime.

Gestion des correctifs : processus systématique d'identification, de test et de déploiement de mises à jour logicielles visant à corriger les vulnérabilités de sécurité et les bogues. Les organisations appliquent des correctifs pour éliminer les failles connues que les attaquants exploitent, réduisant ainsi les risques de violation. Contrairement à la surveillance de l'activité des utilisateurs (B), à la sauvegarde des données (C) ou aux politiques de mots de passe (D), l'application de correctifs s'attaque directement à la cause profonde de nombreux incidents de sécurité en fermant les vecteurs d'attaque avant qu'ils ne soient exploités.

Réponse : L'ARO (Annual Rate of Occurrence).
Explication : L'ARO quantifie la fréquence à laquelle un événement à risque spécifique se produit par an. Si les données historiques montrent que les attaques par ransomware ont une très faible probabilité (ARO faible), la perte annuelle attendue (ALE = SLE × ARO) peut ne pas justifier le coût de la prime d'assurance.

Réponse : INSERT. Explication : INSERT est une instruction DML qui ajoute de nouvelles lignes à une table. Avec UPDATE, DELETE et SELECT, INSERT est une opération DML fondamentale qui modifie les valeurs de données en ajoutant de nouvelles lignes sans modifier les enregistrements existants.

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

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.

Clé primaire : colonne ou ensemble de colonnes garantissant l'unicité de chaque enregistrement dans une table relationnelle. Elle empêche les doublons et permet l'identification précise des données. Contrairement aux clés étrangères (qui créent des relations entre tables) ou aux index (qui optimisent les performances), la clé primaire est fondamentalement un mécanisme d'intégrité et de distinction des données.

Données non structurées vs structurées : Les données non structurées n'ont pas de schéma prédéfini (vidéo, image, audio). Une vidéo de formation est un exemple parfait car elle combine contenus visuels et auditifs sans organisation tabulaire. À l'inverse, SQL et CSV imposent des lignes/colonnes (structurées), tandis que JSON possède une structure hiérarchique définie (semi-structuré).

Réponse : Graphe. Explication : Les bases de données en graphe se caractérisent par l'utilisation de nœuds (représentant des entités) et d'arêtes (représentant les relations entre entités). Cette structure traite efficacement les données hautement connectées et les requêtes de relations complexes.

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

Azure SQL Database est disponible en deux modèles : Single Database (base de données unique avec ses propres ressources dédiées, idéale pour les nouvelles applications) et Elastic Pool (plusieurs bases partagent un pool de ressources, optimal pour des bases aux pics d'activité décalés). Il existe aussi Azure SQL Managed Instance pour les migrations depuis SQL Server on-premises avec compatibilité maximale. Les trois sont des services PaaS gérés par Microsoft (patching, backups automatiques).

Azure SQL Managed Instance : solution cloud offrant une compatibilité quasi complète avec SQL Server on-premise, incluant les agents SQL, jobs, et la réplication native. Contrairement à Azure SQL Database (service entièrement managé avec limitations), Managed Instance émule l'environnement SQL Server complet dans une instance dédiée, facilitant la migration sans refonte majeure.

Réponse : UPDATE. Explication : Pour modifier une valeur existante dans une table de base de données, utilisez l'instruction DML UPDATE : UPDATE [tableau] SET [colonne] = [valeur] WHERE [condition]. INSERT ajoute de nouvelles lignes, SELECT lit les données, et DELETE supprime les lignes.

Réponse : On‑premise ; Cloud Private Edition ; Cloud Public (multi‑tenant).
Explication : S/4HANA existe en plusieurs modes de déploiement officiels : on‑premise, cloud public et cloud private edition. Les offres non‑SAP ou appliances IoT ne constituent pas des déploiements S/4HANA.

Réponse : ACDOCA
La table ACDOCA (Universal Journal Entry Line Items) est la table centrale du Journal Universel en SAP S/4HANA. Elle remplace BSEG (FI), COEP (CO) et ANEK (AA) en consolidant toutes les écritures comptables dans un référentiel unique.

Réponse : Vrai
Dans la comptabilité parallèle de S/4HANA, un ledger non principal peut être assigné à une variante d'exercice fiscal différente du ledger principal (0L). Cela permet, par exemple, d'avoir un ledger IFRS sur une année civile et un ledger local sur un exercice décalé.

Réponse : Le moteur d’accruals (Accrual Engine) et ses modèles.
Explication : Il génère automatiquement les écritures périodiques selon un paramétrage fondé sur des modèles.

Réponse : Domaine d'activité ; secteur d'activité ; centre de profit. Explication : Les domaines d'activité, les secteurs d'activité et les centres de profit sont des unités organisationnelles qui peuvent être attribuées à plusieurs codes sociétés pour le reporting interentreprises. Ils ne sont pas liés à un seul code société, permettant une analyse financière de groupe entre les entités juridiques.

Ordre correct Procure-to-Pay :

1. Commande d'achat (ME21N) avec imputation
2. Réception de marchandises (MIGO/GR)
3. Réception de facture (MIRO)
4. Paiement via F110 (automatique) ou F-53 (manuel)

Le flux P2P génère des écritures automatiques dans FI à la réception de marchandises (débit stock/charges / crédit GR/IR) et lors de la facture (débit GR/IR / crédit fournisseur).

Réponse : Comptes gérés en postes ouverts ; Critères d’égalité (montant/devise/date) ; Champs de correspondance (référence/assignation).
Explication : F.13 lettrent automatiquement selon règles et champs de correspondance.

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

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

Réponse : Vrai
Le report de soldes GL (Balance Carryforward) peut être réexécuté autant de fois que nécessaire. Si des corrections sont apportées après le premier report, il suffit de relancer le programme (FAGLGVTR) pour actualiser les soldes d'ouverture de l'exercice suivant.

Concept clé : Transparence dans le test AI. Une documentation complète des capacités du modèle, de ses limitations et des sources d'entraînement permet aux parties prenantes de comprendre et d'évaluer les systèmes AI. Les testeurs doivent valider que tous les éléments de transparence requis sont correctement documentés et accessibles aux parties concernées.

Réponse : Il devrait y avoir au moins une petite équipe qui se consacre à la conduite des efforts d\'\"amélioration continue\".
Explication : ITIL 4 recommande qu\'une équipe dédiée, même réduite, pilote les efforts d\'amélioration continue pour maintenir le focus et la cohérence, sans que cela n\'empêche toute l\'organisation d\'y contribuer.

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 : Progresser par itérations avec des retours.
Explication : Le principe \'Progresser par itérations avec des retours\' recommande de diviser le travail en petites étapes gérables avec des boucles de feedback fréquentes pour s\'adapter et corriger rapidement.

Réponse : protéger.
Explication : La pratique de gestion de la sécurité de l\'information a pour but de protéger les informations de l\'organisation contre les menaces, en assurant confidentialité, intégrité et disponibilité.

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

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

Réponse : Une demande d\'un utilisateur concernant quelque chose qui fait partie intégrante de la fourniture normale des services.
Explication : La gestion des demandes de services prend en charge les demandes standard faisant partie de la fourniture normale des services, comme une réinitialisation de mot de passe ou la commande d\'un équipement.

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.

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

• Microsoft Defender for Endpoint permet :

  • Détection automatique des menaces sur les endpoints

  • Investigation automatisée des incidents

  • Actions de remédiation automatiques pour contenir et corriger les menaces

• Les autres options ne gèrent pas directement l’investigation et la remédiation automatique :

  • A : PIM gère les rôles à privilèges temporaires.

  • B : Secure Score propose des recommandations de sécurité, pas de remédiation automatique.

  • D : Mailbox hold conserve les emails pour conformité, pas pour gérer des incidents de sécurité.

• onditional Access + Intune compliance policies permet de :

  • Vérifier que les appareils respectent les règles de sécurité avant de leur donner accès aux services Microsoft 365 (Exchange, SharePoint, Teams, etc.)

• Cette fonctionnalité nécessite Microsoft 365 (E3/E5) avec Azure AD Premium P1, et n’est pas disponible dans un Office 365 standalone.

• Les autres options ne gèrent pas le contrôle d’accès basé sur la conformité des appareils :

  • A : DLP protège les données mais ne contrôle pas l’accès selon la conformité des appareils.

  • C : Gestion de base des apps mobiles ne couvre pas l’accès aux services cloud.

  • D : Multi-Geo gère la localisation des données, pas la conformité des appareils.

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.

• Copilot Chat dans Microsoft Teams peut analyser les conversations et générer des tâches.

• Limitation actuelle : il peut créer des tâches dans Microsoft Planner, mais ne prend pas encore en charge la création directe de tâches dans Microsoft To Do.

• Cela signifie que si vous demandez à Copilot de convertir des éléments d’action en To Do, la commande ne fonctionnera pas directement.

Microsoft 365 Apps propose différents canaux de mise à jour :

1. Current Channel (Canal actuel)

   • Reçoit les dernières fonctionnalités, correctifs et mises à jour de sécurité dès qu’elles sont publiées.

   • Idéal pour les utilisateurs qui veulent accéder rapidement aux nouveautés.

2. Monthly Enterprise Channel (Canal mensuel pour entreprises)

   • Regroupe les nouvelles fonctionnalités et correctifs dans une seule mise à jour mensuelle.

   • Fournit un rythme plus prévisible pour les équipes informatiques, tout en maintenant les correctifs de sécurité à jour.

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

👉 Elle permet notamment :

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

• De changer la couleur du texte

• D’ajouter des icônes

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

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

Dans Exchange Online, Microsoft assure automatiquement :

• La haute disponibilité (High Availability) grâce à la réplication native des bases de données de boîtes aux lettres entre plusieurs serveurs et centres de données.

• La reprise après sinistre (Disaster Recovery) grâce à l’architecture distribuée et redondante de Microsoft 365.

Pour répondre aux exigences réglementaires de conservation :

• Litigation Hold permet de conserver les e-mails d’une boîte aux lettres, même s’ils sont supprimés par l’utilisateur.

• Cela garantit l’intégrité et la disponibilité des données à des fins légales ou réglementaires.

👉 Ensemble, ces fonctionnalités assurent la disponibilité continue et la conservation réglementaire des données.

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

💡 Explication :

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

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

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

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

    🎯 À retenir pour l’examen MS-900 :

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

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

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.

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

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

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

Les comptes break-glass sont des comptes d’accès d’urgence utilisés uniquement lorsque :

• L’authentification normale est indisponible

• Les mécanismes MFA ou Conditional Access sont défaillants

• L’environnement est compromis (ex. attaque ransomware)

Les bonnes pratiques Microsoft recommandent :

• 🔐 Identifiants stockés dans un coffre-fort sécurisé hors ligne

• 🔄 Validation régulière (tests d’accès contrôlés)

• 🚨 Surveillance renforcée

• 🔒 Utilisation uniquement en cas d’urgence

Pourquoi hors ligne ?

En cas de ransomware ou compromission massive :

• Les systèmes en ligne (y compris SIEM) peuvent être impactés.

• Le coffre-fort hors ligne réduit le risque de compromission.

• Les exigences réglementaires demandent :

  • Aucun accès permanent → limitation stricte des privilèges

  • Journalisation et révision → audit complet des accès administratifs

• Azure AD Privileged Identity Management (PIM) :

  • Fournit l’accès Just-in-Time aux rôles privilégiés (Owner, Contributor, etc.)

  • Les administrateurs doivent activer explicitement leur rôle pour une période limitée

  • Chaque activation est journalisée dans Azure AD et Azure Monitor, ce qui permet audit et conformité

• C’est la solution recommandée par Microsoft pour les environnements réglementés (finance, santé, gouvernement)

Le CCPA impose notamment :

• Le droit d’accès aux données personnelles

• Le droit à la suppression (Right to deletion)

Microsoft Priva Subject Rights Requests (SRR) permet :

• De gérer les demandes des personnes concernées

• D’orchestrer la recherche des données personnelles

Cependant, pour que la suppression soit réellement possible et conforme :

👉 Il faut que les politiques de rétention (Data Lifecycle Management) soient correctement configurées.

Pourquoi ?

• Les stratégies de rétention déterminent si les données peuvent être supprimées ou si elles sont conservées pour des raisons légales.

• Une politique de rétention peut empêcher la suppression si une obligation légale impose la conservation.

• Elles permettent d’automatiser la suppression lorsque la durée de conservation est atteinte.

Sans gestion du cycle de vie des données, la suppression conforme au CCPA ne peut pas être garantie.

• Azure AD / Entra PIM distingue :

  • Attribution de rôle : l’administrateur se voit attribuer un rôle (souvent par IT ou via JIT)

  • Activation de rôle : l’utilisateur active le rôle pour l’utiliser

• Exiger MFA sur l’activation de rôle :

  • Garantit que chaque activation est sécurisée par MFA, indépendamment de l’état de session existant

  • Respecte le principe du moindre privilège et de Zero Trust pour les rôles privilégiés

• Sécurité renforcée pour les comptes administratifs, même avec sessions existantes

• Dependabot est une fonctionnalité de GitHub Advanced Security qui :

  • Scanne automatiquement les dépendances open-source dans vos projets

  • Identifie les vulnérabilités connues via des bases CVE (Common Vulnerabilities and Exposures)

  • Propose des mises à jour sécurisées dans les workflows CI/CD

• Avantages :

  • Fonctionne directement pendant le build ou le merge

  • Intégré dans GitHub Actions, donc parfait pour les déploiements Azure App Service

  • Permet d’empêcher les vulnérabilités de production

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

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

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.

Automatic Scaling avec min_idle_instances=3 répond exactement aux exigences : App Engine scale automatiquement selon le taux de requêtes ET maintient toujours au minimum 3 instances disponibles en attente. Basic Scaling n'a pas de paramètre min_instances.

Le flux correct est : build image Docker → push vers Container Registry → créer YAML Deployment → kubectl apply. Container Registry est le registre d'images GCP. Cloud Storage ne peut pas servir d'images Docker. kubectl ne déploie pas directement des Dockerfiles.

Quand le Cloud SDK est installé depuis le dépôt Ubuntu de Google (apt), les composants supplémentaires doivent être installés avec apt get install (pas gcloud components install). La commande correcte est : sudo apt-get install google-cloud-sdk-datastore-emulator.

Les tables externes BigQuery pointant vers Cloud Storage permettent d'interroger les données AVRO directement avec SQL sans les importer dans BigQuery. C'est plus rapide (pas de chargement) et moins cher (pas de stockage BigQuery permanent).

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.

Cloud Marketplace propose des images Cassandra préconfigurées que chaque équipe peut déployer rapidement en autonomie, avec une isolation complète entre les environnements. C'est la méthode la plus rapide et nécessitant le moins d'effort d'administration.

Les journaux d'audit d'accès aux données enregistrent qui a lu, modifié ou supprimé des données. En filtrant par email de l'utilisateur comme principal, on peut voir tous ses accès aux données sensibles. Les journaux d'activité Admin n'enregistrent pas les lectures de données.

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

Cette affirmation est Vraie. La dette technique s'accumule avec le temps — les raccourcis accumulés et les mauvais choix de conception rendent les évolutions futures de plus en plus difficiles et coûteuses. Cela ralentit la vélocité et va à l'encontre d'un rythme soutenable, l'un des principes fondamentaux de Scrum.

Réponse correcte : Faux. Le Guide Scrum exige un Incrément unique et intégré à la fin de chaque Sprint, même dans les environnements à grande échelle. Des branches séparées par équipe nuisent à cette transparence et créent un risque d'intégration. Chaque équipe doit œuvrer à la réalisation d'un seul Incrément livrable qui démontre une progression continue vers l'objectif du produit.

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.

Selon le Guide Scrum, c'est l'équipe de développement qui décide où tenir le Daily Scrum. Le lieu choisi doit répondre à leurs besoins de communication, et ne doit pas être imposé par la direction, le Scrum Master ou fixé arbitrairement. Cela reflète l'autonomie et l'auto-organisation de l'équipe.

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.

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

Réponses correctes : Options 1 et 3. Le travail ne répondant pas à la Definition of Done ne doit pas être inclus dans l'Increment (option 1), conformément au Guide Scrum. Le travail restant doit être estimé et retourné au Product Backlog (option 3) afin que le Product Owner puisse le reprioriser. Les options 0 et 2 violent la Definition of Done en incluant ou en divisant un travail incomplet, ce qui nuit à la transparence et à la qualité.

La concentration et la productivité s'améliorent lorsque les membres de l'équipe travaillent à temps plein au sein d'une seule Scrum Team, et un Product Backlog bien structuré minimise les changements de contexte entre les équipes. Il n'est pas nécessaire de personnaliser le cœur de Scrum pour passer à l'échelle — une gestion appropriée du Backlog et une composition d'équipe adaptée permettent de résoudre ces problèmes tout en préservant l'intégrité du framework.

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

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

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

Réponse : En fournissant un atelier sur les techniques de conception de tests.
Explication : Un atelier sur les techniques de conception de tests remédie directement à la faible efficacité de détection des défauts en dotant les testeurs de méthodes systématiques et répétables pour dériver des cas de test de meilleure qualité. Les techniques pratiques (partitionnement des équivalences, analyse des valeurs limites, tables de décision, transitions d\'état, techniques d\'appairage) améliorent la couverture et augmentent la probabilité de détection des défauts.

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

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

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

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

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

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

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

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

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