Cloud Logging and Cloud Monitoring are often mentioned together because they are both part of GCP's observability suite, formerly called Stackdriver. But they serve different purposes and the Associate Cloud Engineer exam tests whether you can tell them apart when a scenario describes a specific operational problem. Reaching for Logging when you need Monitoring, or vice versa, leads to wrong answers on questions that are otherwise straightforward.
Cloud Logging stores, searches, and analyzes log data from GCP resources and applications. Logs are records of discrete events: a request came in, an error occurred, an admin made a configuration change, a VM started. Each log entry has a timestamp, a severity level, a resource identifier, and a message.
GCP services write logs to Cloud Logging automatically. Compute Engine VMs generate system event logs. Cloud Run services log request details and application output. IAM records administrative actions. You can also write custom log entries from your applications using the Cloud Logging client libraries or the logging agent.
The Cloud Logging console lets you filter, search, and analyze log entries. You can filter by resource type, severity, time range, and custom fields. You can create log-based metrics that turn log entry patterns into numeric measurements. And you can set up log sinks to export logs to Cloud Storage, BigQuery, or Pub/Sub for longer retention or analysis.
Default log retention in Cloud Logging is 30 days. After that, logs are deleted unless you have configured a log sink to export them elsewhere. For compliance requirements that mandate longer retention, a log sink to a Cloud Storage bucket with an appropriate storage class is the standard pattern.
Cloud Monitoring collects, analyzes, and visualizes metrics from GCP resources and applications. Metrics are numeric measurements that change over time: CPU utilization percentage, memory usage, request latency in milliseconds, error rate per minute. Unlike log entries, which are individual events, metrics are time series data that you aggregate and analyze over intervals.
GCP automatically collects hundreds of built-in metrics from all managed services. Compute Engine VMs report CPU utilization, disk I/O, and network throughput. Cloud SQL instances report connection count, query latency, and storage usage. Cloud Run services report request count, response latency, and instance count. You can also define custom metrics for application-specific measurements that GCP does not track by default.
Cloud Monitoring's primary action mechanism is alerting. You define an alerting policy that watches a metric and triggers a notification when the metric crosses a threshold. CPU utilization above 90 percent for five minutes triggers an email. Error rate above one percent triggers a PagerDuty alert. Request latency above two seconds triggers a Slack message. The notification channels integrate with common on-call and incident management tools.
Dashboards in Cloud Monitoring let you visualize multiple metrics on a single screen. You can create custom dashboards that combine metrics from different services to give you a unified view of your system's health.
Cloud Monitoring supports monitoring multiple GCP projects from a single workspace. You designate one project as the host project for the monitoring workspace and link other projects to it. All linked projects' metrics appear in the single dashboard. This is the standard pattern for organizations with multiple projects that want unified observability without switching between project consoles.
The Associate Cloud Engineer exam tests this capability in scenarios involving multi-project environments. When a question describes a company with separate projects for development, staging, and production that wants a single monitoring dashboard, the answer involves setting up a Cloud Monitoring workspace in one project and linking the others.
The simplest distinguishing rule: if the scenario involves records of events, errors, or user actions, it is a Logging question. If the scenario involves numeric measurements, thresholds, and automated alerts, it is a Monitoring question.
Logging answers scenarios like: "Find all requests that returned a 500 error in the last hour," "Track which admin changed the firewall rule," "Export application logs for compliance." Monitoring answers scenarios like: "Alert when CPU exceeds 90 percent," "Track request latency over time," "Create a dashboard showing all services' health metrics."
Both tools can feed into each other. Log-based metrics turn log patterns into Monitoring metrics. Cloud Monitoring can trigger actions when a log-based metric crosses a threshold. But for the exam, the tool you reach for first depends on whether you are dealing with events (Logging) or measurements (Monitoring).
Log-based metrics are the bridge between Cloud Logging and Cloud Monitoring. You define a filter in Cloud Logging that matches specific log entries, and Cloud Logging turns the count (or extracted values) of those matching entries into a metric in Cloud Monitoring. This metric can then be used in alerting policies and dashboards just like any built-in metric.
A practical example: you want to be alerted when your application logs the phrase "database connection failed" more than five times in a minute. There is no built-in Cloud Monitoring metric for that because it is specific to your application's log messages. You create a log-based metric that counts log entries matching that phrase, then create a Cloud Monitoring alerting policy that fires when the log-based metric exceeds five in sixty seconds.
This combination is powerful because it lets you build monitoring coverage for application-level events that GCP cannot monitor on its own. The Associate Cloud Engineer exam tests whether you understand that Logging handles the event record and Monitoring handles the measurement and alerting, with log-based metrics being the mechanism that connects them. When a question asks how to alert on a specific log pattern, the answer involves creating a log-based metric and then a Monitoring alerting policy against it, not trying to create an alert directly in Cloud Logging.
My Associate Cloud Engineer course covers the observability suite in full, including the specific alerting and log analysis scenarios that appear most frequently on the Associate Cloud Engineer exam.
