Ne découvrez pas l'examen
le jour J

Réponse : AWS CloudTrail.
Explication : AWS CloudTrail consigne tous les appels d’API et accès sur les ressources AWS du compte.

Réponse : Instances Spot.
Explication : Les instances Spot offrent des économies importantes et sont adaptées aux charges tolérantes à l’interruption, comme le transcodage média.

Réponse : Ressources élastiques / Économies de coûts.
Explication : AWS offre l’élasticité (scalabilité à la demande) et des économies par rapport à l’investissement en capital sur site.

Réponse : Un nom d’utilisateur et un mot de passe.
Explication : L’accès à la console AWS en tant qu’utilisateur IAM se fait avec un identifiant et un mot de passe personnels.

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

Réponse : Facturation à la seconde, minimum une minute.
Explication : AWS facture les instances Linux EC2 à la seconde, après la première minute de lancement (pour une grande flexibilité budgétaire).

Réponse : AWS TCO Calculator.
Explication : Le TCO Calculator permet d’estimer le coût total de possession de votre infrastructure sur site versus AWS.

Réponse : AWS Direct Connect.
Explication : AWS Direct Connect offre une liaison privée, dédiée et sécurisée entre un datacenter client et le cloud AWS, pour des besoins de performance ou sécurité accrus.

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

Réponse : Construire le schéma relationnel / Gérer les paramètres de la base.
Explication : Le client doit gérer la structure logique (schéma, paramètres) ; AWS gère l’infrastructure sous-jacente.

Fine-tuning modifie les poids du modèle en l'entraînant sur des données spécifiques — adapté quand le style ou le comportement doit changer profondément, mais coûteux en calcul et en données. RAG ne modifie pas le modèle : il récupère dynamiquement des documents pertinents au moment de l'inférence — idéal pour des données qui changent fréquemment ou des bases de connaissances volumineuses. Le choix dépend du budget, de la fréquence de mise à jour des données et du type d'adaptation 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.

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

SageMaker Clarify : service AWS spécialisé dans l'explicabilité des modèles IA et la détection de biais. Il génère des rapports détaillés sur les prédictions (SHAP, LIME) et mesure les biais avant/après déploiement. Contrairement à Model Monitor (dérive de performance), Data Wrangler (préparation) et Feature Store (stockage), Clarify se concentre exclusivement sur la transparence et l'équité des modèles.

Workflow SageMaker Serverless Inference : L'artefact du modèle doit d'abord résider sur S3 (source obligatoire), ensuite vous créez la ressource modèle SageMaker qui référence cet artefact, puis la configuration d'endpoint serverless définit les paramètres de concurrence/mémoire, et enfin le déploiement instancie l'endpoint. Les autres options inversent cet ordre logique de dépendances.

Guardrails Bedrock et détection PII : Les Guardrails sont des mécanismes de sécurité qui inspectent les entrées et sorties des modèles IA pour identifier et filtrer les informations personnelles (PII : noms, emails, numéros, adresses). Contrairement aux simples filtres de contenu, ils appliquent des politiques configurables qui peuvent bloquer, rediriger ou masquer les données sensibles, protégeant ainsi la conformité et la confidentialité des utilisateurs.

Vrai. Les Knowledge Bases (RAG) réduisent la taille du prompt et injectent uniquement les passages pertinents au moment de l’inférence.

Containment Rate : mesure le pourcentage d'interactions complètement résolues par le chatbot sans escalade humaine. C'est le KPI direct de l'automatisation, contrairement à AHT (durée) ou NPS (satisfaction) qui sont des indicateurs secondaires, et FCR qui évalue la résolution globale sans distinguer automation vs agent.

On indexe la base (embeddings), puis à la requête on recherche les passages pertinents, on les injecte dans le prompt et le FM génère la réponse.

Modèles génératifs (GAN et diffusion) : apprentissent la distribution statistique complète des données pour générer de nouveaux échantillons fidèles. Les GANs opposent un générateur et un discriminateur en compétition, tandis que les modèles de diffusion affinent progressivement le bruit. XGBoost et ResNet sont discriminatifs (classification), WaveNet s'applique au son : seuls GAN/diffusion capturent les caractéristiques statistiques globales requises pour synthétiser images réalistes.

Auteurs du Scrum Guide : Ken Schwaber et Jeff Sutherland, les créateurs de Scrum, sont les mainteneurs officiels du Scrum Guide. Cela garantit la cohérence et l'autorité dans la définition de Scrum. Le Guide est la source de vérité unique pour les pratiques Scrum, ce qui le distingue des autres cadres de travail ou interprétations.

Réponse : Faux.
Explication : Plusieurs Scrum Teams peuvent avoir des dates de début de Sprint différentes. Bien que des Sprints synchronisés puissent simplifier l'intégration, Scrum ne l'exige pas. Les équipes doivent choisir les dates de début qui correspondent le mieux à leurs besoins de coordination.

Timebox de la Sprint Retrospective : Le Guide Scrum établit une durée maximale de 1h30 par semaine de Sprint. Pour un Sprint d'un mois (4 semaines), cela donne un maximum de 3 heures. Cela garantit une réflexion ciblée sans investissement de temps excessif, la distinguant ainsi des activités de planification plus longues comme le Sprint Planning (8 heures maximum pour les Sprints d'un mois).

