Reviewed 10 October 2026. Use the linked official exam guide for your exam version. These are condensed revision notes; the topic pages provide worked distinctions and more recall practice. Google’s 2026 guides use newer Gemini Enterprise Agent Platform names while some APIs and documentation still use Vertex AI.
Memory hook: Collect → normalize → hunt → detect → respond → prove the detector works.
1. Platform operations — 1.1–1.2
SCC supplies cloud posture/threat findings, Google SecOps correlates telemetry and supports response, Google Threat Intelligence adds indicator/adversary context, Cloud IDS observes supported network threats. Choose overlap by required evidence and workflow; more tools do not automatically close a coverage gap.
Separate authentication, feature authorization, data access and response permissions. Workforce federation supports eligible external human identities; scoped service identities support ingestion/automation. Analysts, detection engineers and response playbooks need different access. Audit platform changes/API use and verify Data Access visibility. Document source owners, residency, retention and degraded operation when an integration fails.
2. Data management — 2.1–2.2
Prioritize identity, endpoint, cloud-admin, network and application telemetry against use cases and critical assets. Estimate volume and retention. Ingestion transports; parsing extracts; normalization maps; enrichment contextualizes. Raw logs can arrive successfully while detection fields are absent or wrong.
UDM (Unified Data Model) provides normalized event semantics. Check event type/time/time zone, principal, target, user/host/IP/process and outcome against original samples. principal is the initiating actor; target is the recipient/object in the event’s context. A mapping mistake can reverse the apparent attacker/victim. Validate parser extensions/custom parsers against positive, negative and format-change examples; monitor rejects and lag.
Events describe activity; entities describe users/assets. Alias mapping connects identities across sources, but NAT/reassigned IPs and shared accounts complicate correlation. Enrich with owner, criticality, identity privileges and intelligence freshness; keep provenance so unverified context does not become permanent fact.
3. Threat hunting — 3.1–3.2
Start with a falsifiable hypothesis, select required telemetry and set a time window. Pivot across user, host, process, IP/domain and cloud resource to assemble a timeline. Baselines and low-prevalence behavior can find threats without known IOCs. SCC posture and GTI prioritize paths worth investigating; Logs Explorer, Log Analytics, BigQuery and SecOps search different stored/query contexts.
Retrohunt applies new logic/intelligence to historical events. Verify retention, source coverage and normalized fields first. A malicious-domain match is a lead, not a full verdict; consider shared infrastructure, scanners and approved administration. Record query version, scope, contrary evidence and conclusions, then convert validated findings into detections or response improvements.
4. Detection engineering — 4.1–4.2
YARA-L correlates security events; it is distinct from file-scanning YARA. A rule can include meta documentation, events filters/relationships, match grouping/time window, outcome computed context/risk and condition the detection trigger. Not every section is required for every rule. Single-event rules inspect one event; multi-event rules combine bounded related events. Link on meaningful normalized entities; otherwise unrelated users can create a false sequence.
Reference lists supply reviewed known-good/high-risk values; entity context and risk improve prioritization. Curated detections supply maintained coverage, custom logic covers local behavior, SCC Event Threat Detection custom IOC detectors cover supported cloud threats. Test known attacks, legitimate lookalikes, missing fields and time boundaries. Measure useful precision, missed cases, alert volume and business impact, not rule count alone. Exceptions need narrow scope, owner and review/expiry; never permanently exempt all administrators.
5. Incident response — 5.1–5.3
Triage confidence × scope × asset impact × active harm. Establish incident command/ownership and collect timestamped evidence. Contain effective access and spread while preserving forensic artifacts; deleting resources immediately can destroy proof. Investigate initial access, persistence, lateral movement and affected data using local telemetry and intelligence.
SOAR playbooks should automate repeatable enrichment and permitted actions with scoped credentials, bounded retries, idempotency, error paths and notification. Require appropriate approval/pre-authorization for high-impact actions. Case workflows record assignment, stage, evidence, escalation and handoff; integration failure must not silently close a case. Recovery removes attacker access and verifies business service; after-action work improves controls and detection.
6. SOC observability — 6.1–6.2
Monitor the whole chain: source heartbeat/volume → ingestion freshness → parse success → rule execution → alert delivery → playbook result → case outcome. Silent-source rules need expected activity and maintenance context. A drop in alerts can mean a broken parser.
Dashboards show risk, source/detection coverage, backlog age, containment time and unresolved gaps. Define measurement start/end for MTTD/MTTR and segment severity; averages can conceal critical outliers. SIEM/SOAR dashboards, Looker Studio and Monitoring serve different reporting paths. Every actionable health alert needs an owner, threshold, route and tested escalation.
Traps to catch
- Raw event arrival is not correct normalization; no hunt result is not proof of safety.
- Threat-intelligence scores support judgment; they are not an incident verdict.
- A successful API action is not verified containment; fewer alerts are not always better security.
Last-pass self-check
1. A rule cannot see a username that exists in the raw event. First investigation?
Parser mapping and UDM fields, including whether the user is correctly represented as principal or target.
2. How does a multi-event rule avoid connecting unrelated activity?
Bind relevant entity identifiers, define the event relationship and limit the correlation time window.
3. A new IOC has no matches. What must the conclusion include?
Whether relevant sources, retention, normalized fields and time coverage actually exist; missing telemetry makes the result inconclusive.
4. Why alert on a silent source?
A failed collector/parser can suppress detections while the threat remains; health monitoring protects visibility.
5. Which incident tasks are best initial automation candidates?
Repeatable bounded enrichment/notification and clearly authorized response, with error handling and escalation for consequential actions.
Sources
- Official exam guide
- Published objective groups (PDF)
- Google SecOps
- YARA-L examples
- UDM field list
- SCC overview
Every topic at a glance
Open any topic to revisit its essential facts, decisions and exam traps. Use the full topic for active recall and supporting references.
01 · Platform architecture and access
Memory hook: Posture finds exposure; SIEM connects evidence.
Must remember
- Security Command Center (SCC) centralizes supported posture and threat findings; Google Security Operations combines security analytics and response workflows. Google Threat Intelligence (GTI) enriches investigations; Cloud IDS observes supported network threats.
- Select overlapping tools by required telemetry, detection, investigation and response capabilities. A product name alone does not prove every source or organization is onboarded.
- Separate user authentication, feature authorization and data access. Workforce Identity Federation can support external workforce identities; service identities and scoped API access support automation.
- Grant analysts, detection engineers and automation identities only their required functions and data. A playbook that can isolate machines has a different risk profile from a read-only hunt.
- Audit platform configuration, API use and sensitive data access. Data Access logs may require deliberate configuration; verify collection rather than assuming every read is recorded.
- Document integrations, ownership, region/data requirements and failure behavior. If one enrichment source fails, core incident handling should still have a defined path.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Need cloud misconfiguration and attack-path context | SCC, integrated with the investigation workflow. |
| Need correlation across endpoint, identity and cloud events | Google SecOps with the relevant sources onboarded. |
Traps
- Authentication into a console does not authorize every dataset or response action.
- More tools do not automatically mean better detection coverage.
02 · Ingestion, normalization and entity context
Memory hook: Raw evidence, normalized fields, useful context.
Must remember
- Prioritize logs by detection use cases and asset risk: identity, administrative activity, endpoint, network, application and cloud findings. Estimate volume and retention before enabling every verbose source.
- Ingestion transports events; parsing extracts meaning; normalization maps it to the Unified Data Model (UDM). A successfully delivered raw log can still be unusable for a rule if fields are wrong.
- Validate timestamps, event types, principal/target fields, network addresses and identifiers. Time-zone errors can break correlation; parser changes need representative regression samples.
- Use supported parser extensions or custom parsing when necessary, keeping the raw evidence available for investigation. Monitor rejected events, ingestion delay and schema changes.
- Entity data describes users/assets and enriches event data about activity. Aliasing fields link identities across sources; poor matching can merge unrelated users or split one attacker into many entities.
- Enrich with asset criticality, ownership, identity context and relevant intelligence. Labels and risk context should have provenance and freshness, not become permanent unverified truth.
Review details
UDM separates event metadata and normalized nouns/actors. Principal is the initiating actor and target the recipient/object in the event's context; observer/intermediary fields serve different roles. Mapping the victim into the actor field can invert a detection. Validate raw message → parsed timestamp/type → normalized entities → rule field references with known samples.
Entity context enriches activity with ownership, criticality and identity relationships. Aliasing can link a hostname, account and other identifiers, but NAT, reused IPs and shared accounts make careless matching dangerous. Parser extensions should be tested on expected variations and rejected cases; successful transport does not imply the rule can use the event.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Rule sees no username although raw logs contain one | Inspect parser mapping and UDM principal/target fields. |
| High ingestion cost with little detection value | Review source priority, filtering and retention against concrete use cases. |
Traps
- Raw log arrival is not proof of correct normalization.
- An IP address alone may not uniquely identify a user or device over time.
03 · Threat hunting and retroactive analysis
Memory hook: Hypothesis, evidence, disproof, refinement.
Must remember
- Begin with a falsifiable hypothesis, such as a privileged identity being used from a new device before a sensitive export. Choose telemetry that could support or disprove it.
- Search across identity, endpoint, network and cloud activity; pivot from an indicator to related users, assets, processes and time windows. Logs Explorer, Log Analytics, BigQuery and SecOps serve different data/query contexts.
- Use GTI, posture findings and incident lessons to prioritize hunts. A low-prevalence process or new domain can be suspicious even without a known malicious hash.
- Retrohunt applies new intelligence or detection logic to historical events. Confirm the relevant retention, parsed fields and time range exist; a clean result with missing telemetry is inconclusive.
- Entity risk scores help triage but require evidence and context. Shared infrastructure, scanners and administrator activity can resemble attacks.
- Record query versions, time bounds, evidence, exclusions and conclusions. Feed validated findings to incident response and reusable detection engineering.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| A new IOC is published today | Search retained historical telemetry and correlate local context. |
| No known IOC but suspicious behavior | A behavior-based hunt across identity, process and network evidence. |
Traps
- An intelligence match is a lead, not a complete incident verdict.
- No results cannot establish safety if the source was never collected.
04 · Detection engineering and tuning
Memory hook: Behavior plus context beats a noisy match.
Must remember
- YARA-L rules express security detections over normalized events. Distinguish event filters, correlations/time windows, outcomes and conditions; match the rule to the intended behavior.
- Single-event rules identify one suspicious activity; multi-event rules correlate a sequence or relationship. Bind meaningful entities and time boundaries to avoid unrelated events creating alerts.
- Reference lists and entity context add known-safe, high-value or suspicious sets. Exceptions should be narrow, owned and reviewed; a permanent broad allowlist can hide future abuse.
- Curated detections provide maintained coverage; custom rules address organization-specific behavior. SCC Event Threat Detection custom IOC detectors and posture findings complement SIEM rules.
- Test positive, negative and boundary cases, then evaluate alert volume and analyst outcomes. Track false positives, missed cases, precision and rule coverage rather than only rule count.
- Prioritize using asset impact, behavior confidence, intelligence and entity risk. Tune repetitive alerts without discarding the only evidence of a real repeated attack.
Review details
YARA-L anatomy: meta documents the rule, events filters and relates normalized events, match sets grouping/time scope, outcome computes useful risk/context, and condition defines the detection trigger. Sections vary by rule type; do not force a multi-event grouping into every single-event rule. A shared user/IP variable must actually identify the intended correlation entity.
Test three groups: known malicious sequences, legitimate lookalikes, and boundaries such as late timestamps or missing fields. Record a rule version and expected results before deployment. Changing a parser can change rule behavior without editing the rule, so treat both as part of detection regression testing.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Several individually ordinary actions form an attack | A time-bounded multi-event detection linked by the relevant entity. |
| An approved scanner causes noise | A narrow reviewed exception with expiry/ownership and monitoring. |
Traps
- YARA-L event correlation is not the same language/use case as file-scanning YARA.
- Suppressing all alerts from an administrator removes visibility into compromised administrator accounts.
05 · Incident response and safe automation
Memory hook: Contain harm; preserve proof; restore trust.
Must remember
- Triage severity using scope, confidence, asset criticality and active impact. Establish a timeline from original events and record evidence provenance.
- Contain affected identities, endpoints or services using the least disruptive effective action. Preserve snapshots/artifacts and audit records where appropriate before destructive remediation.
- Investigate hashes, URLs, IPs, processes and cloud actions with local telemetry and threat intelligence. Identify initial access, persistence, lateral movement and affected data, not only the first alert.
- SOAR playbooks automate repeatable enrichment, notification and supported response. Use approvals for high-impact actions, scoped credentials, idempotency, error handling and bounded retries.
- Case management tracks assignment, status, evidence, escalation, handoffs and closure criteria. Ensure a failed integration does not silently close or abandon the incident.
- Coordinate recovery and long-term remediation with engineering teams. After action, improve controls, telemetry, detections and playbooks; verify the attacker’s access is actually removed.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| A high-confidence stolen token is actively used | Revoke/contain affected access and preserve evidence with appropriate coordination. |
| Automation may disable a business-critical account | A justified approval or pre-authorized policy gate with clear rollback/escalation. |
Traps
- Deleting every suspicious resource can destroy evidence and worsen recovery.
- A successful playbook API call does not prove the incident is resolved.
06 · SOC health and meaningful reporting
Memory hook: Monitor the detector as well as the attack.
Must remember
- Track ingestion freshness, parser failures, source volume, rule execution, alert delivery and playbook errors. A silent source can make the environment appear safer while reducing visibility.
- Define expected activity by source and schedule. Zero events from an always-active identity provider deserves different treatment from an intentionally idle test system.
- Dashboards should connect telemetry health, detection coverage, incident backlog, response times and business impact. Separate workload volume from detection quality.
- Measure time to detect/contain/respond consistently, documenting start/end definitions and severity. Averages alone can hide old high-impact cases.
- Use supported SIEM/SOAR dashboards, Looker Studio and Cloud Monitoring where they fit the data. Alert thresholds need an owner, destination, runbook and tested escalation.
- Report trends and gaps with caveats about missing data. Tune health alerts to avoid creating a second unmanageable alert queue.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| A parser stops accepting a critical log format | Alert on ingestion/parsing health even if threat alerts fall. |
| Leadership needs a security report | Show risk, coverage, incident outcomes and unresolved gaps rather than only event counts. |
Traps
- Fewer alerts can mean broken telemetry, not improved security.
- A dashboard without an operational owner does not create a response process.