Google Cloud · GCP-PSOE · Advanced

Professional Security Operations Engineer — Übungsfragen und Probeprüfung

Name: Pass-IT
Author: Pass-IT

Bereite dich mit eigens erstellten Übungsfragen und verständlichen Antworterklärungen auf GCP-PSOE vor. Frage Alex, deinen KI-Tutor, wenn du mehr Details brauchst. Deine Ergebnisse zeigen dir, welche Themen du wiederholen solltest, und zeitlich begrenzte Probeprüfungen helfen dir, deine Zeiteinteilung zu üben.

Kostenlos für GCP-PSOE üben Zugang für GCP-PSOE für $29.99 kaufen

Zugang für GCP-PSOE für $29.99 kaufen Kostenlos für GCP-PSOE üben

55Fragen der Probeprüfung

120minZeitlimit

Mit Angaben von Google Cloud abgeglichen · August 2026 · Aktuelle Prüfungsversion

Überblick

Über die Prüfung

Die Zertifizierung Professional Security Operations Engineer belegt, dass du Sicherheitsbedrohungen für Workloads, Endpoints und Infrastruktur mit Google-Cloud-Ressourcen aufspüren, überwachen, analysieren, untersuchen und abwehren kannst. Sie deckt Platform Operations, Datenmanagement, Threat Hunting, Detection Engineering, Incident Response und Observability ab und prüft, wie sicher du mit Google Security Operations (SecOps), dem Security Command Center (SCC), dem Schreiben von Detection Rules, der Log-Ingestion und automatisierten Response-Abläufen umgehst.

Es ist eine Zertifizierung auf Professional-Level für Security-Operations-Analysten und -Engineers, die sich auf Threat Detection, Incident Response und Security Monitoring in der Google Cloud spezialisiert haben. Google empfiehlt mindestens drei Jahre Erfahrung in der Security-Branche, davon mindestens ein Jahr mit den Security-Tools der Google Cloud. Typische Rollen danach: SOC-Analyst, Threat Hunter oder Detection Engineer.

Übungsfragen ausprobieren

Fünf Fragen zu GCP-PSOE ausprobieren

Übe mit fünf Fragen aus dem aktuellen Fragenpool für Professional Security Operations Engineer in der App, jeweils mit Antwort und Erklärung.

Threat Hunting1 / 5

Ein Threat Hunter analysiert auffälliges Nutzerverhalten in Google SecOps und vermutet Lateral Movement. Dabei soll ein Nutzerkonto identifiziert werden, das sich innerhalb eines 24-Stunden-Fensters von einer ungewöhnlich hohen Zahl unterschiedlicher Quell-IP-Adressen authentifiziert. Welcher YARA-L-Ansatz eignet sich am besten für diese Verhaltensanalyse?

AlexGanze Erklärung von Alex

Für verhaltensbasierte Detections nimmst du eine Multi-Event-YARA-L-Regel. Weise die User-ID und die Quell-IP aus USER_LOGIN-Events zu, gruppiere im match-Abschnitt über 24 h nach User, berechne ein Outcome wie $distinct_source_ips = count_distinct($src_ip) und löse in der condition aus, sobald dieses Outcome den gewählten Schwellenwert überschreitet. Das entspricht der offiziellen YARA-L-Struktur: match korreliert Events, outcome berechnet Aggregationen, und condition entscheidet, ob die Regel feuert.

Quellecloud.google.com

Datenmanagement2 / 5

Du untersuchst einen möglichen Data Breach und musst feststellen, ob es bei der Log-Ingestion aus einer kritischen Quelle zu Verzögerungen kommt. Welche Health-Hub-Metrik hilft dir, Ingestion-Latenz zu erkennen?

AlexGanze Erklärung von Alex

Der Health Hub zeigt das 95. Perzentil der Differenz zwischen Last Event Time (wann das Event an der Quelle aufgetreten ist) und Last Ingested (wann SecOps es empfangen hat). Eine hohe Differenz deutet auf Latenz innerhalb der Ingestion-Pipeline von SecOps hin, während eine normale Differenz darauf hindeuten kann, dass die Quelle ältere oder historische Daten liefert (Quelle: docs.cloud.google.com/chronicle/docs/reports/data-health-monitoring-and-troubleshooting-dashboard). Diese Metrik beantwortet direkt, ob die Verzögerung bei der Ingestion ein Pipeline-Problem oder ein Problem auf Seiten der Quelle ist. Warum nicht die anderen? Die Zahl der Total Ingested Logs misst Volumen, nicht Latenz. Config Last Updated hilft dabei, Konfigurationsänderungen mit Fehlern zu korrelieren, misst aber keine Verzögerung. Parser-Fehler pro Stunde zeigen den Zustand des Parsings, nicht das Timing der Ingestion. Die Differenz zwischen Last Event Time und Last Ingested ist die eindeutige Diagnose für Latenz.

