EnglishDeutschFrançaisEspañolPortuguês

Google Cloud · GCP-PSOE · Advanced

Professional Security Operations Engineer — Questions d'entraînement et examen blanc

Entraîne-toi avec des questions GCP-PSOE réalistes, alignées sur les objectifs de l’examen. Alex explique chaque réponse et ton score de préparation te montre quoi travailler ensuite.

55Questions
120minDurée

Vérifié auprès de Google Cloud · août 2026Version actuelle de l’examen

À propos de l’examen

La certification Professional Security Operations Engineer valide la capacité à détecter, surveiller, analyser et investiguer les menaces de sécurité visant les workloads, les endpoints et l’infrastructure, ainsi qu’à y répondre à l’aide des ressources Google Cloud. Elle couvre les opérations de plateforme, la gestion des données, le threat hunting, la detection engineering, la réponse aux incidents et l’observabilité, en évaluant ta maîtrise de Google Security Operations (SecOps), de Security Command Center (SCC), de l’écriture de règles de détection, de l’ingestion de logs et de l’automatisation de la réponse.

C’est une certification de niveau professionnel destinée aux analystes et ingénieurs en opérations de sécurité spécialisés dans la détection des menaces, la réponse aux incidents et la surveillance de la sécurité sur Google Cloud. Google recommande au moins 3 ans d’expérience dans le secteur de la sécurité, dont au moins 1 an avec les outils de sécurité Google Cloud. Elle ouvre la voie à des postes d’analyste SOC, de threat hunter ou de detection engineer.

Contenu de l’examen

C’est l’ingénierie de détection qui pèse le plus lourd, avec 22 % : conception de règles YARA-L, détection basée sur le risque et adossée à la threat intelligence, réduction des faux positifs via le scoring des alertes. Vient ensuite la réponse à incident, à 21 % : confinement et recherche de cause racine, conception de playbooks SOAR, progression des cas tout au long du cycle de réponse. Le threat hunting occupe 19 %, avec la recherche d’indicateurs de compromission et de schémas d’attaque émergents dans la télémétrie de l’environnement et la threat intelligence. Les opérations de plateforme et la gestion des données sont à égalité, 14 % chacune : d’un côté l’intégration des sources de télémétrie et l’authentification, de l’autre l’ingestion des logs et le réglage des parsers dans Google SecOps. L’observabilité, qui couvre les dashboards et la surveillance de la santé de la plateforme, ferme le blueprint à 10 %.

À elles deux, détection et réponse représentent 43 % de l’examen. Malgré des intitulés de domaines qui sonnent très terrain, les questions portent bien plus sur les mécanismes de Google Security Operations et de Security Command Center que sur le jugement d’un analyste SOC en général.

Plan de l’examen : GCP-PSOE

Platform operations~14%

Prioritize and stitch together telemetry sources like Security Command Center and Google SecOps to sharpen detection, and set up the user and service-account authentication those tools rely on.

≈ 14 h
Data management~14%

Feed logs into Google SecOps with parsers tuned for accuracy and cost, and build the user, asset, and entity baselines that later detections and enrichment depend on.

≈ 14 h
Threat hunting~19%

Hunt for anomalous behavior across environments by building targeted queries, and lean on threat intelligence to search out indicators of compromise and spot attack patterns before they're widely known.

≈ 19 h
Detection engineering~22%

Develop and implement detection mechanisms such as detection rules and risk-based analytics to identify threats and posture changes, and leverage threat intelligence to score alerts and reduce false positives.

≈ 22 h
Incident response~21%

Contain a live security incident by gathering evidence and scoping its blast radius, trace it back to root cause using tools like Google SecOps SIEM, build playbooks that guide the response, and move cases through a defined lifecycle from open to closed.

≈ 21 h
Observability~10%

Build dashboards and reports that turn telemetry, detections, and alerts into security insight, and set up the health monitoring and alerting that keeps the security platform itself running.

≈ 10 h

Format de l’examen et types de questions

L’examen propose 50 à 60 questions à choix unique et à choix multiples en 120 minutes, réparties grosso modo à 80 % de questions à réponse unique pour 20 % à réponses multiples. Les questions évaluent ta connaissance pratique des capacités SIEM/SOAR de Google Security Operations (anciennement Chronicle) et des fonctionnalités de Security Command Center, pas la théorie générale de l’analyse en sécurité.

