Cloud Logging is the Google Cloud service that lets you store, search, and analyze log data and events generated by your Google Cloud resources and applications. It was formerly named Stackdriver Logging, and you may still see that name in older material, but the functionality is the same. It integrates with Cloud Monitoring, which is what allows you to run analytics over your log data and set up automated alerts that notify you when something unusual happens. For the Professional Cloud Database Engineer exam, the parts worth knowing well are the categories of logs that get ingested, how long different logs are retained, and how log sinks move logs out to other destinations for analysis or long-term storage.
Cloud Logging ingests three core types of logs. Platform logs originate directly from Google Cloud services themselves. These give you insight into the operation of the resources you are running, such as Compute Engine instances, Cloud SQL databases, and GKE clusters, and they help you understand the health and performance of those resources. Application logs are generated by your own code running on Google Cloud. They capture application-specific events and errors and give you visibility into the internal workings of your applications, which is what makes them useful for debugging. Audit logs record user and system activities, including data access, administrative actions, and API calls, which is the information that matters for security and compliance.
For a database engineer, this maps cleanly onto a managed database like Cloud SQL. The platform logs tell you about the database service itself, the application logs come from the code that talks to the database, and the audit logs tell you who accessed or changed the data and configuration.
Retention matters for two reasons that pull in opposite directions. You need enough history to satisfy regulatory requirements, but keeping every log indefinitely raises storage costs, so the goal is a reasonable balance. Cloud Logging draws a distinction between default logs and compliance and audit logs, and the two are stored in different buckets with different rules.
Default logs are stored in the _Default bucket within your project. This bucket holds things like Data Access logs, which track when your data is read or written, Policy Denied logs, which record when an action is blocked by your security settings, and the general run of logs produced by your applications and by Google Cloud services as they operate. The default retention period for this bucket is 30 days, which is usually enough for immediate troubleshooting. If you need more history, retention for project-level logs is configurable from 1 to 3650 days.
Compliance and audit logs follow stricter rules so that they remain available for regulatory and audit purposes. These are stored in the _Required bucket rather than the default one. The bucket holds Admin Activity audit logs, which track configuration changes to your resources, System Event audit logs, which record administrative actions taken by Google Cloud itself, and Login audit logs, which keep track of who is accessing your environment. The retention period for the _Required bucket is fixed at 400 days, and custom retention is not configurable for it. That fixed 400-day figure and the contrast with the configurable 1-to-3650-day range for default logs are the kind of details the exam tends to test, so it is worth keeping them straight.
A log sink is an export destination for your logs, defined by a filter you set. The filter decides which logs get routed, and the sink decides where they go. The log source can be any Google Cloud service, such as Compute Engine, Cloud Run, or Cloud SQL. Those services generate logs that Cloud Logging collects, and within Cloud Logging you configure a sink to direct specific logs onward. Common destinations are Cloud Storage for long-term storage, BigQuery for analysis, and Pub/Sub for triggering downstream workflows or integrations.
Two use cases drive most sink configurations. The first is retaining logs for compliance and auditing, where you need to meet legal requirements for how long data is kept. The second is storing logs in BigQuery so you can query them and extract insights. A concrete database-adjacent example is exporting DAG execution logs from a managed Airflow environment into BigQuery, or sending error logs from Compute Engine to a Cloud Storage bucket for long-term archiving.
When you need to keep audit logs well beyond the bucket retention periods, the usual pattern is to set up an export sink to a Cloud Storage bucket and choose a storage class that fits how often you will actually read the data. For compliance logs that you rarely access but must keep for an extended period, the Coldline storage class is a reasonable fit. If your access frequency is even lower, on the order of once a year or less, Archive storage is the more cost-effective option, since it stores the data securely and lets you retrieve it when you need to. When you are managing several projects, consolidating their logs into a single Cloud Storage bucket simplifies log management and makes it easier to demonstrate compliance across all of them.
Tying it together, the way to reason about a logging question on the Professional Cloud Database Engineer exam is to identify which log type is involved, recall which bucket it lands in and what its retention rule is, and then decide whether a sink to BigQuery for analysis or to Cloud Storage for archiving is what the scenario is actually asking for.
Our Professional Cloud Database Engineer course covers Cloud Logging alongside Cloud Monitoring and database auditing, with practice questions that drill these distinctions.