Quellecloud.google.com

Detection Engineering3 / 5

Ein Detection Engineer schreibt eine YARA-L-Regel, die fehlgeschlagene Login-Versuche erkennen soll, und will Treffer mit Nullwerten im Feld userid herausfiltern. Welcher Ansatz entspricht den YARA-L-Best-Practices?

AlexGanze Erklärung von Alex

In YARA-L 2.0 werden Nullwerte (leere Strings, 0, false) NICHT automatisch für alle Felder gefiltert. Die Rules Engine filtert Nullwerte implizit nur für Platzhalter im match-Abschnitt; andere Event-Felder musst du explizit mit != "" ausschließen (Quelle: docs.cloud.google.com/chronicle/docs/detection/yara-l-best-practices). Ohne $e.principal.user.userid != "" stehen weggelassene userid-Felder standardmäßig auf "" und erzeugen falsch positive Treffer. Das ist eine dokumentierte Best Practice, um False Positives zu reduzieren. Warum nicht die anderen? Die automatische Filterung gilt NICHT generell — nur Platzhalter im match-Abschnitt bekommen den impliziten Ausschluss von Nullwerten (Quelle: docs.cloud.google.com/chronicle/docs/yara-l/match-syntax). Ein Feld in den outcome-Abschnitt zu verschieben verhindert nicht, dass in events auf leere Werte gematcht wird. Der Modifier nocase ändert die Groß-/Kleinschreibungsempfindlichkeit, nicht den Umgang mit Nullwerten.

Quellecloud.google.com

Observability4 / 5

Du musst eine Alerting-Policy in Cloud Monitoring anlegen, die auslöst, wenn die Rate der Log-Ingestion in SecOps unter einen Schwellenwert fällt — ein möglicher Hinweis auf den Ausfall einer Log-Quelle oder eine Netzwerkstörung. Welche Metrik und welche Bedingung solltest du konfigurieren?

AlexGanze Erklärung von Alex

Um den Ausfall einer Log-Quelle zu erkennen, legst du in Cloud Monitoring eine Alerting-Policy an, die die Metrik Chronicle Collector > Ingestion > Total ingested log count (oder Total ingested log size) mit einer Bedingung vom Typ Metric absence verwendet. Sie löst aus, wenn über eine festgelegte Dauer keine Daten eingehen (Quelle: docs.cloud.google.com/chronicle/docs/ingestion/ingestion-notifications-for-health-metrics). Das dokumentierte Setup: die Ingestion-Metrik auswählen, nach collector_id gruppieren, das Rolling window auf bis zu 1 Stunde setzen und Metric absence als Bedingungstyp mit einer Trigger-Absence-Zeit konfigurieren. Warum nicht die anderen? Der Pub/Sub-Backlog überwacht die Queue-Tiefe, nicht die SecOps-spezifische Ingestion. Eine auf null fallende CPU-Auslastung der Compute Engine ist unzuverlässig und zeigt nicht direkt an, dass der Log-Fluss steht. Cloud Logging-Einträge pro Sekunde messen den Durchsatz von Cloud Logging, nicht speziell den Zustand der Ingestion in SecOps.

Quellecloud.google.com

Kostenloses Konto erstellen

Die Fragen in der App sind derzeit auf Englisch. Übersetzungen in dieser Vorschau gelten nur für die Vorschau. Welche Sprachen für die offizielle Prüfung verfügbar sind, erfährst du beim Prüfungsanbieter.

Fragenpool

430 Übungsfragen

Der Pass-IT-Fragenpool bietet dir Aufgaben zur Vorbereitung auf GCP-PSOE. Eine Probeprüfung auf Pass-IT umfasst 55 Fragen bei einem Zeitlimit von 120 Minuten. Diese Einstellungen gelten für die Übung.

Angaben zum Fragenpool: GCP-PSOE

