Prepare and test your skills
Prepare and test your skills
Analysis in Security Command Center centers on threat findings that record suspicious activity in cloud resources. Each finding names the affected resource, the detector that created it, and the evidence needed to decide if the activity was malicious or a missed best practice. Effective operations filter, classify, and manage findings with custom queries and mute rules, then establish real-time notification pipelines using Pub/Sub and Cloud Functions to route alerts, integrate with a SIEM, and trigger remediation.
Threat findings in Security Command Center are detection records created when a threat detector observes suspicious activity in a project, folder, or organization. The full catalog of types is maintained in the threat findings index, where each type documents its source, meaning, and response approach. For example, the Impact: GPU Instance Created (opens in a new tab) finding is produced by the Sensitive Actions Service when a principal creates a GPU instance in a project where that principal has not recently created one. That pattern matters because unexpected GPU creation is a known signal for resource hijacking for cryptomining or other high-compute abuse.
Reviewing a finding in Security Command Center means starting from the finding record and expanding outward to the affected resource and its surrounding activity. The console exposes each finding through Summary and JSON views that carry resource identity, properties, and detector evidence. Triage then correlates related signals and checks configuration and telemetry before a response decision is made.
This order preserves evidence first, then context, then cause. Finding details establish what was detected, correlation establishes whether it is part of a larger incident, and settings plus logs establish whether remediation or hardening is required.
The Impact: GPU Instance Created finding in Security Command Center signals that a creating principal with no recent GPU history in the same project created a GPU instance. The creating principal, project, and instance identity in the finding link the actor to the new high-cost compute resource. Because GPU capacity is a target for hijacked accounts, the finding maps to the MITRE ATT&CK technique for Resource Hijacking (T1496), where an attacker uses compromised access to run unauthorized workloads.
Response focuses on validating intent and blast radius rather than treating every GPU creation as an attack. A legitimate new machine learning workload can produce the same signal as hijacking, so correlation with concurrent findings, review of the instance configuration, and log analysis determine whether credentials were misused. When related findings, unusual principals, or unexpected projects and regions appear together, the activity is more likely to be malicious and requires containment of the identity and resource.
Exam tip: An Impact: GPU Instance Created finding comes from the Sensitive Actions Service and flags a first-time GPU creator in the project, so check findings from a similar time on the same resource to separate resource hijacking from a new legitimate workload.
Security Command Center service tiers determine which threat detection capabilities are available across the organization hierarchy. The tiers named for threat findings include Standard-legacy, Standard, Premium, and Enterprise, with Enterprise now deprecated. The Enterprise tier will shut down on May 21, 2027, and organizations using Enterprise will automatically move to the Premium tier on or after that date. Tier selection therefore affects long-term visibility, so operations that depend on threat findings must account for the move from Enterprise to Premium.
Security Command Center (SCC) (opens in a new tab) is the central platform that combines posture scanning and runtime threat detection to find misconfigurations, software vulnerabilities, and active attacks. Posture services evaluate resource configuration and installed software, while runtime services observe logs and workload behavior to surface threats in near-real time. Findings from all services flow into Security Command Center where they can be reviewed, prioritized with attack exposure, and exported for response.
The four core integrated services divide work by what they observe and what they find. Security Health Analytics (SHA) looks at resource configuration, Event Threat Detection (ETD) looks at log streams, Container Threat Detection (CTD) looks at container runtime behavior, and Virtual Machine Threat Detection (VMTD) looks at VM runtime behavior.
| Service | Monitors | Finds |
|---|---|---|
| Security Health Analytics | Resource configuration and metadata from Cloud Asset Inventory | Misconfigurations, common vulnerabilities, and leaked secrets |
| Event Threat Detection | Cloud Logging streams and Google Workspace logs using threat intelligence and machine learning | Malware, cryptomining, data exfiltration, and malicious control-plane actions |
| Container Threat Detection | Runtime activity in Container-Optimized OS nodes and Cloud Run second-generation execution environments | Evasive exploits, reverse shell executions, and unauthorized cryptomining binaries |
| Virtual Machine Threat Detection | Runtime application behavior inside Compute Engine VM instances without an OS agent | Potentially malicious applications running on VMs |
Posture findings from Security Health Analytics feed attack path simulations, which show how an attacker could chain minor issues from the internet to high-value compute resources or billing permissions. Runtime findings from Event Threat Detection, Container Threat Detection, and Virtual Machine Threat Detection identify activity that is already executing.
Security Health Analytics (SHA) is the misconfiguration and vulnerability posture scanner that detects common risks across Google Cloud resources. Security Health Analytics reads asset configuration from Cloud Asset Inventory and evaluates it against built-in detectors, so it can flag open storage buckets, overly permissive Identity and Access Management (IAM) policies, and known software weaknesses without deploying OS agents to VMs, containers, or Cloud Run workloads. Activating Security Command Center Standard automatically enables Security Health Analytics and creates its service identity, while Premium adds the full detection suite.
Security Health Analytics runs under the Cloud Security Command Center Service Agent, a Google-managed service agent that Security Command Center automatically grants IAM roles to after creation. If workloads sit inside a Virtual Private Cloud Service Controls (VPC-SC) service perimeter, the perimeter must grant inbound access to that service agent or scans cannot read the protected resources. Organizations with unique requirements can extend coverage with custom modules for Security Health Analytics that define their own rules for vulnerabilities, misconfigurations, or compliance violations.
Event Threat Detection (ETD) is the log-based threat detector that applies detection logic, machine learning, and proprietary threat intelligence to log streams in near-real time. Data flows from Cloud Logging and Google Workspace in the organization, folder, or project to Event Threat Detection detectors, and matched threats flow from the detectors to Security Command Center as findings. Because detection depends on the logs, Event Threat Detection starts scanning an always-on source as soon as it is enabled but cannot evaluate a source that is not being generated.
Log availability creates a critical dependency for Event Threat Detection. Cloud Logging Admin Activity audit logs are always on, while most Data Access audit logs are off by default and must be enabled before Event Threat Detection can scan them, and Google Workspace logs require organization-level activation. Which logs to enable depends on the Google Cloud services in use and business security needs, and Cloud Logging may charge for ingestion and storage. After a log is enabled, Event Threat Detection begins scanning it automatically, and organizations can add custom modules for Event Threat Detection to monitor the Logging stream with their own threat parameters.
Exam tip: Event Threat Detection produces no findings for a log type that is disabled, while Container Threat Detection and Virtual Machine Threat Detection produce no findings until their runtime prerequisites are met and, for Cloud Run, services are redeployed.
Container Threat Detection (CTD) and Cloud Run Threat Detection are runtime detectors that monitor active container workloads for live attack behavior. The services observe execution inside the workload and generate findings for patterns such as evasive exploits, reverse shell executions, and launch of unauthorized cryptomining binaries within active containers. Container Threat Detection focuses on Google Kubernetes Engine (GKE) nodes that use Container-Optimized OS images, while Cloud Run Threat Detection focuses on Cloud Run services.
Enabling container runtime detection has explicit configuration dependencies. Container Threat Detection requires clusters on a supported Google Kubernetes Engine version with correct cluster configuration, and it acts through the dedicated Container Threat Detection Service Agent. Cloud Run Threat Detection requires the Container Threat Detection API to be enabled on every project with monitored services, containers tested on the second-generation execution environment, and the Security Center Management Admin role (roles/securitycentermanagement.admin) to change enablement at the organization, folder, or project scope. After Cloud Run Threat Detection is enabled for a scope, the operator must redeploy the Cloud Run services in that scope before instrumentation takes effect, and control-plane threats for Cloud Run remain covered by Event Threat Detection.
Virtual Machine Threat Detection (VMTD) is the agentless runtime detector that identifies potentially malicious applications running inside Compute Engine VM instances. Virtual Machine Threat Detection observes VM behavior from outside the guest operating system, so it can surface cryptominers, rootkits, and other malicious binaries without installing or maintaining OS agents. Vulnerability Assessment complements runtime observation by scanning installed software for common vulnerabilities and exposures (CVEs) and leaked secrets across running VMs, containers, and serverless Cloud Run workloads.
Both services depend on the Cloud Security Command Center Service Agent to access resources on behalf of the customer, and both require Virtual Private Cloud Service Controls ingress and egress rules when service perimeters isolate the environment. Together they close the gap between known-weak software and actively exploited software: Vulnerability Assessment shows what could be exploited, Virtual Machine Threat Detection shows what is behaving maliciously, and Security Health Analytics shows the misconfigurations that would let an attacker reach the host. Findings from all three raise the attack exposure score when they expose resources in the defined high-value resource set.
Enabling the integrated services is a tier-driven operation that is verified in one place. Activating Security Command Center Standard automatically enables Security Health Analytics, while activating Premium enables Container Threat Detection, Event Threat Detection, Security Health Analytics, security posture, Virtual Machine Threat Detection, Vulnerability Assessment, and Web Security Scanner. An administrator confirms which services are enabled on the Settings page in the console and keeps all services in the tier turned on so new and changed resources receive continuous updates, subject to Web Security Scanner production best practices and cost review for Sensitive Data Protection and Google Cloud Armor integrations.
Analysis follows a consistent flow from finding to investigation regardless of source. Visibility depends on the granted Security Command Center role and activation level, and the first full scan typically completes within 24 hours with some services starting later.
Security Command Center (opens in a new tab) is a cloud-based risk management solution that centralizes vulnerability detection, threat detection, security posture management, and compliance monitoring for Google Cloud resources. Security Command Center generates findings, which are records of threats, misconfigurations, vulnerabilities, or compliance drift found by built-in detection services, integrated Google Cloud services, and third-party Marketplace partners. The architecture is controlled by two decisions: the service tier that determines which detection services are available, and the activation level that determines whether coverage and visibility apply to an entire organization or to a single project.
Service tiers in Security Command Center define which detection and operations capabilities are enabled for the activated scope. Standard provides basic scanning for risks and misconfigurations through services such as Security Health Analytics, while Premium adds threat detection, software vulnerability detection, compliance assessment, attack-path simulation, and security posture management. Enterprise adds Google Security Operations (Google SecOps) security information and event management (SIEM) and security orchestration, automation, and response (SOAR), multi-cloud support for Amazon Web Services and Microsoft Azure, and risk analysis features.
| Tier | Activation scope | Choose when |
|---|---|---|
| Standard | Organization or individual project | Basic misconfiguration and risk scanning is sufficient and no additional charge is desired |
| Premium | Organization or individual project | Enhanced scanning, threat detection, attack exposure, compliance monitoring, and posture management are required |
| Enterprise | Organization only | Centralized security operations, multi-cloud collection, and case management with Google SecOps are required |
The Enterprise tier is deprecated and will shut down on May 21, 2027, after which organizations on Enterprise will automatically move to the Premium tier on or after that date. Standard-legacy is a prior version of Standard with limited services, while new Standard activations support enhanced and automatically activated features. Premium project activations support a 30-day free trial that automatically transitions to pay-as-you-go billing unless the project is downgraded to Standard before the trial ends.
Organization-level activation of Security Command Center applies coverage, asset inventory, and findings management across all folders and projects in a Google Cloud organization. Organization-level activation is required for Enterprise, for data residency controls, for customer-managed encryption keys (CMEK), for high-value resource sets and attack exposure scores, for Google Workspace log scanning by Event Threat Detection, and for integrated services such as Google Cloud Armor, Sensitive Data Protection, and third-party sources. Enabling Security Command Center at the organization level gives the security team near real-time visibility into insecure configurations and remediation options as new projects and resources are created.
Project-level activation of Security Command Center applies coverage only to a single project for the Standard, Standard-legacy, and Premium tiers. A project activated at the project level must already be associated with an organization, and certain features that require organization-level access remain unavailable regardless of tier. After activation, Security Command Center completes its first full scan within 24 hours, although some services may start later, and results appear in the Google Cloud console as findings become available. To determine the correct activation path, first check whether Security Command Center is already active in the organization:
Exam tip: Enterprise requires organization-level activation, and project-level activations never gain organization-level features such as integrated sources, Workspace logs, data residency, or high-value resource sets, even on Premium.
Identity and Access Management (IAM) in Security Command Center controls who can activate the service, who can view assets and findings, and what each automated detection service can access. A human administrator activating Security Command Center for a project needs the Security Admin role (roles/iam.securityAdmin) and the Security Center Admin role (roles/securitycenter.admin) on that project, granted directly or through custom or other predefined roles. Enabling required application programming interfaces (APIs) requires the serviceusage.services.enable permission, typically held through the Owner role (roles/owner) or the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin), and domain-restricted organization policies require both the user and service accounts to be in an allowed domain or group.
Automated access in Security Command Center flows from detection services through service agents to monitored resources. A service agent is a Google-managed service account that Security Command Center creates and to which Security Command Center automatically grants required IAM roles so detection services can act on behalf of the customer. Premium activation creates distinct agents with separated duties:
This separation means human IAM roles control asset visibility and administrative permissions, while service agents control service-to-resource access. If Virtual Private Cloud (VPC) Service Controls perimeters isolate projects, the organization must configure ingress and egress policies that grant each service agent inbound access to its service, including separate rules for Security Health Analytics, Container Threat Detection, Compliance Manager, data security posture management, and Vulnerability Assessment.
The Impact: GPU Instance Created finding is produced by the Sensitive Actions Service when a principal with no recent GPU history in the same project creates a GPU instance. It maps to Resource Hijacking (T1496) because unexpected GPU creation is a known signal for cryptomining or other high-compute abuse, so response focuses on validating intent by correlating concurrent findings and reviewing instance configuration and logs.
Review starts by opening the finding through the findings review workflow and examining the Summary tab for context and the JSON tab for complete fields. Triage then correlates other findings from a similar time on the same resource, reviews the affected resource settings for authorized configuration, and checks resource logs to reconstruct who acted and what changed.
Cloud Run Threat Detection requires the Container Threat Detection (CTD) API to be enabled on every project with monitored services and containers tested on the second-generation execution environment. After enablement for an organization, folder, or project scope, the Cloud Run services in that scope must be redeployed before instrumentation takes effect, while control-plane threats remain covered by Event Threat Detection (ETD).
An enterprise has activated Security Command Center (SCC) at the organization level across their Google Cloud environment. A security engineer needs to configure granular Identity and Access Management (IAM) permissions to fulfill two specific operational requirements:
Folder-BU1), without viewing attack paths or resources outside that folder.Which combination of IAM role bindings should the security engineer implement?
Grant roles/securitycenter.findingsViewer and roles/securitycenter.assetsViewer to the central SecOps audit team at the organization level, and grant roles/securitycenter.findingsEditor to the divisional compliance team at the Folder-BU1 level.
Grant roles/securitycentermanagement.admin to the central SecOps audit team at the organization level, and grant roles/securitycenter.settingsViewer to the divisional compliance team at the Folder-BU1 level.
Grant roles/securitycenter.adminViewer to the central SecOps audit team at the organization level, and grant roles/securitycenter.assetsViewer and roles/securitycenter.findingsViewer to the divisional compliance team at the Folder-BU1 level.
Grant roles/securitycenter.admin to the central SecOps audit team at the organization level, and grant roles/securitycenter.adminViewer to the divisional compliance team at the Folder-BU1 level.
Last updated