Definition of Done : Une liste de contrôle formelle définissant à quel moment un Increment répond aux standards de qualité. Elle garantit la cohérence, empêche que des travaux incomplets soient considérés comme « terminés », et permet aux équipes de maintenir une vélocité prévisible ainsi qu'une qualité produit constante d'un Sprint à l'autre.

Cohérence de la durée du Sprint : La durée du Sprint, une fois établie par la Scrum Team, doit rester fixe afin de créer un rythme prévisible et de permettre une planification fiable. Une cadence cohérente permet aux équipes de développer un rythme soutenable, d'améliorer la précision des prévisions et de faciliter le rythme organisationnel. Modifier la durée en cours de Sprint rompt les engagements ; des durées variables empêchent l'identification de tendances ; le Product Owner ne la définit pas unilatéralement ; deux semaines n'est pas une durée obligatoire.

Réponse : Le niveau d'incertitude technologique ; le risque d'être déconnecté des parties prenantes.
Explication : Des Sprints plus courts réduisent le risque en offrant des opportunités d'inspection et d'adaptation plus fréquentes. Une incertitude technique élevée ou un besoin de retours fréquents de la part des parties prenantes favorisent tous deux des Sprints plus courts.

L'Engagement dans Scrum signifie que chaque personne s'engage à atteindre les objectifs de la Scrum Team — non pas envers un ensemble de tâches spécifiques, mais envers le Sprint Goal et la réussite collective. L'Engagement favorise un travail de qualité et instaure la confiance. À noter : les Scrum Teams s'engagent envers le Sprint Goal, et non nécessairement à terminer chaque élément du Sprint Backlog — elles adaptent leur plan au fur et à mesure de leurs apprentissages.

Propriété du Sprint Backlog : Les Developers mettent à jour le Sprint Backlog de manière exclusive pendant le Sprint, car celui-ci représente leur plan de travail engagé. Eux seuls possèdent les connaissances techniques nécessaires pour affiner les tâches, ajuster les estimations et gérer les détails de mise en œuvre. Bien que le Product Owner influence les priorités et que le Scrum Master facilite le processus, aucun des deux ne peut modifier unilatéralement les éléments du Sprint Backlog — préservant ainsi l'autonomie et la responsabilité des Developers.

Équipes auto-organisées et pluridisciplinaires : Les Scrum Teams disposent de l'autonomie nécessaire pour déterminer comment accomplir leur travail et réunissent des membres aux compétences variées — ingénierie, design, connaissance produit — indispensables pour délivrer de la valeur. Cela contraste avec les structures de type commande-et-contrôle (option 1), l'isolement total qui crée des dépendances (option 2) et les hiérarchies rigides (option 4).

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

Réponse : Faux.
Explication : Les parties prenantes sont invitées à la Sprint Review, et non à la Sprint Retrospective. La Retrospective est un événement privé réservé à l'équipe. Le Product Owner y participe, mais n'y invite pas les parties prenantes externes.

Réponse : Impact sur le chiffre d'affaires ; impact sur la satisfaction client ; impact sur les coûts.
Explication : Le succès d'un produit se mesure à travers des résultats business (chiffre d'affaires, efficacité des coûts) et des résultats utilisateurs (satisfaction). Ces indicateurs reflètent la valeur réellement livrée, contrairement à la vélocité ou aux story points qui mesurent la production.

Transparence du Product Backlog : Le Product Owner est seul responsable de la tenue d'un Product Backlog clair, bien organisé et compréhensible par toutes les parties prenantes — y compris l'équipe Scrum, les dirigeants et les clients. Cette transparence permet une prise de décision éclairée, réduit les malentendus et garantit l'alignement sur les priorités. Bien que le Scrum Master facilite les processus Scrum et que les Developers mettent en œuvre les éléments du Backlog, aucun des deux n'est responsable de la clarté de celui-ci. Le Product Owner doit continuellement affiner, ordonner et communiquer les éléments du Backlog afin de créer une compréhension partagée de ce qui sera construit et pour quelles raisons.

Réponse : Vrai. Selon le Guide Scrum, le Product Owner est responsable de la gestion efficace du Product Backlog, ce qui inclut la compréhension des besoins des parties prenantes. Le Product Owner collabore activement avec ces dernières pour recueillir leurs attentes, les traduire en éléments du Product Backlog et maximiser la valeur du produit. Cette collaboration est une responsabilité fondamentale du Product Owner, qui sert d'interface entre l'équipe Scrum et les parties prenantes. L'affirmation « Faux » est incorrecte car ignorer les parties prenantes irait à l'encontre du rôle même du Product Owner, dont la mission centrale est précisément de comprendre et de prioriser les besoins pour orienter le développement du produit.

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.

