CertifyDeck
Start for free
All cheat sheets
Professional Security Operations Engineer · CHEAT SHEET

Google Cloud Certified Professional Security Operations Engineer

Key concepts grouped by official exam weight.

Download as PDF (free, no sign-up)

1. Platform operations

13–13%

Enhancing detection and response

  • Google SecOps receives Google Cloud data through direct ingestion (Cloud Logging, Cloud Asset Metadata and Security Command Center Premium findings) or through Cloud Storage when logs must be filtered first. Data Access logs should be tuned to avoid low-value volume, and SCC findings cannot be filtered. Browser threats need Chrome Management logs from the Chrome Enterprise reporting connector.
  • The Google SecOps Content Hub gathers Content Packs (ingestion, curated detections and dashboards), response integrations, playbooks, blocks and saved searches. After installing an integration you configure its connectors, actions and an instance per environment before a playbook can use it. Updates are tested first in IDE staging mode, and Dynamic Mode picks the instance of the case's environment.
  • Each tool covers a different gap: Security Command Center detects from logs (Event Threat Detection, with custom modules), agentlessly (VM Threat Detection) and at runtime (Container and Cloud Run Threat Detection); Cloud Logging notifies with log-based alerting policies without the SIEM; and Google SecOps correlates SCC findings with other logs through rules and curated detections.
  • The Google SecOps MITRE ATT&CK matrix shows coverage per technique: a card with zero rules but available log types is a detection opportunity. Custom rules count only with a technique key in their metadata, and the calculation can be refined by live and alerting status. Managed Detection Testing rule sets confirm that data has the format that curated detections expect.
  • Gemini in Google SecOps generates search queries and YARA-L rules from natural language, summarizes cases and helps build playbooks. The Triage and Investigation Agent decides whether a SIEM alert is a true or false positive using GTI, searches and process trees; it does not process SOAR connector alerts. Embedded in a playbook, its verdict and confidence drive conditional branches.

Configuring access for human and non-human identities

  • Users sign in to Google SecOps with Cloud Identity or Google Workspace, or with a SAML or OIDC IdP through Workforce Identity Federation (SP-initiated SSO only). The SecOps remote MCP server uses OAuth 2.0 with IAM, the MCP Tool User role and, for federated users, a dedicated provider; production agents use their own identity. The GTI API uses keys in the x-apikey header.
  • Google SecOps feature access (feature RBAC) is controlled with IAM on the bound project: predefined roles such as Chronicle API Admin, Editor, Viewer and Limited Viewer, or custom roles with chronicle.* permissions. With Workforce Identity Federation you map google.groups and grant roles to group principalSets. In shared projects, a modifiedGrantsByRole condition limits which roles an administrator can grant.
  • Data RBAC limits which data each Google SecOps user sees through scopes built from labels (log type, namespace, ingestion or custom labels). A scoped user gets Chronicle API Restricted Data Access with an IAM condition on the scope name; global access overrides scoped access. Rules, data tables and reference lists are also bound to scopes, and curated detections are visible only to global users.
  • Google SecOps writes Cloud Audit Logs under the chronicle.googleapis.com service: Admin Activity (creating rules, updating feeds) is always recorded, and to keep UDM searches you must enable Data Read in the Chronicle API Data Access logs. Query them in Logs Explorer by principalSubject and methodName; reading Data Access logs requires Private Logs Viewer, and exempted principals reduce volume.
  • Automations should use least-privilege non-human identities: a service account attached to the resource or impersonated through Workload Identity (as the Security Command Center integration recommends) rather than JSON keys, because a standard API key does not identify a principal. In GTI, integrations use group service account keys, and the Google SecOps MCP server requires MCP Tool User plus a Chronicle API role.

2. Data management

20–20%