Types de questions : GCP-PSOE

Choix multiple80%

Choisis la seule bonne réponse parmi quatre ou cinq options — le format de base de l’examen.

Réponse multiple20%

Plusieurs réponses sont correctes et il te les faut toutes ; l’énoncé indique combien en cocher.

Google Cloud confirme ces types de questions — aucune répartition en pourcentage n’est publiée ; les parts reflètent notre banque de questions alignée sur l’examen.

Essaie cinq questions GCP-PSOE

Cinq questions tirées de notre banque Professional Security Operations Engineer. Réponds à une — Alex t’explique le pourquoi.

L’examen et l’app sont en anglais — ces questions d’exemple, nous les avons traduites.

Chasse aux menaces1 / 5

Un threat hunter analyse un comportement utilisateur anormal dans Google SecOps et soupçonne un déplacement latéral. Il s'agit d'identifier un compte utilisateur qui s'authentifie depuis un nombre inhabituel d'adresses IP source distinctes sur une fenêtre de 24 heures. Quelle approche YARA-L convient le mieux à cette analyse comportementale ?

AlexExplication complète d’Alex

Pour les détections comportementales, utilise une règle YARA-L multi-événements. Affecte l'ID utilisateur et l'IP source des événements USER_LOGIN, regroupe par utilisateur dans la section match sur 24 h, calcule un outcome tel que $distinct_source_ips = count_distinct($src_ip) et déclenche dans la section condition dès que cet outcome dépasse le seuil choisi. Cela suit la structure officielle de YARA-L : match corrèle les événements, outcome calcule les agrégations et condition décide si la règle se déclenche.

Sourcecloud.google.com

Gestion des données2 / 5

Tu enquêtes sur une possible fuite de données et tu dois déterminer s'il y a un retard dans l'ingestion des logs d'une source critique. Quelle métrique du Health Hub t'aide à identifier la latence d'ingestion ?

AlexExplication complète d’Alex

Le Health Hub expose le 95e centile de l'écart entre Last Event Time (le moment où l'événement s'est produit à la source) et Last Ingested (le moment où SecOps l'a reçu). Un écart élevé suggère une latence dans le pipeline d'ingestion de SecOps, tandis qu'un écart normal peut indiquer que la source envoie des données plus anciennes ou historiques (réf. : docs.cloud.google.com/chronicle/docs/reports/data-health-monitoring-and-troubleshooting-dashboard). Cette métrique répond directement à la question de savoir si le retard d'ingestion vient du pipeline ou de la source. Pourquoi pas les autres ? Le nombre de Total Ingested Logs mesure le volume, pas la latence. Config Last Updated aide à corréler les changements de configuration avec les pannes, mais ne mesure pas le retard. Les erreurs de parseur par heure indiquent la santé du parsing, pas le timing de l'ingestion. L'écart entre Last Event Time et Last Ingested est le diagnostic de latence définitif.

Sourcecloud.google.com

Ingénierie de détection3 / 5

Un ingénieur en détection écrit une règle YARA-L pour détecter les tentatives de connexion échouées et souhaite filtrer les correspondances sur les valeurs nulles du champ userid. Selon les bonnes pratiques YARA-L, quelle approche doit-il retenir ?

AlexExplication complète d’Alex

En YARA-L 2.0, les valeurs nulles (chaînes vides, 0, false) ne sont PAS filtrées automatiquement pour tous les champs. Le Rules Engine ne filtre implicitement les valeurs nulles que pour les placeholders de la section match ; les autres champs d'événement exigent une exclusion explicite avec != "" (réf. : docs.cloud.google.com/chronicle/docs/detection/yara-l-best-practices). Sans $e.principal.user.userid != "", les champs userid omis prennent la valeur "" par défaut et créent des correspondances faussement positives. C'est une bonne pratique documentée pour réduire les faux positifs. Pourquoi pas les autres ? Le filtrage automatique ne s'applique PAS partout — seuls les placeholders de la section match bénéficient de l'exclusion implicite des valeurs nulles (réf. : docs.cloud.google.com/chronicle/docs/yara-l/match-syntax). Déplacer un champ vers la section outcome n'empêche pas les correspondances sur les valeurs vides dans events. Le modificateur nocase change la sensibilité à la casse, pas la gestion des valeurs null.

