Comment passer l'examen blanc PSD-I ?

Cliquez sur le bouton « Commencer l'examen » sur cette page pour accéder à l'examen blanc PSD-I en ligne, gratuitement, avec correction immédiate à la fin.

Quel est le seuil de réussite ?

Le seuil de réussite varie selon la certification officielle.

Puis-je refaire l'examen plusieurs fois ?

Oui, autant de fois que vous le souhaitez.

Les corrections sont-elles fournies ?

Oui, chaque réponse est expliquée en détail.

Examen PSD-I — PSD-I — Professional Scrum Developer I (PSD I) | Questions d'entraînement

À propos de l'examen PSD-I

L'examen PSD-I — PSD-I — Professional Scrum Developer I (PSD I) — est proposé par Scrum.org et fait partie des certifications IT les plus reconnues au niveau international. Cette épreuve évalue vos compétences pratiques et théoriques dans le domaine de professional scrum developer i (psd i). L'entraînement Certifexpress comprend 40 questions au format officiel pour une durée de 80 minutes. Sur cette page, découvrez 5 exemples de questions représentatives pour évaluer votre niveau avant de commencer l'entraînement complet.

Comment se préparer à l'examen PSD-I ?

Révisez les concepts clés couverts dans le guide officiel de l'examen PSD-I.

Entraînez-vous régulièrement avec des questions au format réel pour vous familiariser avec la structure de l'épreuve.

Identifiez vos points faibles grâce aux explications détaillées fournies après chaque réponse.

Gérez votre temps : simulez les conditions réelles de l'examen en vous chronométrant.

Rejoignez la communauté Certifexpress pour partager vos retours d'expérience avec d'autres candidats.

5 exemples de questions — PSD-I

Ces questions sont extraites aléatoirement de la banque de questions officielle. Les réponses correctes ne sont pas indiquées ici — elles sont révélées lors de l'examen complet.

Qu'est-ce qu'un 'feature flag' (ou 'feature toggle') et pourquoi est-ce essentiel pour le continuous deployment haute fréquence ?

A Variable de configuration qui active/désactive une feature en runtime sans redéployer. Découple le déploiement de la release : ship + hide + rollout progressif. B Configuration au temps de compilation pour créer des builds différentes selon le profil (debug vs production). Réduit la taille des déploiements. C Système de permissions granulaires qui contrôle qui peut accéder à quelles features. Active/désactive par utilisateur ou groupe. D Mécanisme de versioning des features : chaque feature a une version, et les clients ne reçoivent que les versions compatibles à leur build.

Un développeur demande comment implémenter un feature toggle pour une nouvelle logique métier en production sans risque. L'équipe pratique le continuous deployment. Quelle approche minimise le risque ?

A Déployer le code avec le toggle OFF par défaut, tester le chemin inactif en production via des outils de monitoring, activer progressivement. B Utiliser une branche feature isolée, merger dans main que si tous les tests passent, deployer immédiatement avec le toggle actif. C Maintenir deux versions de la logique en production (ancien + nouveau) et switcher le toggle uniquement après 1 mois de validation QA. D Créer une release candidate dans une staging identique à prod, tester le toggle là, puis déployer en prod sans monitoring supplémentaire.

Une équipe constate que les bugs reportés en prod ne remontent jamais aux sprints suivants car 'c'est urgent'. L'équipe corrige ad-hoc sans tests. Comment stabiliser ce pattern ?

A Définir un SLA de bug (critique : 24h, majeur : 1 sprint) avec tests obligatoires à chaque fix. Tracker les bugs comme stories dans le backlog. B Créer une équipe support dédiée pour tracker et fixer les bugs, libérant l'équipe de dev du backlog métier stratégique. C Augmenter la couverture des tests en prod (canary, A/B testing) pour détecter les bugs avant qu'ils ne soient reportés par les utilisateurs. D Instaurer une période de 'stabilisation' après chaque release de 3-5 jours où seuls les bugs peuvent être addressé avant le prochain sprint.

Pourquoi le pattern 'Dependency Injection' est-il préféré à 'Service Locator' dans une architecturedéveloppement pilotée par les tests ?

A DI expose les dépendances explicitement au constructeur/setter, rendant testable par substitution simple. Service Locator cache les dépendances. B DI est plus performant car il résout les dépendances une fois au startup. Service Locator fait des lookups répétés et lents. C Service Locator est trop vieux et deprecated ; DI est la norme moderne même si les deux accomplissent la même chose techniquement. D DI force une hiérarchie de modules, tandis que Service Locator permet une graph arbitraire, donc DI est plus flexible pour les tests.

Qu'est-ce que l'inversion de dépendances et pourquoi est-ce crucial pour la testabilité d'une architecture en couches (présentation, métier, persistence) ?

A Abstraire les dépendances via des interfaces : les couches hautes dépendent d'interfaces, pas de l'implémentation concrète, permettant l'injection de mocks. B Placer toutes les dépendances dans une couche centrale d'injection, et faire que chaque module importe de cette couche centrale. C Reverser l'ordre des dépendances : faire que persistence appelle métier qui appelle présentation pour qu'aucune couche ne dépende des autres. D Utiliser un conteneur d'injection de dépendances qui automatiquement remplace les dépendances réelles par des mocks durant les tests.

Encore 35 questions dans l'examen complet

Accédez à toutes les questions avec corrections détaillées et explications officielles.

Commencer l'examen — Gratuit

✓ Sans inscription obligatoire · Correction immédiate

📖 Préparez-vous avec nos guides

Salaires & Certifications IT 2026

Commencer l'examen PSD-I complet

40 questions au format officiel, corrections détaillées, suivi de votre progression. Gratuit, sans CB.

Commencer l'examen complet →