Ingesting logs for security tooling

  • The Bindplane collector (OpenTelemetry-based) reads Windows Event channels and sends them with one exporter per log type (WINEVTLOG, WINDOWS_SYSMON); at scale, gateways sit behind a load balancer. For Google Cloud, direct ingestion forwards Cloud Logging, Cloud Asset Metadata and SCC Premium findings, which cannot be filtered per finding; GKE application logs go through Cloud Storage and a feed.
  • Each Event Threat Detection rule states which logs it needs: Cloud DNS for bad domains, VPC flow, firewall or Cloud NAT logs for bad IPs, data access logs (with pgAudit for Cloud SQL for PostgreSQL) for databases, and Workspace only with organization-level activation. In Google SecOps, each curated detection rule set documents its sources, such as GCP_RUN or Cloud Asset Metadata context.
  • Each parser maps to a single log type and converts the raw log into UDM; whatever it does not map stays in the raw log. The Parsers page only lists prebuilt parsers for log types already ingested, and Compare parsers shows the code diff and the UDM output for an editable sample. Turning off auto updates pins the version; Skip update creates a custom parser.
  • A parser extension adds mappings to a default or custom parser without replacing it; a custom parser does replace it and stops updates. There is one extension per log type, built with the no-code approach (simple JSON) or a code snippet (XML, CSV, Grok), and its mappings take precedence. Repeated fields support Append or Replace, and it applies only to new data unless a Log Replay is requested.
  • Normalization turns each log into a UDM event with metadata.event_type, a timestamp and at least one noun (principal, target, src, intermediary, observer, about), so different sources share semantics and rules. Namespaces separate assets with overlapping IPs, and enrichment and aliasing add context at ingestion; for full coverage, use data tables and entity graph joins.

Implementing a baseline of user, asset, and entity context

  • Relevant intelligence is the intelligence that touches your environment: the IOC Matches tab shows feed indicators seen in your events (with retroactive matching over history), ATI prioritizes those matches (Active Breach, High, Medium), the Emerging Threats Center maps GTI campaigns to your IoC matches and enabled rules, and GTI threat profiles recommend actors and campaigns by industry and region.
  • Event data (Cloud Audit Logs, the IdP system log, Sysmon, DNS) records actions and is normalized into UDM events; entity data (OKTA_USER_CONTEXT, AZURE_AD_CONTEXT, CMDBs, Cloud Asset Metadata such as GCP_IAM_CONTEXT) describes users and assets and feeds the Entity Context Graph. Context has a validity interval and is queried with graph.* fields, not with an event UDM search.
  • Aliasing links indicators of the same asset or user (DHCP links IP, MAC and hostname; CS_EDR links asset ID and hostname) so events can be enriched. Each type has its own logic: file hashes use first match, assets merge hostname, MAC and asset_id with the IP only as a fallback, always within the same namespace. For full coverage in rules, Google recommends entity graph joins.

Configuring and Ingesting Threat Intelligence

  • Third-party IoCs are ingested with the matching IoC log type (MISP_IOC, STIX, CSV_CUSTOM_IOC...) so the parser turns them into ECG entities with source_type ENTITY_CONTEXT, threat metadata and a validity interval; GTI data arrives through the BYOL integration (GCP_THREATINTEL) or ATI. YARA-L rules join events with those entities, and a retrohunt with alerting disabled reviews history.
  • Google Threat Intelligence offers Livehunt (YARA rules on every file it analyzes, with IoC Stream notifications) and Retrohunt (past files and a goodware corpus for false positives), Digital Threat Monitoring (monitors over web and dark web content: credentials, brands, domains), Private Scanning of files and URLs without sharing them, and Google Insights, where organization count outweighs raw sightings.

3. Threat hunting

18–18%

Performing threat hunting across environments

  • Google SecOps UDM searches perform best when they filter on optimized fields (metadata.event_type, principal.hostname, target.ip) and narrow the time range; enumerated fields do not accept regular expressions, long value lists belong in data tables used with in, Gemini turns natural language into editable queries, and the search range follows event time, not ingestion time.
  • UDM statistics searches combine a filter, match (grouping, also per day or hour with by or over every), an outcome with functions such as count, count_distinct, sum or earliest, plus order and limit; they do not support condition or the rule-style over window. Empty fields count as values, so filter them out. For continuous behavioural analysis, Risk Analytics for UEBA provides managed rules.
  • Logs Explorer filters entries with the Logging query language (log_id, protoPayload, SEARCH) but does not aggregate; counting and grouping use Observability Analytics with SQL. In Google SecOps, UDM search covers normalized events and raw log search (raw=) finds unparsed strings. The BigQuery export (datalake: events, rule_detections, ioc_matches, entity_graph) supports historical analysis and SQL joins.
  • Threat hunting together with incident response relies on SIEM Search: UDM events and detections you find can be attached to a new or existing case as evidence, and saved searches with ${...} variables are shared with the organization. The Threat Hunt Agent creates cases tagged Threat Hunt, and watchlists raise the risk of only the entities you list.
  • Hunting hypotheses can come from exposure (SCC Risk Engine attack paths, toxic combinations and exposure scores, which are simulations rather than evidence), from intelligence (GTI Threat Profiles and the Emerging Threats Center feed filtered by industry and IoC matches) and from behavior, such as domains with a recent first_seen_time in the Entity Context Graph.