Sourcecloud.google.com

Observabilité4 / 5

Tu dois créer une règle d'alerte Cloud Monitoring qui se déclenche lorsque le débit d'ingestion des logs SecOps passe sous un seuil, ce qui peut signaler la panne d'une source de logs ou une coupure réseau. Quelle métrique et quelle condition dois-tu configurer ?

AlexExplication complète d’Alex

Pour détecter la panne d'une source de logs, crée une règle d'alerte Cloud Monitoring qui utilise la métrique Chronicle Collector > Ingestion > Total ingested log count (ou Total ingested log size) avec une condition Metric absence. Elle se déclenche quand aucune donnée n'est reçue pendant une durée définie (réf. : docs.cloud.google.com/chronicle/docs/ingestion/ingestion-notifications-for-health-metrics). La configuration documentée : sélectionne la métrique d'ingestion, regroupe par collector_id, règle la Rolling window sur 1 heure au maximum et choisis Metric absence comme type de condition, avec un délai d'absence de déclenchement. Pourquoi pas les autres ? Le backlog Pub/Sub surveille la profondeur de file, pas l'ingestion propre à SecOps. Une CPU Compute Engine qui tombe à zéro n'est pas fiable et n'indique pas directement l'arrêt du flux de logs. Les entrées par seconde de Cloud Logging mesurent le débit de Cloud Logging, pas spécifiquement la santé de l'ingestion SecOps.

Sourcecloud.google.com

303 questions, construites comme l’examen

Chaque domaine de l’examen GCP-PSOE a assez de questions dans la banque pour être travaillé en profondeur. Un examen blanc te pose 55 questions d’affilée, sur le même chrono de 120 minutes que le jour de l’examen.

Procès-verbal : GCP-PSOE

Contrôle du programme auprès de Google Cloud4 août 2026

dernière vérification auprès de la source officielle Google Cloud

Couverture du programme13 objectifs officiels

répartis sur 6 domaines, d’après le guide officiel de l’examen

Taille de la banque303 questions

= 5 examens blancs complets de 55 questions — jamais deux fois la même question

Couverture des domainesles 6 domaines à leur pondération officielle

Platform operations 41 · Data management 39 · Threat hunting 56 · Detection engineering 74 · Incident response 61 · Observability 32

Validation canonique303 sur 303

chacune vérifiée avec la documentation officielle Google Cloud — réponse, options et explication, source citée

Méthodologie documentée ouvertement.Comment les questions sont créées →

Se préparer à GCP-PSOE

Le temps qu’il te faut dépend de ton expérience pratique. Le reste est fixé par l’éditeur : comment l’examen se déroule, quand tu peux le repasser et combien de temps la certification reste valable.

Tu peux passer l’examen en ligne avec surveillance à distance, ou dans un centre d’examen. La certification est valable 2 ans, et se renouvelle en repassant une version actualisée de l’examen pendant la période d’éligibilité au renouvellement.

Ton plan : GCP-PSOE

Préparation

Temps de préparation60–150 h

en général environ 60 h si tu travailles déjà avec ces technologies, environ 150 h en partant de zéro

NiveauAvancé
À maîtriser avantAucun prérequis officiel. Il est recommandé d'avoir au moins 3 ans d'expérience dans le secteur de la sécurité, dont au moins 1 an d'utilisation des outils de sécurité Google Cloud.

Le jour J et après

Mode de passageSurveillé en ligne ou centre d'examen sur place
Politique de reprisePolitique standard de nouvelle tentative des certifications Google Cloud : 14 jours d'attente après la première tentative, 60 jours après la deuxième tentative, 365 jours après la troisième tentative
Validité2 ans

Recertification pendant la période d'éligibilité au renouvellement, en repassant l'examen dans sa version à jour

Ces heures sont notre propre estimation de planification — Google Cloud ne publie aucun temps de préparation pour cet examen. Un point de départ pour ton agenda, pas un objectif.

Erreurs courantes