Évolution du Product Goal par l'empirisme : Le Product Goal n'est pas figé ; il représente la vision à long terme qui guide le produit. Au fur et à mesure que l'équipe Scrum inspecte les Increments du produit, recueille les retours des parties prenantes et acquiert des connaissances sur les conditions du marché, les besoins des utilisateurs et la faisabilité technique, le Product Goal peut et doit évoluer. Cela reflète l'empirisme — l'un des piliers fondamentaux de Scrum — selon lequel l'équipe s'adapte en continu sur la base de preuves et d'apprentissages. Cependant, le Product Goal fournit une orientation stratégique et ne doit pas changer de manière arbitraire ; des changements significatifs interviennent lorsque de nouvelles connaissances importantes émergent et justifient de reconsidérer la vision. Cela le distingue des Sprint Goals, qui restent fixes durant un Sprint, et du Product Backlog, qui est affiné en continu. Comprendre que le Product Goal peut évoluer permet aux équipes de rester réactives face à la réalité tout en conservant leur focus stratégique.

Le Product Backlog est la source unique de vérité pour tout le travail sur le produit — il est géré par (et non réservé exclusivement à) le Product Owner, qui le maintient ordonné afin d'optimiser la valeur. Il est ordonné selon la priorité, la valeur, les dépendances et le risque — il n'est pas maintenu comme une liste de périmètre figé. Il n'est pas exhaustif dès le départ ; il évolue en continu à mesure que de nouvelles informations émergent. Tout membre de la Scrum Team peut ajouter des éléments ; seul le Product Owner les ordonne.

La Définition of Done (DoD) comme standard de qualité : La Definition of Done est un engagement partagé au sein de la Scrum Team qui établit les critères qu'un Increment doit satisfaire pour être considéré comme terminé et potentiellement livrable. Chaque Increment — la somme de tous les éléments du Product Backlog complétés durant un Sprint — doit se conformer à la DoD sans exception. Cela garantit une qualité constante, réduit la dette technique et maintient la confiance des parties prenantes. La DoD n'est ni optionnelle ni négociable ; elle sert de mesure objective de complétude et prévient l'accumulation de travail inachevé. Les équipes qui appliquent la conformité à la DoD livrent des Increments fiables et potentiellement livrables qui satisfont à la fois la Definition of Done et les critères d'acceptation, permettant une livraison de valeur prévisible et un rythme soutenable tout au long du cycle de vie du produit.

Le Product Backlog est émergent car il évolue continuellement à mesure que la compréhension du produit et du marché s'améliore — ce n'est pas un document figé créé à l'avance. Il est ordonné par le Product Owner en fonction de la valeur et des priorités, et contient tout ce qui est connu comme nécessaire — et non une spécification complète, ce qui contredirait la nature empirique de Scrum. Les autres options le décrivent à tort comme fixe, entièrement détaillé ou comme un outil d'attribution de tâches, aucune de ces descriptions n'étant conforme à la définition du Product Backlog dans le Scrum Guide en tant qu'artefact dynamique et priorisé.

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

L'engagement des parties prenantes : processus de communication et de collaboration continue avec tous les individus ou groupes affectés par ou pouvant affecter le projet. Selon le PMBOK 7e édition, cet engagement est fondamental car il crée un environnement de confiance mutuelle où les attentes sont clarifiées dès le départ, les préoccupations sont adressées proactivement, et chaque partie prenante comprend sa contribution au succès du projet. En effet, un engagement authentique réduit les résistances au changement, minimise les conflits non gérés, renforce l'adhésion aux décisions prises collectivement, et mobilise les ressources nécessaires pour atteindre les objectifs. Cette approche dépasse largement la simple approbation formelle ou la limitation des changements—elle construit un véritable partenariat. Les autres options sont incorrectes : limiter les changements n'est pas l'objectif principal (certains changements sont justifiés), l'approbation formelle n'est qu'un aspect mineur du processus, et l'engagement n'est jamais optionnel mais essentiel dans tous les types de projets, qu'ils soient réglementés ou non.

Fast-tracking : technique de compression du calendrier qui chevauche les phases/tâches normalement séquentielles. Quand EV < PV indique un retard, fast-tracking compense en parallélisant les activités. Contrairement à l'ajustement budgétaire (inefficace sur le délai) ou à la création de marge (mesure préventive), seul le fast-tracking accélère réellement l'exécution.

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.

Réponse : Faciliter la communication et le team building. Cela renforce la cohésion et l’efficacité d’un groupe dispersé.

Plan de management vivant : Le plan de management de projet est un document d'orientation évolutif, créé pendant la planification mais mis à jour continuellement selon les changements, les risques identifiés et les leçons apprises. Contrairement aux idées reçues, il n'est jamais figé après approbation et reste un outil de pilotage dynamique tout au long du projet.

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-6.1.1 (K2) - Expliquer comment

différents types d\'outils de test soutiennent les tests.

● a) Correct → Cette combinaison associe correctement :
○ La conception des cas de test (1) aux outils de conception et
d\'implémentation de tests (A)
○ L\'exécution automatisée des tests (2) aux outils d\'exécution de tests (B)
○ La gestion des environnements de test (3) aux outils d\'infrastructure de test (D)
○ L\'analyse des résultats de test (4) aux outils de gestion des tests (C)
● b) Faux → Cette combinaison associe incorrectement la conception des cas de test (1) aux outils de gestion des tests (C) et l\'exécution automatisée des tests (2) aux outils de conception et d\'implémentation de tests (A).
● c) Faux → Cette combinaison associe incorrectement l\'exécution automatisée des tests (2) aux outils d\'infrastructure de test (D) et la gestion des environnements de test (3) aux outils d\'exécution de tests (B).
● d) Faux → Cette combinaison associe incorrectement la conception des cas de test (1) aux outils de gestion des tests (C) et la gestion des environnements de test (3)
aux outils de conception et d\'implémentation de tests (A).