Leveraging threat intelligence for threat hunting

  • To search Google SecOps history for IOCs, use UDM searches with data tables (in %table.column), raw log search for strings not mapped to UDM, and BigQuery for multi-dimensional IOCs such as IP and port. IOC matching is also retroactive, and your own IOC entities need metadata.threat to match beyond roughly five days.
  • To spot new attack patterns, the Emerging Threats Center matches GTI campaigns with your telemetry, shows associated and disabled rules, and Gemini drafts rules for gaps that an analyst approves. ATI prioritizes IoCs as Active Breach, High and Medium. In SCC, Risk Engine finds toxic combinations and chokepoints, shown on the Issues and Findings pages.
  • The Google SecOps entity risk score adds the highest-risk finding to a weighted sum of the others, is normalized from 1 to 1000 and is calculated over 24-hour or 7-day windows. Rules can assign risk with risk_entity_to_score, query graph.risk_score with the window size, or alert on ENTITY_RISK_CHANGE events; the entity page shows its findings and anomalies.
  • A retrohunt applies a YARA-L rule to historical data and is best run with alerting disabled. Multi-event rules re-evaluate time blocks in true-up runs, extended by Ensure enrichment completeness. UDM search and rule results differ, for example on repeated fields (use any). For SQL comparison, BigQuery receives the SecOps export and Cloud Logging offers linked datasets.
  • Proactive intelligence-led hunting combines Google Threat Intelligence (Livehunt applies YARA rules to every analyzed file and notifies in the IoC Stream; Retrohunt scans history and a goodware corpus to test false positives) with Google SecOps rules: YARA-L rules over the ATI Fusion Feed and Mandiant Hunting rule sets with alerting turned off.

4. Detection engineering

20–20%

Developing and implementing mechanisms to detect risks and identify threats

  • Google SecOps automatically matches UDM events against IoCs from Google and from your own feeds, in real time and retroactively, and shows the assets and users involved on IoC Matches. Applied Threat Intelligence prioritizes those matches with GTI, and for custom logic YARA-L joins events, Entity Context Graph indicators and user or asset context.
  • To find anomalous activity, UDM search supports statistics with match, outcome, order and limit; raw log search (raw= and parsed = false) covers data that was never normalized, and metrics functions compare activity with a 30-day baseline inside a rule. Repeated fields are evaluated differently in search and in rules, which need the any keyword.
  • Live rules evaluate new data and a retrohunt applies the same logic to history, preferably with alerting disabled. In the match section you choose hop (over), tumbling (by) or sliding windows anchored to a pivot (after or before), and multi-event rules support a settlement delay and true-up runs for late-arriving data.
  • Google SecOps data tables are lookup tables with typed columns that rules use column-based (in) or row-based (=, >=); in row-based use, all conditions must match on the same row and the rule needs a match section. Rules can write outcome variables with write_row, and rows can expire through a table-level or row-level TTL.
  • Risk Analytics adds up the risk of alerts and detections into a score per entity (user or asset), with configurable weighting, closed alert coefficient and default scores. Risk Analytics for UEBA curated detections compare activity with history; in custom rules, $risk_score sets the value and $risk_entity_to_score the entity, and watchlists apply a factor to specific entities.

