5 questions piège de l'examen GH-SEC et comment les éviter
Tous les examens GH-SEC (GitHub (Microsoft)) contiennent des questions piège spécifiquement conçues pour faire échouer les candidats mal préparés. Cet article décortique 5 questions piège réelles tirées de notre banque, explique pourquoi ce sont des pièges, l'erreur typique commise par les candidats, et la bonne approche pour les éviter. Lisez-le attentivement avant votre examen.
5
Questions analysées
60
Banque totale
5
Catégories de pièges
Intermédiaire
Niveau examen
Les catégories de pièges typiques de GH-SEC
Avant de plonger dans les questions, comprenons d'abord quels types de pièges sont récurrents dans l'examen GH-SEC. Connaître les patterns vous permet de les détecter en temps réel pendant l'examen.
Les confusions de concepts proches
Authentification ≠ Autorisation. Chiffrement ≠ Hachage. Risque ≠ Menace ≠ Vulnérabilité. RTO ≠ RPO. BCP ≠ DRP. Ces concepts proches sont la matière première des questions piège. Une lecture rapide vous fera mélanger.
Les attaques aux noms similaires
DDoS / DoS, MITM / Replay, XSS / CSRF / SSRF, SQLi / NoSQLi / Command injection. Les questions présentent un scénario d'attaque et vous demandent le type exact, pas le type voisin.
Les frameworks et leurs phases
NIST CSF (Identify, Protect, Detect, Respond, Recover), Cyber Kill Chain, MITRE ATT&CK, ISO 27001. Les questions vous demandent dans quelle phase se passe une action précise. Apprenez chaque phase et ses étapes.
Les contrôles préventifs / détectifs / correctifs
Un IDS est détectif, un IPS préventif, un backup correctif, une formation préventive. Les questions présentent une mesure et vous demandent sa catégorie. Erreur fréquente : considérer un firewall comme uniquement préventif (il a aussi un volet détectif via les logs).
Le scope du chiffrement
Données au repos ≠ données en transit ≠ données en cours d'utilisation. Une question scénarisée vous demande quel mécanisme utiliser : TLS pour transit, AES-256 pour repos, enclaves (TEE/Confidential Computing) pour utilisation.
Les 5 questions piège analysées
Voici 5 questions tirées aléatoirement de notre banque GH-SEC, particulièrement représentatives des pièges qu'on retrouve à l'examen. Chacune est analysée selon le même schéma : pourquoi c'est un piège, l'erreur typique, la bonne approche.
Question piège 1
Vous gerez un projet Maven multi-modules ou Dependabot ouvre regulierement des PR de mise a jour qui echouent au build car certaines dependances internes au groupId com.acme.internal ne doivent jamais etre mises a jour automatiquement (elles suivent un cycle de release manuel). Quelle directive ajouter dans .github/dependabot.yml ?
Pourquoi c'est un piège
Cette question est piégeuse parce qu'elle contient une contrainte implicite que beaucoup de candidats lisent trop vite. Plusieurs réponses semblent fonctionner techniquement, mais une seule respecte l'ensemble des contraintes (coût, sécurité, contexte). C'est typique des questions scénarisées de l'examen GH-SEC où le contexte d'entreprise change la bonne réponse.
L'erreur typique
L'erreur typique consiste à choisir la première réponse qui semble correcte techniquement, sans vérifier qu'elle respecte la contrainte principale du scénario. Beaucoup éliminent à tort une bonne réponse parce qu'elle parait « trop simple ». La règle : la solution la plus adaptée au scénario gagne, pas la plus impressionnante.
La bonne approche et le raisonnement
La bonne approche est de lire deux fois la question en surlignant les mots-clés (contraintes, exigences). Identifier ensuite parmi les 4 réponses celle qui adresse la contrainte principale. Si deux réponses semblent valides, choisir celle qui adresse aussi les contraintes secondaires (sécurité, coût, simplicité opérationnelle). En cas de doute, privilégier le « best practice » officiel GitHub (Microsoft).
Dans une requete CodeQL personnalisee pour Code Scanning, vous voulez que les alertes apparaissent avec une severite 'error' et soient classees comme probleme de securite. Quelles metadonnees devez-vous obligatoirement inclure en commentaire QLDoc en tete du fichier .ql ?
Pourquoi c'est un piège
Cette question est piégeuse parce qu'elle utilise un vocabulaire technique très proche entre les options proposées. Les 4 réponses partagent les mêmes termes-clés mais dans des combinaisons différentes. Sans connaître précisément chaque concept et sa nuance, on choisit par intuition — ce qui mène souvent à la mauvaise réponse.
L'erreur typique
L'erreur classique est de se laisser guider par un mot-clé évident dans la question (par exemple « sécurité » qui pousse vers la réponse contenant « sécurité »). Les concepteurs de l'examen le savent et placent volontairement un mot-clé qui oriente vers une mauvaise réponse. Toujours vérifier que la logique complète de la réponse correspond, pas juste un mot-clé.
La bonne approche et le raisonnement
Pour répondre correctement, il faut maîtriser la définition exacte de chaque concept. Construisez une fiche mémo avec chaque acronyme/concept de GH-SEC et sa différence avec ses « voisins ». Avant de répondre, demandez-vous : « Est-ce que cette réponse couvre exactement ce que demande la question, ni plus ni moins ? »
Un administrateur GitHub Enterprise Cloud constate que la facturation GHAS depasse les previsions. Il souhaite identifier comment sont comptabilisees les licences GHAS pour optimiser les couts. Quelle affirmation est exacte concernant la facturation des licences GHAS ?
Pourquoi c'est un piège
Cette question est un piège parce qu'elle présente un cas réel d'entreprise et demande la « meilleure » solution. Toutes les options fonctionneraient en théorie, mais une seule respecte les bonnes pratiques de GitHub (Microsoft) pour ce cas précis. C'est exactement le type de question qui distingue les candidats préparés de ceux qui révisent uniquement la théorie.
L'erreur typique
L'erreur typique est de choisir la solution la plus familière au candidat (celle qu'il a déjà utilisée en projet), au lieu de la solution recommandée officiellement par GitHub (Microsoft) pour ce scénario. Votre expérience perso peut vous tromper : l'examen GH-SEC teste votre connaissance des recommandations officielles, pas vos préférences personnelles.
La bonne approche et le raisonnement
Avant de répondre, posez-vous trois questions : (1) Quelle est la contrainte numéro 1 du scénario ? (2) Quelle solution GitHub (Microsoft) recommande-t-elle officiellement pour ce type de cas ? (3) Y a-t-il une option qui combine performance, sécurité et simplicité opérationnelle ? La réponse qui répond « oui » aux trois est généralement la bonne.
Vous configurez le streaming des audit logs vers AWS S3 pour la conformite HIPAA. Quelle configuration est REQUISE pour garantir l'integrite des logs exportes ?
Pourquoi c'est un piège
Cette question est piégeuse parce qu'elle contient une négation ou une condition d'exclusion (« lequel n'est PAS… », « sauf… », « à l'exception de… »). Sous le stress, le cerveau lit la phrase comme si la négation n'existait pas et choisit la réponse qui correspondrait à la version affirmative. Résultat : la réponse exactement opposée à la bonne.
L'erreur typique
L'erreur typique est de répondre vite, sans avoir relu la question. Le candidat coche la première réponse qui « fait sens » dans le sujet, sans vérifier si la question demande l'inclusion ou l'exclusion. C'est l'une des erreurs les plus fréquentes de l'examen GH-SEC et la plus facile à éviter avec une lecture attentive.
La bonne approche et le raisonnement
La méthode : reformulez la question dans votre tête avant de lire les réponses. Par exemple, « Lequel n'est PAS un service Compute Azure ? » devient « Trouvez la réponse qui n'est PAS dans la liste des services Compute Azure ». Soulignez mentalement la négation. Vérifiez ensuite chaque réponse contre la définition exacte.
Dans un workflow GitHub Actions utilisant l'action github/codeql-action/init@v3, quelle configuration permet d'activer la suite de requêtes étendue tout en excluant un dossier de tests ?
Pourquoi c'est un piège
Cette question est piégeuse parce qu'elle présente une situation où plusieurs réponses sont correctes mais une seule est la « meilleure ». Les examens GitHub (Microsoft) aiment ce format car il teste la capacité du candidat à hiérarchiser les solutions selon des critères précis (coût, sécurité, performance, simplicité).
L'erreur typique
L'erreur typique est de s'arrêter à la première réponse qui semble correcte, sans lire les 3 autres. Or, parmi les 4, deux ou trois peuvent fonctionner. La bonne réponse est celle qui combine le plus de critères favorables. Toujours lire les 4 réponses en entier avant de choisir.
La bonne approche et le raisonnement
Pour répondre correctement, créez une matrice mentale : pour chaque réponse, notez si elle adresse coût, sécurité, performance et simplicité. La réponse qui coche le maximum de cases est la bonne. En cas d'égalité, privilégiez la réponse qui adresse la contrainte explicite du scénario (« cost-effective », « high availability », etc.).
5 règles d'or pour ne plus tomber dans les pièges GH-SEC
Au-delà des questions analysées ci-dessus, voici 5 règles d'or à appliquer systématiquement pendant l'examen pour éviter les pièges les plus courants. Ces règles sont issues du retour d'expérience de centaines de candidats certifiés.
Règle 1 — Lisez la question deux fois, surtout les mots de négation. « PAS », « EXCEPT », « SAUF », « JAMAIS » inversent complètement la bonne réponse. Une lecture rapide vous fera choisir la réponse exactement opposée à celle attendue. Prenez 5 secondes de plus pour relire ces mots-clés.
Règle 2 — Lisez les 4 réponses en entier avant de cocher. Plusieurs réponses peuvent être partiellement correctes. La bonne est celle qui adresse toutes les contraintes du scénario, pas seulement la première qui semble plausible. Vous gagnerez 5 points en moyenne juste avec cette règle.
Règle 3 — Identifiez la contrainte numéro 1 du scénario. Chaque question scénarisée contient une contrainte dominante : coût, sécurité, performance, simplicité, conformité. Cette contrainte définit la bonne réponse. Si vous l'identifiez, 50 % du travail est fait.
Règle 4 — En cas de doute, privilégiez les recommandations officielles GitHub (Microsoft). L'examen teste votre connaissance des « best practices » officielles, pas vos préférences personnelles. Une solution exotique mais fonctionnelle perdra face à la solution recommandée officiellement.
Règle 5 — Faites confiance à votre première intuition. Les statistiques montrent que changer sa réponse en relecture fait perdre des points dans 60 % des cas. Ne revenez sur une question que si vous avez identifié une erreur factuelle claire, pas un simple doute.
L'astuce qui fait la différence : entraînez-vous à repérer le type de piège dès la lecture de la question. Avec la pratique, vous identifiez en 5 secondes si la question est un piège « négation », « best answer », « concept proche » ou « contrainte cachée ». Cette identification rapide vous fait gagner du temps et améliore drastiquement votre score.
Continuez votre préparation GH-SEC
Détecter les pièges est une compétence qui se travaille. Plus vous passez de questions, plus votre intuition s'affine. Voici les ressources complémentaires pour aller plus loin sur GH-SEC :