Cette question correspond à l’objectif FL-5.5.1 (K3) – Préparer un rapport de défaut.
● a) Faux → Utile, mais pas bloquant pour comprendre l’erreur.
● b) Correct → Sans résultat attendu, il est impossible de savoir ce qui aurait dû se produire → c’est l’élément clé manquant
● c) Faux → Peu utile dans la reproduction du défaut.
● d) Faux → Intéressant dans certains cas (web), mais pas toujours essentiel

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

Cette question correspond à l\'objectif d\'apprentissage FL-4.5.3 (K3) - Utiliser le développement piloté par les tests d\'acceptation (ATDD) pour dériver les cas de tests.

● a) Faux → Cette approche confond les tests unitaires avec les tests d\'acceptation.
Dans l\'ATDD, l\'objectif est de créer des tests d\'acceptation automatisés qui valident les comportements attendus du point de vue de l\'utilisateur, pas de décomposer le scénario en tests unitaires.

● b) Faux → Ajouter des détails techniques d\'implémentation va à l\'encontre des principes de l\'ATDD. Les tests d\'acceptation doivent se concentrer sur le comportement observable et les critères d\'acceptation métier, pas sur les détails d\'implémentation technique.

● c) Correct → Cette approche est parfaitement alignée avec les principes de l\'ATDD.

Le scénario actuel est trop vague et ne fournit pas d\'exemples concrets permettant de déterminer si l\'implémentation est correcte. En ajoutant plusieurs exemples avec des valeurs d\'entrée spécifiques (différents niveaux de revenus, scores de crédit, valeurs de propriété) et les résultats attendus correspondants (éligible/non éligible),le scénario devient beaucoup plus clair.

d) Faux → Cette réponse contredit fondamentalement la nature collaborative de l\'ATDD. Dans l\'ATDD, l\'écriture et l\'automatisation des tests d\'acceptation font partie
intégrante du processus de développement et impliquent idéalement les développeurs, les testeurs ET les parties prenantes métier. Confier cette responsabilité uniquement aux testeurs après le développement revient à abandonner l\'approche \"piloté par les tests\" de l\'ATDD.

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

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

Cette question correspond à l’objectif FL-5.4.1 (K2) – Résumer la manière dont la gestion de configuration soutient les tests.
● a) Faux → Ce n’est pas un rôle de la configuration mais de la stratégie de test.
● b) Correct → Le cœur de la gestion de configuration, c’est le suivi des versions, des liens entre livrables et des artefacts.
● c) Faux → Ce n’est ni toujours souhaitable, ni une responsabilité de la configuration.
● d) Faux → Les spécifications sont sous contrôle de gestion produit.

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.

Chiffrement WPA3 : La dernière norme de sécurité Wi-Fi offrant un chiffrement robuste et une protection contre les attaques par force brute grâce à l'authentification simultanée des pairs (SAE). Contrairement au WEP (obsolète et compromis), aux SSID masqués (sécurité par l'obscurité) ou au filtrage par adresse MAC (facilement contournable par usurpation), le WPA3 propose une authentification cryptographique solide répondant aux exigences de sécurité modernes.

L'exercice sur table (Tabletop Exercise) : une simulation structurée basée sur la discussion, au cours de laquelle les membres de l'équipe passent en revue les procédures de réponse aux incidents sans les exécuter réellement. Cette méthode rentable améliore la réponse aux incidents en identifiant les lacunes, en clarifiant les rôles et en testant les plans de communication. Contrairement au basculement (Failover, commutation de systèmes) et à la reprise (Recovery, restauration), l'exercice sur table se concentre sur la planification et la préparation plutôt que sur la mise en œuvre technique.

Moindre privilège : Les utilisateurs ne doivent disposer que des droits d'accès minimaux nécessaires à leur fonction. Lorsque des utilisateurs accèdent à des ressources non autorisées, cela indique que des permissions excessives ont été accordées, ce qui constitue une violation directe de ce principe. Contrairement à la séparation des tâches (répartition des responsabilités entre plusieurs personnes) ou à la défense en profondeur (sécurité par couches), le moindre privilège contrôle les niveaux d'accès individuels.

Cheval de Troie : un logiciel malveillant déguisé en logiciel légitime que les utilisateurs installent volontairement, croyant qu'il remplit une fonction inoffensive. Contrairement aux vers (auto-réplication) ou aux virus (attachés à des fichiers), les chevaux de Troie nécessitent une interaction de l'utilisateur et ne se propagent pas de manière autonome. Les logiciels espions se concentrent sur le vol de données plutôt que sur la tromperie lors de l'installation.

Pour sécuriser des zones sensibles, il faut des contrôles physiques (portes, badges, gardes), qui empêchent l'accès physique direct.