Leveraging threat intelligence for detection

  • Applied Threat Intelligence assigns Active breach, High and Medium priorities to IoC matches based on GTI verdict and severity, presence in Mandiant investigations and other features; medium priorities are kept non-alerting to avoid noise. In custom rules, $risk_score in the outcome grades risk per IoC, and ENTITY_RISK_CHANGE lets you alert on an entity risk threshold.
  • To search recent IoCs in Google SecOps telemetry, UDM search with grouped fields (hash, ip, domain) covers several fields at once, and raw log search is kept for unnormalized data. Automatic IoC matching runs in real time and retroactively, rules only use indicators whose metadata.interval covers the event, and the datalake.ioc_matches table supports historical analysis in BigQuery.
  • To measure repetitive alerts in Google SecOps, test the rule over several days, review the Procedural Filtering panel and use the rules and detections curated dashboards. To reduce false positives: suppression_window to throttle repeats, exclusions (curated rules only, checked with Test Exclusion) and data tables holding reusable exclusion lists for custom rules.
  • Google SecOps YARA-L rules can join UDM events with Google Threat Intelligence indicators in the entity graph. Rules that use the legacy Mandiant feeds must move to the GTI_IOC feed, filtering on stable = true to use only verified indicators; association fields (malware, actor) narrow the threat. Without ATI, the BYOL integration normalizes GTI data as GCP_THREATINTEL.
  • Applied Threat Intelligence evaluates telemetry against IoCs curated by Google Threat Intelligence and prioritizes the matches; its composite rules group detections from the same campaign or actor. The Emerging Threats Center shows GTI campaigns and operations with IoC matches, associated and disabled rules, MITRE ATT&CK coverage and the potentially affected entities in your environment.

5. Incident response

18–18%

Containing and investigating security incidents

  • To collect incident evidence in Google Cloud, first snapshot the VM disks, which works with the disk attached, knowing that snapshots do not capture memory; volatile data is collected with live forensics tooling after reducing access, and the VM is abandoned from its managed instance group before isolation. In Google SecOps, Download as CSV exports the UDM events of a multi-event detection.
  • In Security Command Center, the Threats dashboard shows the trend and distribution of threat findings, and each finding includes its JSON, links to MITRE ATT&CK and, when available, the VirusTotal Indicator field. In Google SecOps, the alert view offers the Overview, Graph and Alert history tabs; the graph depends on the UDM nouns included in the outcome section of the rule.
  • To assess scope and severity: Cloud Audit Logs in Logs Explorer (Data Access logs are off by default except for BigQuery and need Private Logs Viewer), related vulnerability and misconfiguration findings in Security Command Center, Vulnerability Assessment for Google Cloud for agentless CVE scanning and Compliance Manager for control violations. A high attack exposure score does not prove an attack.
  • Collaboration relies on ticketing integrations such as Jira (Create Alert Issue plus jobs that sync comments and closure) and on structured closure data: a Disposition field in the Close Case dialog feeds the false positive rate per rule, and the Improvement stage flags cases for detection refinement. In Security Command Center, a real threat finding is set to INACTIVE only after the root cause is investigated with the system owners.
  • Containment runs from playbooks through response integrations: Stop Instance in Google Cloud Compute (after backing up the disks for forensics, since deleted resources cannot be recovered), Contain Endpoint in CrowdStrike Falcon, Disable Service Account in Google Cloud IAM (reversible) and Revoke User Sessions in Google Workspace. Always pick the action that stops the attack without destroying evidence or breaking unknown dependencies.

Building, implementing, and using response playbooks

  • Automate enrichment and triage, and keep containment for cases with certainty or approval: the fallback playbook (priority 3, All trigger) is non-destructive, sensitive actions become Manual with an Approval link for external approvers, and branches after the Triage and Investigation Agent use its verdict and confidence. Failures are handled with Skip step or If previous action fails branches.
  • A Google Threat Intelligence threat profile recommends actors, campaigns and malware by industry, region and motivation; the Threat Map highlights what is both relevant and frequent, and its IoCs can be exported or followed in the IoC Stream. In playbooks, Get Related Associations links entities to actors and campaigns, and the enrichment block should run services by entity type and avoid unnecessary calls.
  • Response integrations are installed from the Content Hub and add connectors, actions and jobs. Pick the one that meets the requirement: Workload Identity and a custom role for Google Cloud Compute, a Remote Agent with Run Remotely for networks without inbound access, Microsoft Graph Mail or Gmail to ask by email and wait for the reply, and ServiceNow wait actions to pause the playbook until IT resolves.
  • New patterns are spotted by reviewing the alerts that fall into the fallback playbook and become use-case-specific playbooks. Gemini can generate them from a prompt with objective, trigger, actions and conditions, using installed integrations only; shared sequences are built as reusable blocks, and everything is tested in the Playbook Simulator with test cases and mock data before activation.
  • Playbook monitoring reveals gaps: Redundant shows playbooks that did not attach because of the one-automatic-playbook-per-alert limit, and Waiting for User Action points to manual waits that can escalate with Time to respond and a dedicated branch. Repeated work on many entities is automated with playbook loops, and informal requests from other teams with request templates handled by a playbook.

