Design, migrate, and run scalable, highly available databases on Google Cloud across relational and NoSQL services, and track your readiness for the Professional Cloud Database Engineer exam.
Prepare and test your skills
Prepare and test your skills
Cloud Audit Logs (opens in a new tab) is the Google Cloud service that records who did what, where, and when on Google Cloud resources. Log entries are written by Google Cloud services to Cloud Logging for each project, folder, and organization, and entries are immutable once written. For managed databases such as Cloud SQL, Spanner, and Bigtable, the same categories separate control-plane administration from data-plane access.
Admin Activity audit logs record user-driven API calls and other actions that modify the configuration or metadata of resources. Examples include creating a Cloud SQL instance, restoring a backup, updating an instance, changing Identity and Access Management (IAM) permissions, or creating a virtual machine instance. These logs show who changed infrastructure and when the change occurred.
Admin Activity logs are always written and cannot be configured, excluded, or disabled. They are generated even if the Cloud Logging API is disabled. Because the control plane writes these logs automatically, they provide baseline auditing for every managed service without manual configuration.
Data Access audit logs record user-driven operations that read configuration or metadata and operations that read or write user-provided data. These logs provide deeper visibility than Admin Activity logs, including reads such as getting instance details and data operations such as listing databases, getting users, exporting data, or creating and deleting databases. In Cloud SQL, the log category follows the IAM permission type required by the method.
ADMIN_READ generates Data Access logs for operations that read configuration, such as cloudsql.backupRuns.get, cloudsql.instances.get, cloudsql.instances.list, and cloudsql.operations.get.DATA_READ generates Data Access logs for operations that read user-provided data or database metadata, such as cloudsql.databases.get, cloudsql.databases.list, cloudsql.users.get, and cloudsql.instances.export.DATA_WRITE generates Data Access logs for operations that modify user-provided data, such as cloudsql.databases.create and cloudsql.databases.delete.Data Access logs are disabled by default and must be explicitly enabled through IAM audit configuration. Enabling them increases log volume and cost, so they are used when compliance or investigation requires visibility into reads and data-level writes. Access to these logs is also more restricted than access to Admin Activity logs.
Exam tip: ADMIN_WRITE permissions generate Admin Activity logs, while ADMIN_READ, DATA_READ, and DATA_WRITE permissions generate Data Access logs that must be explicitly enabled.
System Event audit logs record automated actions by Google Cloud systems that modify the configuration of resources. These entries are not driven by direct user action and sit on the Google-owned side of the management boundary, while Admin Activity and Data Access logs sit on the customer-action side. System Event logs identify maintenance, failover, and other automated platform operations that affect resource configuration.
System Event logs cannot be deactivated. Like Admin Activity logs, they are always available for visibility into platform-initiated changes without manual configuration.
Default states and access rules for audit logs determine which logs exist automatically and who can read them. The three categories differ in what triggers them and whether configuration is required.
| Log category | What it records | Default state |
|---|---|---|
| Admin Activity audit logs | User-driven writes to configuration or metadata | Always enabled, cannot be disabled |
| Data Access audit logs | User-driven reads of configuration and reads or writes of user data | Disabled by default, requires explicit enablement |
| System Event audit logs | Google system-driven changes to resource configuration | Always enabled, cannot be disabled |
Viewing and storing these logs depends on Cloud Logging buckets and IAM roles. Admin Activity, System Event, and Policy Denied logs can be read with the Logs Viewer role (roles/logging.viewer). A holder of only Logs Viewer cannot view Data Access logs stored in the _Default bucket. The Private Logs Viewer role (roles/logging.privateLogViewer) includes Logs Viewer permissions plus permission to read Data Access logs in the _Default bucket, and grants access to all logs in the _Required and _Default buckets. For Cloud SQL, audit entries can be isolated in Logs Explorer with the filter protoPayload.serviceName="cloudsql.googleapis.com".
Cloud Audit Logs compared with database-engine auditing is the distinction between management-API auditing and in-database SQL auditing. Cloud Audit Logs audit administrative and maintenance operations performed on a Cloud SQL instance through the Google Cloud control plane. Database-engine auditing audits SQL commands and queries executed inside the database itself.
For Cloud SQL for PostgreSQL, in-database auditing uses the pgAudit (opens in a new tab) extension, which selectively records SQL operations defined by flags such as cloudsql.enable_pgaudit and pgaudit.log. For Cloud SQL for SQL Server, in-database auditing uses SQL Server Audit (opens in a new tab), which writes audit files first to instance disk and then uploads them to a Cloud Storage bucket on a configured retention and upload interval. Choose Cloud Audit Logs when the question is who called the management API to create, update, restart, or delete resources, and choose engine auditing when the question is which SQL statement ran inside the database.
Analysis of Data Access auditing and granularity is the process of deciding which data interactions to log and how much detail to keep. Cloud Audit Logs (opens in a new tab) records who did what, where, and when across Google Cloud resources, and Data Access audit logs are the part that records user-driven access to data and configurations. Unlike administrative logs that are always on, Data Access logs are disabled by default and must be explicitly enabled, which forces a tradeoff between detailed visibility and higher log volume and storage cost.
Monitored operations in Data Access audit logs are user-driven operations that read or change resource data and configuration. For managed database services, this coverage answers which principal accessed which database resource and when, supporting compliance, operational transparency, and investigation of data misuse. Log entries written by Cloud Audit Logs are immutable, so recorded access cannot be altered after it is written.
Data Access auditing is divided into three subtypes that control granularity:
Enabling only ADMIN_READ gives lightweight visibility into metadata access, while adding DATA_READ and DATA_WRITE gives full visibility into user queries at the cost of much larger log volume. A single request can generate more than one entry because entries are created based on the IAM permissions checked during the request.
Comparison of Data Access logs with other audit log types shows why database auditing policies must combine multiple types rather than relying on one type alone. Each type has a different source and default behavior in a project, folder, and organization.
| Log type | What it records | Enabled by default |
|---|---|---|
| Admin Activity audit logs | User-driven API calls or actions that modify configuration or metadata, such as creating an instance or changing IAM permissions | Yes; always written and cannot be configured, excluded, or disabled, even if the Cloud Logging API is disabled |
| Data Access audit logs | User-driven reads and writes to data and reads of configuration not tracked as Admin Activity | No; must be explicitly enabled through IAM audit configuration |
| System Event audit logs | Changes made by Google Cloud systems, not driven by direct user action | Yes; generated by the system |
Admin Activity logs track administrative control-plane changes, while Data Access logs track the data-plane interactions that show actual database use. System Event logs complete the picture by showing system-initiated changes that no user directly requested.
Configuration choices that control granularity, volume, and cost are set in the IAM AuditConfig object for a specific service. An administrator enables auditing for a service and selects whether ADMIN_READ, DATA_READ, and DATA_WRITE are recorded. This per-service, per-subtype control lets a team enable DATA_WRITE for all databases while limiting high-volume DATA_READ to only regulated datasets.
Greater granularity directly increases log volume, ingestion, and storage cost because every read and write can create an entry. Teams balance this by allocating audit log storage capacity in advance, exporting logs through a log sink to Cloud Storage or another destination for long-term storage, and defining retention policies with Bucket Lock to meet compliance retention. For Cloud SQL for MySQL (opens in a new tab), which does not provide Oracle-style standard and fine-grained auditing by default, Cloud Audit Logs should be combined with database flags that enable the slow-query log and general log to capture DML and DDL statements, with retention managed according to business needs.
Exam tip: Admin Activity logs are always on and cannot be disabled, while Data Access logs for ADMIN_READ, DATA_READ, and DATA_WRITE are off until explicitly enabled.
Viewing rules and protection for Data Access audit logs control who can see sensitive access records. A principal with the Logs Viewer role (roles/logging.viewer) gets read-only access to Admin Activity, Policy Denied, and System Event logs but cannot view Data Access logs stored in the _Default bucket. Access to all logs in the _Required and _Default buckets, including Data Access logs, requires the Private Logs Viewer role (roles/logging.privateLogViewer), which includes all Logs Viewer permissions plus permission to read private Data Access entries.
Because audit logs provide unique accountability for who accessed sensitive data, access to the logs themselves must be restricted to authorized personnel. Centralizing logs from all sources, monitoring for anomalous access patterns, and creating log-based alerts for suspicious API activity help security teams detect misuse without granting broad access to the raw audit data.
Governance, retention, and security of audit telemetry is the practice of keeping a complete, tamper-resistant record of who did what, where, and when in Google Cloud. Cloud Audit Logs stores information about the actions users take, where the activity occurred, and when it occurred. Audit telemetry flows from Google Cloud services into Cloud Logging, and from Cloud Logging through log sinks to long-term destinations for compliance, analysis, and protection against exfiltration.
Audit log categories and their default protections define four peer types that support forensics, access-pattern analysis, and breach investigation:
Admin Activity audit logs are the foundation for identity lifecycle governance because they capture service account creation, IAM policy changes with SetIamPolicy, service account key downloads, and new key generation. Policy Denied audit logs complement them by showing attempted access that policy blocked. Admin Activity audit logs are always written and cannot be configured, excluded, or disabled, even if the Cloud Logging API is disabled.
Exam tip: Admin Activity audit logs are always written and cannot be disabled, while other categories such as Data Access must be explicitly enabled and configured.
Export paths and long-term retention for compliance address the limited retention period of audit logs in Cloud Logging. When an organization or legal requirement needs storage beyond the default retention period, the organization must create a log sink that routes log entries to a separate destination for long-term storage. Exporting logs to BigQuery lets teams view selected columns over time, run aggregate analysis of security and access patterns, and monitor slot and permission usage with dashboards. Sinks can also route to Cloud Storage or Pub/Sub for archival storage or streaming delivery.
Retention controls also apply to the log buckets that hold the logs before export. Retention policies on log buckets configured with Bucket Lock prevent early deletion and support compliance checks that sinks are configured for all log entries. Centralized collection strengthens this model by sharing Cloud Identity and Google Workspace Admin Activity audit logs, such as user login events, into the Google Cloud environment so all sources are managed together.
Identity and Access Management (IAM) (opens in a new tab) controls for audit data determine who can view, query, and manage log data and its destinations. In BigQuery, IAM grants roles on organizations, projects, datasets, tables, and views, where datasets are child resources of projects and tables inherit permissions from their dataset. Access is granted by assigning roles to users, groups, or service accounts, with organization and project roles controlling job execution and management and dataset roles controlling access to the data itself.
BigQuery IAM provides three role patterns for least-privilege governance:
Fine-grained protection extends beyond project and dataset roles through column-level access controls, row-level access controls, and data masking, which obscure sensitive columns, rows, or patterns while permitting access to surrounding data. Operational transparency is maintained by monitoring with log-based alerts for suspicious API requests, such as unauthorized creations or IAM privilege escalations, and by reviewing Policy Analyzer results and IAM recommender insights on a periodic basis.
VPC Service Controls (opens in a new tab) is the control that prevents data exfiltration by placing a virtual network boundary around Google Cloud resources and their audit and database data. A service perimeter defines the virtual boundaries from which a service can be accessed, so data cannot be moved outside those boundaries. The control applies to API movement paths, including restricting use of the Cloud SQL Admin API and Cloud Storage API to import and export data, which helps enforce data residency in selected regions.
The perimeter enforces its boundary even when the requester is authorized by IAM policy, so IAM authorization alone does not permit movement outside the perimeter. Traffic from inside the perimeter to an allowed service stays permitted, while traffic that would copy audit telemetry or database exports to an outside project or location is denied. Choose VPC Service Controls when the requirement is to contain audit logs and managed database exports within approved networks and regions despite valid credentials.
ADMIN_WRITE permissions generate Admin Activity logs, while ADMIN_READ, DATA_READ, and DATA_WRITE permissions generate Data Access logs.roles/logging.privateLogViewer) is required to read Data Access logs in the _Default bucket, while the Logs Viewer role (roles/logging.viewer) cannot read those entries.Last updated