Réponse : Un employé reçoit une demande de carte-cadeau par e-mail avec le nom d'un dirigeant affiché dans le champ d'affichage.
Explication : Les attaques de type BEC (Business Email Compromise) usurpent l'identité de dirigeants en falsifiant le nom affiché (tout en utilisant une adresse e-mail réelle différente) pour inciter les employés à effectuer des transactions financières, comme l'achat de cartes-cadeaux.

Le contrôle d'accès obligatoire (MAC) est le modèle le plus restrictif — une autorité centrale (administrateur système, responsable de la sécurité) attribue des étiquettes de sensibilité aux sujets (utilisateurs) et aux objets (fichiers). L'accès n'est accordé que lorsque le niveau d'habilitation du sujet est égal ou supérieur à la classification de l'objet (par exemple, un utilisateur avec une habilitation « Secret » peut accéder aux fichiers « Secret » et « Non classifié », mais pas aux fichiers « Très Secret »). Le DAC laisse les propriétaires décider qui accède à leurs ressources. Le RBAC attribue les permissions en fonction des rôles professionnels. L'ABAC utilise des attributs et des politiques.

Réponse : Le client.
Explication : Dans un modèle cloud IaaS, le client est responsable de la sécurisation de tout ce qui se trouve au-dessus de l'hyperviseur : le système d'exploitation, les logiciels de base de données, l'application, les données et les contrôles d'accès. Le fournisseur cloud sécurise l'infrastructure physique et l'hyperviseur.

Réponse correcte : Le principe du moindre privilège (Least Privilege) signifie accorder aux utilisateurs uniquement les permissions minimales nécessaires pour accomplir leurs fonctions professionnelles, réduisant ainsi la surface d'attaque et limitant les dégâts en cas de compromission de compte.

Pourquoi les autres réponses sont incorrectes : Accorder tous les droits d'accès d'abord puis les retirer est inefficace et dangereux. Partager des comptes privilégiés entre plusieurs administrateurs viole la responsabilité individuelle et la traçabilité. Utiliser des comptes administrateur pour les activités quotidiennes expose l'organisation à des risques de sécurité majeurs en cas de malveillance ou d'erreur.

