Audit Logs, Cloud Logging, and Compliance-Oriented Monitoring

Why Logs Matter

In Google Cloud, almost every meaningful action is recorded. For security and compliance, you must know what is logged, where to find it, and how to use it during operations and incidents.

Three Pillars

We focus on three pillars: audit logs (who did what), Cloud Logging (view and route logs), and Cloud Monitoring (metrics and alerts from logs and resources).

Compliance Angle

Regulations like GDPR, ISO 27001, SOC 2, HIPAA, and PCI DSS require evidence of access, configuration changes, and timely detection of suspicious activity.

Tools in Google Cloud

Cloud Audit Logs capture admin and data access events, Cloud Logging stores and queries them with IAM-based access, and Cloud Monitoring turns them into alerts and dashboards.

Exam Relevance

Expect questions on audit log types, filtering IAM and security events, exporting logs to Cloud Storage or BigQuery, and designing investigation workflows using these tools.

What Are Cloud Audit Logs?

Cloud Audit Logs record activity in your projects, folders, and organizations. You must know the main categories and where they live for both the exam and real operations.

Admin Activity Logs

Admin Activity logs record configuration changes, such as creating VMs, editing firewall rules, or modifying IAM policies. They are always enabled and free within quotas.

Data Access Logs

Data Access logs record API calls that read or write user data, like reading Cloud Storage objects or BigQuery queries. They may be disabled by default and can be enabled per service.

System Event & Policy Denied

System Event logs capture Google-managed operations (like autoscaling). Policy Denied logs capture requests blocked by org policies or VPC Service Controls before reaching services.

Log Names and Scope

Find them in Logs Explorer by filtering `cloudaudit.googleapis.com`. Example: `...%2Factivity`, `...%2Fdataaccess`, `...%2Fsystemevent`, `...%2Fpolicy`, all scoped to a project, folder, or org.

Scenario A: Firewall Change

You want to know who changed a firewall rule. In Logs Explorer, select the project, filter for `cloudaudit.googleapis.com/activity`, and target firewall-related method names like `compute.firewalls.patch`.

Firewall Change Query

Example query:

```

logName = "projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity"

protoPayload.methodName = "v1.compute.firewalls.patch"

```

Inspecting Firewall Logs

Open a log entry and look at `protoPayload.authenticationInfo.principalEmail` (who), plus `request` and `response` fields (what changed in the firewall rule).

Scenario B: Storage Object Access

To see who read an object in a sensitive bucket, filter Data Access logs for `gcs_bucket` and method `storage.objects.get` targeting your bucket name.

Storage Access Query

Example query:

```

logName = "projects/PROJECTID/logs/cloudaudit.googleapis.com%2Fdataaccess"

protoPayload.serviceName = "storage.googleapis.com"

protoPayload.methodName = "storage.objects.get"

resource.labels.bucketname = "SENSITIVEBUCKET_NAME"

```

IAM Controls Log Access

Logs can be sensitive, so access is controlled by IAM at the project, folder, or org level. IAM defines who has what role for which resource.

Key Logging Roles

Logs Viewer can read logs. Logs Writer lets services or service accounts write logs. Logs Admin manages all logging configs and data.

Private Logs Viewer

Private Logs Viewer can view all logs, including sensitive Data Access logs. Many orgs restrict this to security or compliance teams.

Log Sinks and Service Accounts

When you create a log sink, Cloud Logging creates a sink-specific service account. You must grant it access (for example, to write to a Cloud Storage bucket).

Service Accounts in Logs

When workloads run under a service account, that identity appears as `principalEmail` in audit logs, linking back to your service account and Workload Identity design.

Why Export Logs?

Default Cloud Logging retention is limited. Compliance often needs years of history and deeper analytics, so you export logs for long-term storage and reporting.

Export to Cloud Storage

Use Cloud Storage for low-cost archival of audit logs. Combine with Object Lifecycle Management and storage classes like Standard, Nearline, Coldline, and Archive.

Export to BigQuery

Use BigQuery for interactive analysis and reporting. Run SQL to list IAM changes, data access events, or other compliance-focused queries over long periods.

Export via Pub/Sub

Export to Pub/Sub for real-time streaming into SIEM tools or custom processors. This is useful for centralized security monitoring across platforms.

Creating a Log Sink

In Logs Router, create a sink, choose a destination, define a filter (for example, audit logs), and then grant the sink service account permission on the destination.

Why Cloud Monitoring?

Cloud Logging stores events, but Cloud Monitoring turns them into actionable alerts and dashboards using metrics, uptime checks, and alerting policies.

Log-Based Metrics

You can define log-based metrics that count or measure events matching a log filter, such as IAM policy changes or repeated permission denied errors.

Unusual API Activity

Example: create a log-based metric for audit logs where `methodName` contains `setIamPolicy`, then alert if the count exceeds a threshold in a short time window.

Resource Change Monitoring

Monitor creation or deletion of VMs, firewall rules, or buckets. Alerts on spikes can reveal compromised accounts or misbehaving automation.

From Logs to Alerts

Typical pipeline: Logs → Log-based metric → Alerting policy → Notification channels (email, SMS, PagerDuty, etc.). This is a frequent exam pattern.

Start from the Alert

Cloud Monitoring fires an alert about high IAM policy change activity. First, confirm details: metric, threshold, and time window, and review related dashboards.

Investigate in Logs Explorer

Filter Admin Activity logs for `setIamPolicy` in the project and time window. Sort by time and look for unusual patterns like bursts of changes or odd hours.

Identify the Actor

Inspect `protoPayload.authenticationInfo.principalEmail` to see which user or service account made the changes, and whether that identity is expected.

Understand the Change

Review `protoPayload.request` to see which roles and members were added or removed. Watch for risky grants like `roles/owner` or large groups.

Check Data Access & Remediate

Search Data Access logs for that identity to see if sensitive data was accessed. Then roll back bad changes, rotate credentials, and document the incident.