Security Command Center (SCC) et Google Security Operations se recouvrent suffisamment dans leurs objectifs pour que, sous la pression de l’examen, on ne sache plus dire quel outil assure quelle fonction. La confusion la plus fréquente : l’Event Threat Detection automatisé de SCC face aux règles de détection YARA-L personnalisées de SecOps. Les parser modifications et les parser extensions répondent à des besoins de normalisation des données différents dans SecOps, et beaucoup de supports de révision les présentent comme interchangeables, ce qui entretient l’amalgame. Les questions de réponse à incident supposent que tu maîtrises tout le cycle de vie d’un playbook SOAR, y compris les étapes de case management et les workflows d’escalade, bien au-delà du simple confinement. Logs Explorer, Log Analytics et BigQuery correspondent chacun à des scénarios d’investigation différents : choisir le mauvais te coûte du temps, même si ton analyse aurait été juste sur le fond.

Points de vigilance : GCP-PSOE

  1. 01Chronicle/SecOps

    Mal comprendre l’architecture de Google Security Operations (Chronicle), l’UDM et les règles de détection

  2. 02Detection Rules

    Ne pas savoir écrire ni optimiser des règles de détection YARA-L pour repérer les menaces

  3. 03Log Ingestion

    Confondre les sources de logs, les parsers et la normalisation vers le Unified Data Model

  4. 04SOAR Playbooks

    Ne pas savoir concevoir ni mettre en place des playbooks de réponse automatisée

  5. 05Threat Intelligence

    Négliger les flux de threat intelligence, la gestion des IOC et les workflows d’enrichissement

  6. 06Incident Response

    Sauter des étapes de la réponse à incident : confinement, éradication et retour d’expérience une fois l’incident clos

Pass-IT t’entraîne précisément sur ces points faibles — adaptatif et espacé →

Questions fréquentes

Quelles sont les erreurs fréquentes à l’examen Professional Security Operations Engineer ?

Les pièges fréquents incluent : Chronicle/SecOps, Detection Rules, Log Ingestion, SOAR Playbooks, Threat Intelligence, Incident Response. Concentre ton temps de révision sur ces points pour ne pas perdre de points.

Quelle est la pondération de l'examen Professional Security Operations Engineer ?

Detection engineering est la plus grosse partie avec 22%, devant incident response à 21% et threat hunting à 19%. Platform operations et data management comptent pour 14% chacune et observability pour 10%. Six dixièmes de l'examen portent donc sur la détection, la chasse aux menaces et la réponse.

Security Operations Engineer ou Cloud Security Engineer ?

L'examen Cloud Security Engineer porte sur la construction des contrôles : configuration des accès, protection des données et sécurité du périmètre. Celui-ci porte sur l'exploitation de la détection et de la réponse qui viennent par-dessus, d'où des questions sur l'écriture de détections, la chasse aux menaces et la gestion des incidents. Si ton quotidien, c'est une garde en SOC plutôt qu'une revue de conception sécurité, c'est celui-ci qui te correspond.

Quelle expérience l'examen Security Operations Engineer suppose-t-il ?

Trois ans ou plus d'expérience dans le secteur de la sécurité, dont au moins un an avec les outils de sécurité Google Cloud, à titre de recommandation. Le catalogue prévoit environ 100 heures. L'expérience acquise dans un autre SOC se transpose bien, car l'examen porte autant sur la méthode que sur les produits.

Combien de temps la certification Security Operations Engineer reste-t-elle valable ?

Deux ans, avec une recertification via un examen actualisé pendant la période d'éligibilité au renouvellement. Google Cloud ne propose aucune alternative à base de crédits.

Quelle est la politique de repassage de l'examen Security Operations Engineer ?

Quatorze jours après le premier échec, 60 jours après le deuxième et 365 jours après le troisième. Ce calendrier est le même que pour le reste de la gamme professional de Google Cloud.

Pass-IT est un outil de révision indépendant, ni affilié à Google Cloud ni approuvé par Google Cloud ; Google Cloud et les noms d’examens sont des marques de leurs propriétaires respectifs.

Une certification. Un seul paiement.

Accès complet à GCP-PSOE

Accède à toute la banque de questions de cette certification. Alex explique chaque réponse et ton score de préparation te montre quoi travailler ensuite.

Acheter l’accès à GCP-PSOE pour $29.99Un seul paiement. Accès à vie à cette certification.
Vérifie gratuitement si tu es prêt20 questions. Sans carte. Vois quoi travailler avant d’acheter.

Atteins 80 % de préparation et réussis — ou tu es remboursé.

Comment fonctionne le score →