Prüfungsziele im Leitfaden13 im offiziellen Leitfaden aufgeführte Prüfungsziele

verteilt auf 6 Bereiche im offiziellen Prüfungsleitfaden

Größe des Fragenpools430 Fragen

= Der Umfang des Fragenpools entspricht rechnerisch 7 Zusammenstellungen mit je 55 Fragen. Daraus folgt nicht, dass jede Probeprüfung andere Fragen verwendet.

Bereiche im Prüfungsplan6 Bereiche im Prüfungsplan

Platform operations 73 · Data management 59 · Threat hunting 72 · Detection engineering 86 · Incident response 97 · Observability 43

Als mit Quellen abgeglichen erfasst430 von 430

Fragen, deren Antwort, Antwortoptionen und Erklärung als mit der offiziellen Dokumentation von Google Cloud abgeglichen erfasst sind

So entstehen die Fragen →

Prüfungsbereiche

Inhalte der Prüfung

Detection Engineering wiegt mit 22 % am schwersten: YARA-L-Regeldesign, risikobasierte Detection im Zusammenspiel mit Threat Intelligence und weniger False Positives durch Alert Scoring. Direkt dahinter liegt Incident Response mit 21 %, also Containment und Root-Cause-Analyse, das Design von SOAR-Playbooks und das Führen von Cases durch den Response-Lifecycle. Threat Hunting kommt auf 19 %, hier durchsuchst du die Telemetrie der Umgebung und Threat Intelligence nach Indicators of Compromise und neuen Angriffsmustern. Platform Operations und Data Management liegen mit je 14 % gleichauf, einmal Anbindung von Telemetriequellen und Authentifizierung, einmal Log-Ingestion und Parser-Tuning in Google SecOps. Observability schließt das Blueprint mit 10 % ab und deckt Dashboards sowie das Monitoring der Plattform-Gesundheit ab.

Detection und Response machen zusammen 43 % der Prüfung aus. Die Domain-Namen klingen zwar stark nach Hands-on-Betrieb, tatsächlich zielen die Fragen aber vor allem auf die Mechanik von Google Security Operations und Security Command Center, weniger auf allgemeines Urteilsvermögen als SOC-Analyst.

Prüfungsplan: 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

Prüfungsformat und Fragetypen

In 120 Minuten bekommst du 50 bis 60 Fragen im Multiple-Choice- und Multiple-Select-Format, im Verhältnis von grob 80 % Einzelantwort zu 20 % Mehrfachauswahl. Geprüft wird praktisches Wissen zu den SIEM-/SOAR-Fähigkeiten von Google Security Operations (früher Chronicle) und zu den Funktionen von Security Command Center, nicht allgemeine Theorie aus der Security-Analyse.

Fragetypen: GCP-PSOE

Multiple Choice80%

Wähle die einzelne Antwort aus, die die Anforderungen der Frage am besten erfüllt.

Mehrfachauswahl20%

Wähle mehrere Antworten aus. Beachte dabei, wie viele Antworten laut Aufgabenstellung gefragt sind.

Offizielle Informationen zu den Frageformaten findest du bei Google Cloud. Die dargestellten Anteile beziehen sich auf den Pass-IT-Fragenpool und geben keine Verteilung für die offizielle Prüfung vor.

Planung

Vorbereitung auf GCP-PSOE

Die Prüfung legst du entweder online mit Remote-Proctoring ab oder vor Ort in einem Testcenter. Die Zertifizierung gilt 2 Jahre; zur Verlängerung schreibst du im Recertification-Zeitfenster eine aktualisierte Prüfung.

Vorbereitung und Organisation: GCP-PSOE

Vorbereitung

Beispielhafter Lernaufwand60–150 h

Beispiel für die Planung: von 60 h mit einschlägiger Erfahrung bis 150 h beim Einstieg; dein Bedarf kann außerhalb dieser Spanne liegen

NiveauFortgeschritten

Empfohlene VorkenntnisseKeine formalen Voraussetzungen. Empfohlen werden mindestens 3 Jahre Berufserfahrung im Security-Umfeld, davon mindestens 1 Jahr mit den Security-Tools der Google Cloud.

Prüfung und Erhalt der Zertifizierung

DurchführungOnline beaufsichtigt oder Prüfungszentrum vor Ort

