Prepare and test your skills
Prepare and test your skills
Audit logging, monitoring, and retention architecture in Google Cloud is the end-to-end system that records who did what to which resource and proves the records are complete and tamper-evident. Cloud Audit Logs (opens in a new tab) generates the audit records, Cloud Logging routes and stores them through filters, sinks, and buckets, and Security Command Center (SCC) (opens in a new tab) consumes them for threat detection and compliance verification. This chain satisfies regulatory auditability only when Admin Activity, Data Access, and denied-access events are captured, centrally aggregated, and retained with enforced access control.
Cloud Audit Logs is the native audit trail that records administrative and data-plane activity across Google Cloud services. Admin Activity audit logs record ADMIN_WRITE operations that write metadata or configuration information, and these logs cannot be disabled. Data Access audit logs record read and write access to data and configuration, while Policy Denied events record requests denied by policy checks, so together the three categories show both successful privileged actions and blocked attempts. Data Access entries can contain personally identifiable information (PII) such as caller identities and IP addresses, so log data with PII must be protected with access control, retained only as long as needed for audit purposes, and then disposed of securely.
Data Access audit logs provide broad threat-detection coverage but create a tradeoff between visibility and cost for ingestion, storage, export, and processing. Data Access audit logs, except for BigQuery, are disabled by default and must be explicitly enabled by editing Identity and Access Management (IAM) policy objects through the Google Cloud console or Google Cloud CLI. The IAM policy depends on the organization, folder, or project hierarchy, so configuration applied at the folder or organization level flows down to all child projects. The best practice is to enable Data Access audit logs at the folder or organization level to ensure consistent compliance coverage rather than relying on per-project enablement.
When Data Access audit logs are enabled, the recorded operation types are configurable:
ADMIN_READ: records operations that read metadata or configuration information.DATA_READ: records operations that read user-provided data.DATA_WRITE: records operations that write user-provided data.ADMIN_WRITE operations cannot be configured in Data Access audit logs because those operations are already included in Admin Activity audit logs. Selecting only the needed read and write types limits cost while preserving evidence of access to sensitive data.
Exam tip: ADMIN_WRITE is always on in Admin Activity and cannot be disabled, while ADMIN_READ, DATA_READ, and DATA_WRITE are off by default except for BigQuery and must be explicitly enabled.
Platform logs and audit logs together determine whether compliance violations, MITRE ATT&CK techniques, and Event Threat Detection rules can be detected. The log scoping tool maps each log type to the compliance violations it can detect, the Event Threat Detection rules that rely on that log, and the MITRE ATT&CK tactics and techniques it can monitor. Selecting logs in the tool automatically updates a generated log filter that defines exactly which log entries will be routed. This link between selected sources and the filter keeps detection coverage aligned with what is actually collected.
Platform logs must be enabled service by service at the resource level, and the enablement boundary differs by service. Cloud DNS logs are enabled at the VPC-network level, VPC Flow Logs are enabled at the subnet level for all VMs in the subnet, and Firewall Rules Logging is enabled at the individual firewall-rule level. The log scoping tool links each platform log to its enablement instructions through the enablement column, so the selected filter and the enabled sources stay aligned.
Log routing and retention moves filtered log entries from Cloud Logging to controlled, long-term destinations for auditability. A saved log filter defines the scope, then a log sink routes matching entries from the source project, folder, or organization to a destination log bucket, separate project, or export system. Aggregated sinks created at the folder or organization level collect entries from all child projects into one central location, which prevents gaps when new projects are created and separates audit storage from workload projects.
By default, services such as Gemini Enterprise send Cloud Logging data to the _Default bucket, where access is controlled by IAM roles including Logs Viewer (roles/logging.viewer), Private Logs Viewer (roles/logging.privateLogViewer), and Logs View Accessor (roles/logging.viewAccessor). For projects with mixed sensitivity, fine-grained control isolates sensitive audit logs from general logs and enforces least privilege on viewing, retention, and export.
| Control | What it isolates | Use when |
|---|---|---|
| Log views | Subset of logs within a log bucket | Different teams need different slices of the same bucket |
| Log sinks | Sensitive logs to a separate project with restrictive IAM | Audit logs need stronger boundaries than operational logs |
| Field-level access control | Specific fields within log entries | Entries must be visible but PII fields must stay hidden |
Additional controls include IAM conditions for conditional access, tags for managing IAM access to individual log buckets, and Logs Explorer queries such as filtering on logName to verify that only the intended audit streams reach the retention destination.
Security Command Center is the centralized monitoring plane that turns retained audit and platform logs into findings, compliance evidence, and response actions. Logs Explorer is used to view and analyze event logs and create custom metrics and alerts, the Cloud Monitoring dashboard tracks performance and ingestion health, and Security Command Center applies cloud controls and frameworks to detect vulnerabilities and threats such as privilege escalation. Findings can then flow from Security Command Center to continuous exports for Pub/Sub, BigQuery, and Cloud Logging, and to playbooks used by security operations analysts.
Compliance verification depends on activating the correct tier and framework in Security Command Center. Security Command Center Premium enables Compliance Manager, which can deploy frameworks such as FedRAMP Low 20x for continuous auditing against control objectives. This dependency means auditability requires first the log sources to be enabled, then the aggregated sink to preserve them immutably, and only after that the Security Command Center integrations and Event Threat Detection rules to evaluate them.
Network isolation and perimeter security controls are the set of boundaries that keep regulated workloads separated and keep data from leaving an approved perimeter. VPC Service Controls (VPC-SC) (opens in a new tab) creates service-level perimeters around projects and Google-managed services, Virtual Private Cloud (VPC) (opens in a new tab) networks and filtering rules control traffic between segments, and private connectivity removes public paths to APIs and clusters. Together these layers map to network segmentation and perimeter defense mandates in PCI-DSS, FedRAMP Moderate and FedRAMP High, CIS Controls 12 and 13, and SOC 2.
VPC Service Controls (VPC-SC) is a perimeter service that creates isolation perimeters around Google Cloud resources, projects, networks, and Google-managed services to prevent data exfiltration. Traffic from inside the perimeter to a protected service is allowed by default, while traffic that crosses the perimeter boundary from outside or to another perimeter is denied unless an explicit allowlist permits it. This allowlist model applies even when Identity and Access Management (IAM) would otherwise allow the call, so stolen credentials or a misconfigured IAM grant cannot copy data to an external project.
VPC-SC perimeters segment cloud projects in a Shared VPC so each compliance scope keeps its own boundary while sharing network infrastructure. Access across the boundary is controlled by ingress and egress rules that name the source project, the destination service, and the permitted methods. Platform teams audit blocked traffic and then add precise allowlists, which supports Day One deployment from on-premises to cloud and Day Two automation and maintenance without opening the perimeter broadly.
Perimeter access at scale is managed by integrating IAM roles and group identities into VPC-SC ingress and egress rules. Identity and Access Management (IAM) defines what an identity can do, while VPC-SC defines where that call can go, so a request must pass both the IAM check and the perimeter check before data flows from the protected service to the caller. This separation lets on-premises developers and tools reach cloud resources through defined entry points without granting broad cross-perimeter access.
Identity Groups delegate that control by assigning perimeter access to a group rather than to individual users. Membership in the group flows to the perimeter rule, so adding or removing a user from the group adds or removes cross-perimeter access without editing the perimeter itself. This model reduces rule sprawl and preserves a clear ownership boundary where the perimeter owner manages the boundary and the group owner manages membership.
Segmentation with VPC networks filters traffic between network segments inside and at the edge of the perimeter. Virtual Private Cloud (VPC) isolation starts with custom VPC networks that use custom firewall rules instead of the default network, plus organization policy constraints that restrict default network creation and can disable internal IPv6 usage. Access controls for the network boundary then define which sources, destinations, protocols, and ports can cross each segment, and a dedicated security policy mitigates distributed denial-of-service (DDoS) events at the edge.
Traffic filtering between segments is enforced by workload-specific controls that each name both sides of the flow:
Private connectivity is the practice of keeping traffic flows from compute resources to Google services and control planes off the public internet. Private Google Access lets virtual machine (VM) instances in a subnet reach Google APIs through the VPC network without a public IP address, so data flows from the instance to the API over Google's private path. Private Clusters for GKE removes public endpoints from cluster nodes and the control plane, so kubectl traffic and node-to-control-plane traffic stay private.
Exposure is further reduced by restricting public IP addresses on Compute Engine instances, Cloud SQL instances, and Vertex AI workbench notebooks and instances. Enabling intranode visibility and Cloud Monitoring on GKE clusters preserves inspection of traffic flows from node to node after public paths are removed. Choose private connectivity when the compliance objective is to prove that cardholder data or federal data cannot traverse the internet even if firewall rules change.
Continuous monitoring validates that segmentation and perimeters remain effective after deployment. Security Command Center scans projects protected by a service perimeter, monitors log streams for threats, and exports findings to Pub/Sub and BigQuery across perimeter boundaries. The scans depend on the Security Center Service Agent, so the perimeter must grant that agent explicit ingress or egress access to the required APIs or detection and export will fail.
If perimeter restrictions block scanning, Security Health Analytics generates a VPC_SC_RESTRICTION error finding that signals the dependency is broken. Implementing continuous network traffic monitoring, host-based monitoring on GKE clusters, and network intrusion detection through intranode visibility provides the correlated alerting required by CIS Controls 13-1 through 13-4. Compliance Manager, Event Threat Detection, Virtual Machine Threat Detection, Container Threat Detection, and Vulnerability Assessment for Google Cloud each require the same explicit perimeter access before their findings can flow from the protected project to the security project.
Exam tip: VPC Service Controls denies cross-perimeter data movement even when IAM allows it, and Security Command Center scans fail with a VPC_SC_RESTRICTION finding unless the Security Center Service Agent has explicit ingress or egress rules.
Aligning identity governance and data protection controls with regulatory mandates means mapping each control objective to native Google Cloud enforcement and monitoring. Identity and Access Management governs who can act on resources, VPC Service Controls and organization policies isolate where resources can communicate and reside, and Customer-Managed Encryption Keys (CMEK) (opens in a new tab) and default encryption protect stored data. Together with audit logging and provider transparency, these controls provide the evidence needed for frameworks such as FedRAMP.
Identity and Access Management (IAM) is the system for granting only the roles required to accomplish a task at the smallest scope. Least privilege is implemented by assigning roles to functional groups rather than to individual users, which reduces complexity for managing and auditing access, and by reviewing role recommendations to remove unused and excessive grants. Access to the underlying data queried by a service is controlled separately from access to the service resource itself, so permissions on the data source must also be restricted even when IAM grants access to agents and conversations.
Conditional and credential controls further narrow who can use those grants under strict access governance requirements. Chrome Enterprise Premium is a user-centric control that evaluates attributes such as IP-based access or certificate-based access for mutual TLS on every API request and rejects user traffic that does not meet the defined access level and binding. Compromised authorization credentials alone are insufficient when conditions require an approved device, network, or certificate. For privileged access paths, OS Login with 2-Step Verification (2SV) forces SSH users on Compute Engine to reauthenticate with a password or security key, while service account key creation and upload can be disabled centrally (opens in a new tab) with the constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload organization policy constraints.
| Control | Scope | Applies to |
|---|---|---|
| Chrome Enterprise Premium | User-centric request conditions evaluated on every API request | User identities in the organization only |
| VPC Service Controls | Resource-centric perimeter within which resources can communicate | All user identities and service account identities |
Exam tip: Chrome Enterprise Premium applies only to user identities, while VPC Service Controls applies to both user and service account identities; use them together to limit compromised credentials on an attacker-controlled machine outside the environment.
VPC Service Controls is the resource-centric isolation control that defines service perimeters to prevent access to Google-managed services outside a trusted perimeter, block access from untrusted locations, and mitigate data exfiltration. Traffic flows from developer workstations or corporate networks to Google Front End (GFE), and then from GFE to Google Cloud services over authenticated and encrypted infrastructure, with optional Cloud VPN or Cloud Interconnect providing a dedicated connection between on-premises environments and Google Cloud. Shared VPC (Virtual Private Cloud) centralizes network configuration management while maintaining separation of environments, so network policy ownership stays central while workloads remain isolated.
Data residency is enforced with preventive policy and verified with inventory. The Resource Location Restriction constraint (constraints/gcp.resourceLocations) lets administrators choose the regions where data such as agent configuration, staging and published context, and conversation messages can be stored, and Cloud Asset Inventory verifies the location of those resources. A second boundary, Restrict Resource Service Usage (constraints/gcp.restrictServiceUsage), limits which services can be used in the environment. When the Conversational Analytics API is enabled, Google Cloud creates service agents such as service-PROJECT_NUMBER@gcp-sa-geminidataanalytics.iam.gserviceaccount.com to access resources on behalf of the customer, so those non-interactive identities must be included in perimeter and policy design.
Data protection for regulated workloads starts with Google Cloud default encryption, which encrypts stored data such as data agent configuration, data agent context, and conversation messages and state history so that only the service instances can access it. Customer-Managed Encryption Keys (CMEK) replace Google-managed keys for selected data with keys stored in Cloud Key Management Service (Cloud KMS) as software-protected keys or hardware-protected keys with Cloud HSM, but managed by the customer. With Cloud KMS Autokey, a developer requests a key from Cloud KMS and the service agent provisions a consistent key on demand that follows industry-standard practices, avoiding manual key pipelines that add cost, latency, and complexity.
This separation preserves strict isolation because key ownership stays with the customer while data processing stays with the service. Revoking or restricting the CMEK key in Cloud KMS removes the ability to decrypt the protected data at rest without changing IAM grants on the data itself. For planning, the documentation points to the Sensitive Data Protection overview for discovery and classification workflows that complement encryption when mandates require identification of sensitive fields before applying residency and access controls.
Audit coverage proves that governance and protection controls are operating as required. Cloud Audit Logs for regulated APIs distinguish Admin Activity audit logs, which record ADMIN WRITE operations that write metadata or configuration, from Data Access audit logs, which record ADMIN READ operations that read metadata or configuration plus DATA READ and DATA WRITE operations that read or write user-provided data. Storing Gemini prompts and responses in a Cloud Logging bucket, viewing event logs in Logs Explorer, and monitoring performance in Cloud Monitoring extend that coverage from configuration changes to data usage.
Provider-access transparency and continuous framework monitoring complete the compliance mapping. Access Approval lets customers approve or dismiss requests for access by Google personnel, while Access Transparency logs provide near real-time records when Google Cloud administrators access resources. Security Command Center with Compliance Manager can deploy frameworks such as FedRAMP Low 20x to detect issues like privilege escalations and trigger alerts and playbooks for security operations analysts.
ADMIN_WRITE and cannot be disabled, while Data Access ADMIN_READ, DATA_READ, and DATA_WRITE are disabled by default except for BigQuery and must be enabled at the folder or organization level.VPC_SC_RESTRICTION unless the Security Center Service Agent has explicit ingress or egress access.Admin Activity audit logs record ADMIN_WRITE operations that write metadata or configuration information and cannot be disabled, while Data Access audit logs record ADMIN_READ, DATA_READ, and DATA_WRITE operations and are disabled by default except for BigQuery and must be explicitly enabled. Data Access audit logs should be enabled at the folder or organization level so the configuration flows down to all child projects for consistent coverage.
Aggregated sinks created at the folder or organization level should be used to collect filtered log entries from all child projects into one central log bucket or project for long-term retention. This central collection prevents gaps when new projects are created and separates audit storage from workload projects.
VPC Service Controls (VPC-SC) denies cross-perimeter data movement even when Identity and Access Management (IAM) would otherwise allow the call, so a request must pass both the IAM check and the perimeter check before data flows. Traffic from inside the perimeter to a protected service is allowed by default, while traffic that crosses the perimeter boundary is denied unless an explicit ingress or egress allowlist permits it.
A financial enterprise is subject to strict regulatory compliance mandates governing data residency, cryptographic boundary isolation, and access governance. The security team needs to enforce the following controls across their Google Cloud environment:
Which combination of controls and Organization Policies should the enterprise implement?
Last updated