Moindre Privilège : Un principe de sécurité fondamental limitant l'accès des utilisateurs aux seules ressources et permissions minimales nécessaires à l'exercice de leurs fonctions. Cela réduit la surface d'attaque et les dommages causés par des comptes compromis. Contrairement au principe du « besoin d'en connaître » (classification de l'information), le moindre privilège s'applique aux droits d'accès aux systèmes. Contrairement à la « séparation des tâches » (prévention de la fraude par la division des rôles) ou à la « rotation des postes » (réduction des menaces internes), le moindre privilège se concentre sur un contrôle d'accès granulaire.

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

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

Réponses : read-access geo-redundant storage (RA-GRS) et geo-redundant storage (GRS). Explication : GRS et RA-GRS répliquent tous deux les données vers une région secondaire en dehors de la région Azure primaire, satisfaisant ainsi à l'exigence de réplication automatique inter-régions. LRS et ZRS répliquent uniquement au sein d'une même région. RA-GRS ajoute l'accès en lecture à la région secondaire.

Un Data Lake stocke toutes les données brutes d'une organisation dans leur format natif (structuré, semi-structuré, non structuré) avant traitement. Azure Data Lake Storage Gen2 (ADLS Gen2) est construit sur Azure Blob Storage avec des fonctionnalités supplémentaires : système de fichiers hiérarchique (dossiers et sous-dossiers natifs), contrôle d'accès POSIX granulaire (ACLs par fichier/dossier), et performances optimisées pour les analytics massifs avec Spark, Hadoop, Azure Synapse. La différence clé : ADLS Gen2 supporte les opérations de répertoire atomiques manquantes dans Blob Storage.

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

Charges analytiques (OLAP) : systèmes conçus pour analyser de grands volumes de données historiques et produire des rapports complexes. Contrairement aux charges transactionnelles (OLTP) qui traitent chaque transaction individuellement, l'OLAP agrège et synthétise les données pour déceler des tendances et patterns. Les distracteurs confondent OLTP (enregistrement de transactions) avec OLAP (analyse rétrospective).

La clause WHERE : filtre les lignes d'une table selon des conditions spécifiques AVANT le regroupement. Elle s'applique aux enregistrements individuels. À ne pas confondre avec HAVING (filtre après regroupement), ORDER BY (tri des résultats) ou GROUP BY (agrégation de données).

Power BI : plateforme Microsoft dédiée à la business intelligence, permettant de transformer des données brutes en visualisations interactives et tableaux de bord partageables. Contrairement à Excel (outil bureautique) ou Azure Monitor (surveillance d'infrastructure), Power BI excelle dans l'analyse métier et la décision data-driven en temps réel.

Réponse : az storage account create. Explication : Le stockage de table Azure fait partie des comptes de stockage Azure. Pour utiliser le stockage de table, vous devez d'abord créer un compte de stockage Azure à l'aide de la commande Azure CLI « az storage account create », puis créer la table dans ce compte.

API Gremlin et modèle graphe : Gremlin est un langage de requête standardisé pour naviguer dans les bases de données graphes. Cosmos DB utilise ce modèle pour stocker des données sous forme de nœuds (entités) et d'arêtes (relations) entre eux, idéal pour représenter des réseaux complexes. Contrairement au modèle relationnel (tables), au modèle clé-valeur (paires simples) ou au modèle orienté colonnes (analytique), le graphe excelle pour explorer les connexions et chemins entre données interconnectées.

Réponse : Le solde résiduel clôt l'original et crée un nouvel open item
En AR/AP SAP :

• Paiement partiel : conserve le document original ouvert, crée un paiement partiel séparé. Les deux restent ouverts.
• Solde résiduel : clôt le document original et crée un nouvel open item pour la différence. Une seule écriture ouverte subsiste.

Ordre correct clôture mensuelle FI :

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

Le programme de relance (Dunning) identifie automatiquement les postes clients en retard de paiement et génère des lettres de relance graduées (niveau 1 = rappel poli, niveau 4 = mise en demeure avant action légale). Le principal paramètre est le niveau de relance (Dunning Level), qui détermine la sévérité du message selon le nombre de jours de retard dépassé. La procédure de relance (Dunning Procedure) définit également les intervalles entre relances, les frais applicables et les intérêts de retard. Elle est exécutée via F150 ou l'app Fiori équivalente.

Ordre correct :

1. Définir zone/méthode de valorisation
2. Sélectionner les postes ouverts en devises étrangères
3. Calculer les écarts de change non réalisés
4. Comptabiliser les ajustements (débit/crédit écart de change)

La valorisation de fin de période garantit que les postes ouverts en devises étrangères reflètent le cours de change à la date de clôture.

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

L'amortissement ordinaire (planned depreciation) est calculé automatiquement selon la clé d'amortissement, la durée de vie utile et la valeur d'acquisition de l'actif — il suit un plan prédéfini (mensuel, annuel). L'amortissement non planifié (unplanned depreciation) est saisi manuellement pour des dépréciations exceptionnelles : détérioration soudaine, obsolescence technologique, sinistre. Il est comptabilisé via la transaction ABAA ou l'app Fiori équivalente. Ces deux types se cumulent dans le calcul de la valeur nette comptable.

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

FB60 (ou son équivalent Fiori) permet la saisie directe d'une facture fournisseur en FI-AP sans lien avec le processus d'achat (MM). Elle génère une écriture débitant le compte de charge et créditant le compte collectif fournisseur. En revanche, MIRO est utilisée pour les factures avec référence bon de commande (flux MM-FI). FB65 est pour les avoirs fournisseurs sans BDC. F-43 est l'ancienne transaction de saisie manuelle. Dans S/4HANA, les apps Fiori remplacent progressivement ces transactions.

Réponse : FBZP
La transaction FBZP (Maintain Payment Program Configuration) est l'interface centrale de configuration du programme de paiement automatique. Elle permet de définir les sociétés, les méthodes de paiement, les banques payantes, les délais de valeur et les déductions d'escompte.

Réponse : F-53
La transaction F-53 (Post Outgoing Payments) permet d'enregistrer un paiement sortant manuel fournisseur et de lettrer le paiement avec les factures ouvertes correspondantes. Elle est utilisée pour les paiements individuels manuels, par opposition au run automatique F110.

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.

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

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

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

Réponse : La gestion des 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 : 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 : 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.

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 : Les centres de services doivent comprendre l\'organisation dans son ensemble.
Explication : Les centres de services doivent avoir une compréhension globale de l\'organisation pour orienter correctement les utilisateurs, comprendre les impacts des incidents et prioriser les demandes.

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

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

• Les labels de sensibilité doivent être publiés via une stratégie de labels et les utilisateurs doivent être inclus dans la portée pour que les labels apparaissent dans Office Online.

• Si la stratégie n’inclut pas PowerPoint Online ou si l’utilisateur n’est pas dans la portée, les labels n’apparaîtront pas.

• Les autres options ne sont pas pertinentes pour PowerPoint Online :

  • B : Azure RMS connector concerne les scénarios hybrides et on-premises.

  • C : La synchronisation des apps Purview sur le poste local n’affecte pas Office Online.

  • D : Le client AIP Unified Labeling est pour les applications desktop, pas pour Office Online.

Le Service Health Dashboard dans le centre d’administration Microsoft 365 permet :

• De consulter l’état actuel des services (Exchange, SharePoint, Teams, etc.)

• De voir les incidents en cours

• D’obtenir des mises à jour en temps réel

• De recevoir des avis et recommandations

Il aide les administrateurs à comprendre si un problème vient de Microsoft ou de leur propre environnement.

❌ Pourquoi les autres réponses sont incorrectes :

• A. Configurer des SLA personnalisés → Impossible. Les SLA sont définis par Microsoft.

• C. Correction automatique des incidents → Le dashboard informe, mais ne corrige pas automatiquement.

• D. Rapports mensuels détaillés de conformité SLA → Ce n’est pas sa fonction principale. Il montre l’état des services, pas des rapports analytiques mensuels complets.

  🎯 À retenir pour l’examen MS-900 :

  • Service Health Dashboard = visibilité en temps réel sur l’état des services Microsoft 365

  • Il informe, mais ne configure pas de SLA ni ne corrige automatiquement les incidents.

Windows Autopatch est un service Microsoft qui automatise les mises à jour de Windows, Microsoft 365 Apps, Edge et Teams. Il requiert obligatoirement une licence Windows 10/11 Enterprise E3 ou E5 — incluse dans Microsoft 365 E3/E5 ou disponible séparément via Windows Enterprise E3/E5.

Microsoft 365 Business Premium ne contient pas de licence Windows Enterprise et ne donne pas accès à Autopatch. Intune seul permet la gestion des appareils mais n'active pas Autopatch. Windows Pro avec EMS E3 est insuffisant car Autopatch exige la version Enterprise, pas Pro.

L’application mobile OneDrive permet :

• D’accéder aux fichiers sur tablette et smartphone

• De rendre certains fichiers ou dossiers disponibles hors ligne

• De minimiser le stockage local, car seuls les fichiers sélectionnés sont téléchargés pour un accès hors ligne, le reste reste dans le cloud.

  🎯 À retenir pour l’examen MS-900 :

  • OneDrive mobile app + disponibilité hors ligne = accès aux fichiers sur appareils mobiles même sans connexion, avec stockage local limité.

  • Les autres solutions (navigateur, WebDAV, laptop) ne répondent pas au besoin mobile hors ligne.

• Le bloc-notes est stocké dans un site SharePoint d’équipe.

• L’URL correcte doit donc pointer vers :

  • Le tenant SharePoint principal (contoso.sharepoint.com)

  • Le site d’équipe (/sites/ProjectTeam)

  • Le dossier du bloc-notes

L’option B correspond à une URL SharePoint classique permettant :

• L’ouverture dans OneNote Desktop

• La synchronisation automatique

• Les mises à jour en temps réel pour tous les membres

❌ Pourquoi les autres réponses sont incorrectes :

• A et C → Utilisent contoso-my.sharepoint.com, qui correspond à OneDrive personnel, pas à un site SharePoint d’équipe.

• D → URL interne SharePoint (_layouts) utilisée pour l’interface web, pas pour un accès direct propre au bloc-notes.

🎯 À retenir pour l’examen MS-900 :

• tenant.sharepoint.com/sites/... = site d’équipe SharePoint

• tenant-my.sharepoint.com = OneDrive personnel

• Pour collaboration d’équipe → toujours utiliser l’URL du site SharePoint

• Dans Microsoft Stream, on peut contrôler :

  • Qui peut regarder une vidéo (exiger l’authentification)

  • Si la vidéo peut être téléchargée (désactiver le téléchargement)

• Cette configuration garantit que seuls les employés authentifiés peuvent accéder au contenu et qu’aucun téléchargement n’est possible.

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

  • A : OneDrive sync ne concerne pas Stream.

  • B : Désactiver l’accès invité protège l’ensemble du tenant, mais ne gère pas les vidéos internes.

  • D : Une politique de rétention supprime des vidéos, ne contrôle pas l’accès ou le téléchargement.

• Dans un environnement hybride, vous continuez à utiliser votre infrastructure locale (CapEx) pour certains services ou serveurs AD.

• En parallèle, vous payez des abonnements cloud Azure AD Premium et éventuellement des services de synchronisation de données, ce qui constitue des dépenses d’exploitation (OpEx).

• Les autres options sont incorrectes :

  • A : Faux, le CapEx sur site reste nécessaire.

  • B : Faux, ce n’est pas un double paiement intégral.

  • C : Faux, l’utilisation d’Azure AD introduit bien des coûts OpEx.

Le programme Cloud Solution Provider (CSP) permet aux organisations :

• D’acheter des licences Microsoft 365 via un partenaire Microsoft, qui gère la facturation et le support.

• De modifier le nombre de licences chaque mois (ajouter ou supprimer des utilisateurs) sans engagement annuel rigide.

• De bénéficier d’un accompagnement personnalisé via le partenaire.

• Intune device compliance policies permettent de s’assurer que seuls les appareils conformes (sécurisés, à jour, chiffrés) peuvent accéder aux données.

• Azure AD Conditional Access applique des règles basées sur l’identité et l’état de l’appareil pour contrôler l’accès aux services Microsoft 365.

• Ensemble, ces fonctionnalités assurent un accès sécurisé aux dossiers patients tout en respectant les normes de conformité.

Les autres options ne couvrent pas à la fois sécurité des appareils et contrôle d’accès :

• B : Azure Information Protection protège les fichiers mais ne contrôle pas l’accès en fonction de l’appareil.

• C : Stream et SharePoint versioning gèrent le contenu mais pas la sécurité des accès.

• D : DLP et Teams Shifts protègent certains contenus ou planifications, pas l’accès sécurisé aux dossiers patients.

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

• Il permet de :

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

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

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

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

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

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

Pour assurer la conformité de toutes les ressources Azure avec le CIS Benchmark :

• Azure Policy permet de définir et appliquer des règles sur les ressources Azure.

• Une initiative (initiative definition) regroupe plusieurs policies liées à un objectif, ici : le CIS Benchmark.

• Déployer cette initiative au niveau du Management Group :

  • Assure que toutes les souscriptions enfants héritent des règles

  • Centralise la gouvernance

• Cette approche est scalable et alignée avec les Azure Landing Zones et le Cloud Adoption Framework (CAF).

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

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

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

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

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

• 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

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.

• Microsoft Intune Device Compliance Policies permet de :

  • Appliquer le chiffrement FileVault sur macOS

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

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

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

• Mailbox Intelligence : analyse le comportement des utilisateurs pour identifier des emails suspects envoyés ou reçus

• Spoof Intelligence : détecte les tentatives d’usurpation d’identité (spoofing), notamment des domaines ou adresses similaires aux comptes internes

• Ensemble, ils permettent à Defender for Office 365 de :

  • Bloquer ou marquer les emails imitant des comptes internes ou exécutifs

  • Réduire les risques d’account takeover via phishing ciblé

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

• Intune + Conditional Access permet :

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

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

    • BitLocker activé

    • Antivirus à jour

    • Correctifs appliqués

  • Bloquer l’accès depuis appareils non conformes

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

• 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

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

Dans GCP, un même VPC peut avoir des sous-réseaux dans plusieurs régions. Les instances du même VPC peuvent communiquer directement via IPs privées sans VPN ni peering. C'est la solution la plus simple et recommandée.

La commande gcloud projects get-iam-policy retourne toutes les attributions de rôles IAM du projet, incluant qui a le rôle Project Owner. C'est la méthode la plus directe — aucune configuration préalable nécessaire.

Les uploads composites parallèles (parallel composite uploads) de gsutil divisent le fichier en morceaux et les uploadent simultanément, saturant ainsi la bande passante disponible. Avec 1 Gbps dédié, c'est la méthode la plus rapide pour un gros fichier.

Pour utiliser un SSO externe (IdP tiers) avec Cloud Identity, il faut configurer Cloud Identity comme fournisseur de services (SP) et votre SSO d'entreprise comme fournisseur d'identité (IdP) tiers. C'est l'intégration SAML standard.

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.

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

La séquence correcte est : obtenir l'ID du projet avec gcloud projects list, puis lister les services activés avec gcloud services list --project. --available liste toutes les APIs disponibles (pas seulement les activées).

Sur une VM CE, Application Default Credentials (ADC) utilise automatiquement le compte de service attaché à la VM. En attribuant les bonnes permissions au compte de service de la VM, l'application fonctionne sans modification de code ni gestion de fichiers de clés.

Accorder le rôle Storage Object Creator directement au compte de service de la VM sur le bucket cible (corp-aggregate-reports-storage) est la méthode la plus simple. La VM peut alors écrire dans ce bucket cross-projet sans configuration réseau supplémentaire.

L'ordre correct est : 1) Créer le projet avec gcloud, 2) Activer l'API CE dans ce projet, 3) Créer l'instance. Le flag --project ne crée pas un projet automatiquement, et gcloud ne peut pas activer l'API CE d'un projet inexistant à la volée.

Correct : Option 6 (Toutes les réponses ci-dessus) - L'ouverture, une valeur fondamentale de Scrum, imprègne l'ensemble du cadre de travail : elle améliore la collaboration, favorise des discussions de qualité, accroît l'engagement, accélère les boucles de rétroaction qui influencent le délai de mise sur le marché, et renforce la confiance des parties prenantes. Chaque élément repose sur une communication transparente et honnête que l'ouverture rend possible.

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

Réponses correctes : Options 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.

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

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

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

L'option B est correcte. Le Scrum Master doit accompagner le Product Owner en lui expliquant que l'empirisme et l'émergence sont au cœur de Scrum ; la complexité rend toute prévision parfaite impossible. Les nouveaux apprentissages réalisés durant le Sprint affectent naturellement le Sprint Backlog. L'option A démotive l'équipe par une pression irréaliste, l'option C est défensive et ignore les préoccupations des parties prenantes, et l'option D enfreint le principe selon lequel l'ajout de personnes en cours de Sprint réduit la productivité et ne résout pas les problèmes de fond.

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

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.

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 : 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 : 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 : Pourcentage des exigences métier exercées.
Explication : La mesure la plus appropriée de couverture de test pour un rapport de progression métier hebdomadaire est le pourcentage des exigences métier exercées. Cette métrique s\'aligne directement avec les priorités métier : valider que le logiciel remplit son objectif et fournit une valeur tangible aux parties prenantes.

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

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

Réponse : Le pourcentage de couverture de décision atteint durant les tests unitaires. / La disponibilité de la dernière version de l\'outil d\'enregistrement-rejoue (pour tester l\'interface avec le nouvel outil de gestion des tests)..
Explication : Les critères d\'entrée sont des conditions préalables concrètes et vérifiables avant l\'exécution. La couverture de décision des tests unitaires (A) et la disponibilité des outils requis (B) sont des critères d\'entrée classiques, mesurables et directs pour l\'intégration.

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

Réponse : Qualité d\'entrée inconnue due au développement par un tiers.
Explication : D est correct car la qualité d\'entrée inconnue provenant du développement par un tiers crée le plus grand risque d\'estimateur : variance élevée des taux de défauts, comportements d\'intégration imprévisibles et efforts de vérification imprévisibles qui gonflent directement les estimations de temps et ressources. Les hypothèses quantifiées deviennent invalides avec les entrées tierces.

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

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

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

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

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

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