WiederholungsregelnStandard-Wiederholungsrichtlinie für Google Cloud-Zertifizierungen: 14 Tage Wartezeit nach dem ersten Versuch, 60 Tage nach dem zweiten Versuch, 365 Tage nach dem dritten Versuch

Gültigkeit der Zertifizierung2 Jahre

Rezertifizierung innerhalb des Verlängerungszeitraums durch das Ablegen der aktualisierten Prüfung

Offizieller LeitfadenAuf der Website des Anbieters ansehen

Lernhinweise

Häufige Fehlerquellen

Themen zum Wiederholen: GCP-PSOE

01Chronicle/SecOps
Du verstehst die Architektur von Google Security Operations (Chronicle), das UDM und die Detection Rules nicht
02Detection Rules
Du kannst keine YARA-L Detection Rules zur Bedrohungserkennung schreiben und optimieren
03Log Ingestion
Du verwechselst Log-Quellen, Parser und die Normalisierung ins Unified Data Model
04SOAR Playbooks
Du weißt nicht, wie man automatisierte Response-Playbooks entwirft und umsetzt
05Threat Intelligence
Du übersiehst Threat-Intelligence-Feeds, IOC-Management und Workflows zur Anreicherung
06Incident Response
Du hältst dich nicht an saubere Incident-Response-Abläufe, also Containment, Eradication und die Nachbereitung des Vorfalls

Mit Fragen und Erklärungen in Pass-IT üben →

Fragen

Häufig gestellte Fragen

Welche Fehlerquellen sollte ich bei der Vorbereitung auf Professional Security Operations Engineer beachten?

Zu den Themen, die du wiederholen solltest, gehören Chronicle/SecOps, Detection Rules, Log Ingestion, SOAR Playbooks, Threat Intelligence, Incident Response. Prüfe anhand von Beispielen, ob du die Unterschiede verstehst und deine Antwort begründen kannst.

Wie ist die Prüfung zum Professional Security Operations Engineer gewichtet?

Detection Engineering ist mit 22% der größte Abschnitt, gefolgt von Incident Response mit 21% und Threat Hunting mit 19%. Platform Operations und Data Management machen je 14% aus, Observability 10%. Sechs Zehntel der Prüfung entfallen damit auf Detection, Hunting und Response.

Security Operations Engineer oder Cloud Security Engineer?

Bei der Prüfung zum Cloud Security Engineer geht es darum, die Kontrollen aufzubauen: Zugriffskonfiguration, Datenschutz und Boundary Security. Hier geht es darum, die darauf aufsetzende Detection und Response zu betreiben, also fragt sie nach dem Schreiben von Detections, dem Aufspüren von Bedrohungen und dem Umgang mit Incidents. Wenn dein Job eine SOC-Schicht ist und kein Security-Design-Review, passt diese Prüfung besser.

Welche Erfahrung setzt die Prüfung zum Security Operations Engineer voraus?

Als Empfehlung drei oder mehr Jahre Erfahrung in der Security-Branche, davon mindestens ein Jahr mit Security-Tooling von Google Cloud. Der Katalog veranschlagt rund 100 Stunden. Erfahrung aus einem anderen SOC lässt sich gut übertragen, denn in der Prüfung geht es genauso um Methodik wie um Produkte.

Wie lange gilt die Zertifizierung zum Security Operations Engineer?

Zwei Jahre, mit Rezertifizierung über eine aktualisierte Prüfung innerhalb des Zeitfensters für die Verlängerung. Google Cloud bietet keine Alternative über Credits an.

Wie sind die Wiederholungsregeln für die Prüfung zum Security Operations Engineer?

Vierzehn Tage nach dem ersten Fehlversuch, 60 Tage nach dem zweiten und 365 Tage nach dem dritten. Der Zeitplan entspricht dem der übrigen Professional-Prüfungen von Google Cloud.

Eine Zertifizierung, 12 Monate

Für GCP-PSOE üben

Übe gezielt für eine Zertifizierung oder wähle Pro, um für alle Zertifizierungen zu üben.

Zugang für GCP-PSOE für $29.99 kaufen

Kostenlos mit dem Üben beginnenProbiere die ersten 20 Fragen ohne Kreditkarte aus und finde heraus, ob die Übungen zu dir passen.

Für berechtigte Käufe: Geld-zurück-Garantie bei Nichtbestehen.

Garantiebedingungen ansehen →