Implementing the case management lifecycle

  • SOAR SLAs can apply to alerts or cases; a stage-based case SLA runs only in that stage and doesn't reset on return, a priority-based one resets when priority changes, and a playbook action takes precedence over stage and priority. At closure, Reason and Root Cause are complemented by Case or All scoped custom fields, such as Disposition, which dashboards can query.
  • For escalation, the Assessment stage means evaluation by the next tier, and marking a case as an Incident sets it to Critical, moves it to the irreversible Incident stage, assigns it to the SOC Manager and notifies all analysts. In playbooks, Raise Incident escalates to a SOC role, and a Manual action assigned to a role with Time to respond lets the flow escalate when it times out.

6. Observability

11–11%

Developing and maintaining dashboards to provide insights

  • Response KPIs come from curated dashboards: the Response Health Hub compares MTTR for automatic and manual closures, separates total playbook time from active action time, and shows queues, attachments, failures and terminated runs. The Triage and Investigation Agent Metrics dashboard tracks volume, verdicts and user feedback on those verdicts.
  • Google SecOps dashboards use YARA-L 2.0 queries with a prefix per data source (events, detection, ioc, ingestion, case, playbook...), with match or outcome and no condition section. Curated dashboards aren't edited but duplicated. All follow data RBAC; SOAR data is visible only to global users, and ingestion metrics need scopes with standard labels such as namespace.
  • Each platform has its own reports: in SOAR, the case report (DOC, XLSX or CSV) with wall and actions; in SecOps, dashboard downloads (full CSV, PDF and PNG only what is visible) and scheduled reports by email or Cloud Storage link; in SCC, the PDF risk report with attack paths and toxic combinations; in GTI, report PDFs and Report Digest emails.

Configuring health monitoring and alerting

  • Ingestion health is watched with Google SecOps metrics in Cloud Monitoring: Total ingested log count with Metric absence, grouped by collector_id or ingestion_source, detects silent sources, and Total ingested log size tracks the contracted daily volume, not quota_limit. The Health Hub shows failed or irregular sources and parsers, Last Ingested versus Last Normalized, and silent feed credential failures.
  • Google SecOps dashboards combine charts from several data sources (ingestion metrics, detections, cases, playbooks) using YARA-L queries with a match or outcome section. Curated dashboards such as the Health Hub or Response Health Hub are read-only and are duplicated to customize. To bring Google Cloud metrics, alerting policies and logs into one view, use a Cloud Monitoring custom dashboard.
  • Google SecOps publishes ingestion metrics to Cloud Monitoring (Chronicle Collector Ingestion and Normalizer, Outofband for feeds) that can be filtered by log_type, feed_name, collector_id or state. For daily volume, use Total ingested log size with a one-day window and a threshold, not quota_limit, and aggregate with sum grouped by project_id to avoid false alerts.
  • Cloud Monitoring notification channels include email, SMS, Slack, PagerDuty, webhooks, the Mobile App and Pub/Sub. Redundancy should use email or Pub/Sub, because Slack, PagerDuty, webhooks and the Mobile App share a single point of failure; automation or private endpoints use Pub/Sub, with the notifications service account authorized as Pub/Sub Publisher.
  • On instances with a BYOP project, Google SecOps sends feed activity logs to Cloud Logging (log_id chronicle.googleapis.com/ingestion_activity; STS feeds use storage_transfer_job). Debug with logs opens Logs Explorer filtered on the feed, Ask Gemini Cloud Assist answers questions about volumes and errors, and the Health Hub shows each source's latest issue.
Practice this certification