Prepare and test your skills
Prepare and test your skills
Manage Access and Security for Centralized Observability controls who can view, configure, and administer logs and metrics that are collected from many Google Cloud projects. Log entries flow from workload projects through organization-level sinks into a central log bucket in Cloud Logging (opens in a new tab), while time-series data flows into a scoping project through a metrics scope in Cloud Monitoring (opens in a new tab). Because both central destinations concentrate sensitive operational and audit data, access is limited by Identity and Access Management (IAM) roles, group membership, retention locks, and continuous monitoring of access changes.
Central administrators for observability are the identities allowed to manage the central log bucket and the central scoping project. These administrators hold the Logging Admin (roles/logging.admin) and Monitoring Admin (roles/monitoring.admin) roles through membership in purpose-built groups such as gcp-organization-admins@YOUR_DOMAIN, gcp-security-admins@YOUR_DOMAIN, or gcp-logging-monitoring-admins@YOUR_DOMAIN. This group-based model keeps ownership of routing, retention, and metrics scope membership with platform, security, and observability administrators. Workload teams receive narrower permission to view only their own logs and metrics, so they cannot change central routing or retention.
Separation of duties with Identity and Access Management (IAM) means no single user or team can both use privileged identities and hide that use from audit logs. IAM policies apply at the organization, folder, and project levels, so controls set at the organization boundary constrain what project-level grants can allow. Development, security, and operations teams are placed in different groups with least-privilege roles, and group membership is monitored to prevent non-corporate accounts from gaining policy-carrying membership.
Centralized access depends on several IAM hygiene guardrails:
When these boundaries hold, a developer who can deploy code cannot also grant central log access, and a security administrator who can read audit logs cannot also modify the keys that protect them.
The central log bucket in Cloud Logging is the tamper-evident store for organization-level audit logs that supports security, auditing, and compliance analysis. Sinks route log entries from every project in the organization to this single bucket, which is created in a selected region with a defined retention period. By default logs are stored for 30 days, 365 days is recommended for large enterprises, and storage beyond 30 days incurs retention cost. Retention policies configured with Bucket Lock make the audit trail immutable for its retention window, so even privileged administrators cannot delete evidence early.
Different audit log types have different enablement rules for central export:
| Log type | Records | Enablement for central export |
|---|---|---|
| Admin Activity | API calls that modify resource configuration or metadata | Always written; included by default when routed |
| System Event | Google Cloud actions that modify resource configuration | Included by default when routed |
| Access Transparency | Google personnel access to customer content | Included by default when routed |
| Data Access | Reads of configuration or metadata and user-driven reads or writes of user data | Exported only if enabled in source projects |
| Policy Denied | Service denials to users or service accounts due to policy violations | Exported only if enabled in source projects |
Exam tip: Admin Activity logs cannot be disabled or excluded, while Data Access and Policy Denied logs must be explicitly enabled before a central sink can export them.
Metrics scope visibility control defines which projects are visible from a central scoping project without moving the underlying metric data. By default, Cloud Monitoring pages show only time-series data stored in the scoping project selected in the console picker. The scoping project also stores the alerts, synthetic monitors, and dashboards configured for central operations, while the attached metrics scope defines the additional Google Cloud projects and AWS accounts whose metrics are visible. Projects created during organization setup are added when central monitoring is selected, and projects created later are added by configuring the metrics scope.
This design preserves a trust boundary between workload ownership and central visibility. Workload projects retain ownership of their resources and their local view, while the scoping project depends on metrics scope membership to read cross-project time series for health, performance, and security analysis. Removing a project from the metrics scope immediately removes its metrics from the central view without deleting data in the source project.
Alerts for access and policy changes turn the central log bucket from passive storage into active enforcement of compliance requirements. Log-based metric filters watch the aggregated Admin Activity stream and trigger alerts when sensitive IAM or network controls change. Coverage includes project ownership assignments, audit configuration changes, custom role changes, VPC firewall rule changes, route and network changes, Cloud Storage IAM permission changes, and SQL instance configuration changes. Because sinks are configured for all log entries, these signals are preserved centrally even if a project-level actor tries to alter local logging.
Monitoring of identity use completes the loop between access grants and audit trails:
Together, immutable storage with Bucket Lock, organization-wide audit logging, and alerts on every change to ownership, roles, and audit configuration maintain a continuous audit trail.
Architect Log Aggregation and Centralized Analysis is the design of routing log entries from many projects, folders, and organization resources into one analysis destination. Cloud Logging (opens in a new tab) performs the routing through log sinks, while Observability Analytics, BigQuery (opens in a new tab), Pub/Sub (opens in a new tab), and Cloud Storage (opens in a new tab) provide the central repositories where logs are stored, queried, and exported. An organization-level design preserves the audit trail for security and compliance while giving operators one place to search, retain, and alert on logs.
The central Logging bucket is the recommended aggregation point for organization-level audit logs and operational logs from Google Cloud, applications, on-premises resources, and other clouds. The bucket lives in a designated central project selected in the Google Cloud console under Central logging and monitoring, and all child projects route copies of their logs to that bucket. By default logs are stored for 30 days, large enterprises are recommended to retain logs for 365 days, and custom retention can be configured from 1 day to 3650 days with retention costs applying beyond 30 days. Bucket region controls where log data is physically stored and cannot be changed after the bucket is created.
Supported bucket locations include global, us, and eu, with global used when no location is specified. Use a dedicated bucket for centralized analysis rather than the _Default bucket, and upgrade that bucket to use Observability Analytics when long-term SQL-based investigation is required. This separation keeps central audit and operational analysis independent from default per-project storage.
An aggregated sink is a log sink created at the organization or folder level that captures matching log entries from that resource and all current and future child projects. Log entries flow from the source projects to the sink, the sink applies its inclusion filter to select which entries to forward, and the sink then writes the selected entries to its single configured destination. This inheritance model means new projects are automatically covered without creating per-project sinks, which is the core dependency for organization-wide observability.
Building the routing path follows an ordered workflow:
gcloud logging buckets create or the central BigQuery dataset with bq mk in the aggregation project.Exam tip: If a central Logging bucket or BigQuery dataset with an aggregated sink already exists, do not create a second sink — update the existing sink inclusion filter and, for Observability Analytics, upgrade the existing bucket.
Central destinations for analysis and export determine the routing path from source projects and the type of analysis that follows aggregation. Observability Analytics and BigQuery both use only an aggregated sink, while Google Security Operations and third-party tools add direct-ingest or intermediate export steps. The choice depends on whether the team needs central search, long-term SQL joins, built-in security ingest, or export outside Google Cloud.
| Destination | Routing path from source projects | Choose when |
|---|---|---|
| Observability Analytics in a Logging bucket | Log entries flow from projects through an aggregated sink directly to the central Logging bucket | Central search, real-time troubleshooting, and log-based alerting in Cloud Logging are needed |
| BigQuery dataset | Log entries flow from projects through an aggregated sink directly to the central BigQuery dataset | Long-term SQL analysis, joins with business data, and custom retention by partitioned table are needed |
| Google Security Operations direct ingest | Predefined exportable logs flow automatically through built-in ingest without a sink | The predefined subset of security logs meets the need and no custom filter is required |
| Third-party SIEM | Log entries flow from projects through an aggregated sink to Pub/Sub or Cloud Storage, then are pulled into the external tool | Logs must leave Google Cloud for multi-cloud correlation, Splunk streaming, or an external SIEM |
For export outside Google Cloud, the sink writes to a Pub/Sub topic identified by a topic ID, and subscribers pull from that topic with pull subscriptions. Filters can limit which log types are exported to control cost and reduce noise in the external system.
Volume, retention, and cost controls use inclusion filters and exclusions to decide which log entries consume storage and reach the central destination. The inclusion filter on the aggregated sink selects the log types to forward, and entries are exported only if those log types are actually enabled in the source projects or resources. Exclusions discard noisy or low-value entries before storage, which is especially important because Data Access audit logs can be large and can push projects over free allotments.
Centralized designs typically distinguish five audit and transparency log types:
Admin Activity, System Event, and Access Transparency are recommended for routine central export, while Data Access and Policy Denied are added selectively because of volume and cost. A common pattern is to exclude Data Access logs from development projects while retaining them for authentication services, storage services holding user data, and infrastructure services holding metadata. Retention rules apply to the entire bucket regardless of log type, encryption defaults to Google-managed encryption at rest, and customer-managed encryption keys (CMEK) can be configured when the organization must control its own keys.
Access separation and centralized alerting for logs keep sink write permission distinct from analyst read permission across the trust boundary between source projects and the central project. Setup requires the Logging Admin (roles/logging.admin) and Monitoring Admin (opens in a new tab) (roles/monitoring.admin) roles, or membership in an admin group such as gcp-organization-admins, gcp-security-admins, or gcp-logging-monitoring-admins. The sink writer identity must be granted write access to the destination, while human and service identities are granted read access to the central bucket, dataset, or topic only as needed for investigation and compliance.
Cloud Monitoring provides centralized alerting by creating log-based alerting policies against the aggregated logs in the destination project. Log entries flow from multiple projects through the sink to the central destination, and the alerting policy evaluates the central query and notifies when a matching event appears. This allows one policy to distinguish immediate-investigation events, such as specific data-access or policy-denied messages, from low-priority events across the entire organization.
Configure Cross-Project Metrics and Dashboards is the practice of collecting, visualizing, and alerting on time-series data from multiple projects in one place. Cloud Monitoring (opens in a new tab) provides this single interface through a scoping project that hosts configuration and a metrics scope that defines which projects and accounts are visible. Charts, dashboards, and alerting policies created in the scoping project then operate against the combined set of visible metrics.
Metrics scope and scoping project ownership separate where metric data is stored from where it is viewed and managed. A metrics scope is the Cloud Monitoring construct that defines which Google Cloud projects and AWS accounts are visible to a scoping project. By default, Cloud Monitoring pages in the Google Cloud console show only time series stored in the scoping project, which is the project selected with the console project picker. Visibility is expanded by configuring the metrics scope to include time-series data from other Google Cloud projects and AWS accounts.
The scoping project is also the ownership boundary for observability configuration. The scoping project stores the dashboards, alerting policies, and synthetic monitors that are configured, while the underlying metric data remains stored in each monitored project and account. Central monitoring setup adds projects created during organization setup to the metrics scope of a designated scoping project, so health, performance, and security can be analyzed from one place without moving raw time series.
Exam tip: The scoping project stores dashboards, alerts, and uptime checks, while the metrics scope controls which monitored projects and AWS accounts those configurations can see.
Metric data available to cross-project views includes every metric type that Cloud Monitoring collects and stores, regardless of which monitored project produced it. Once a project is added to a metrics scope, its system, agent, custom, and derived metrics become selectable in the scoping project's charts, dashboards, and alerting policies. This allows a unified dashboard to combine infrastructure, application, and log-derived signals from across the resource hierarchy. Each time series carries its monitored resource, metric type, labels, and timestamped points, and resource labels include the source project_id so charts can filter and compare the same metric across projects.
Cloud Monitoring collects and stores the following metric data:
Because the source project identity travels with each time series, central queries preserve which project produced each point while still aggregating across the full scope.
A unified dashboard is a custom dashboard stored in the scoping project that visualizes metric and log data from every project in its metrics scope. Google Cloud-managed dashboards are created automatically for Google Cloud resources and App Hub applications and show curated health information, such as log or metric data and open alerts for an application and its services and workloads. When managed dashboards do not show trends, outliers, or cross-project comparisons, a custom dashboard is created to control exactly what data is viewed and how it is displayed.
Custom dashboards in the scoping project can display the following:
Custom dashboards can be created and managed by using the Google Cloud console or the API, by importing a Grafana dashboard, or by installing a dashboard from a template. The Metrics Explorer chart service supports rapid exploration with comparison of current data to previous data, display of outliers and percentiles, and display of multiple metrics on one chart, and charts built in Metrics Explorer can be saved directly to a custom dashboard.
Querying metrics across projects is driven by a query that selects time-series data from the metrics scope for every chart and alerting policy. In the Google Cloud console the query can be built by making selections from menus or by writing a query directly, with query editors for Prometheus Query Language (PromQL) that provide syntax checks and suggestions. The Cloud Monitoring API supports both PromQL and Monitoring filter expressions, so the same logic can run in the console and in automation.
| Query method | Supported interface | Behavior in cross-project use |
|---|---|---|
| Menu-built selection | Google Cloud console | Selects resources, metric types, and filters without writing syntax |
| PromQL | Google Cloud console and Cloud Monitoring API | Expresses complex selection, aggregation, and calculation over scoped time series |
| Monitoring filter expression | Google Cloud console and Cloud Monitoring API | Expresses resource and metric filters in Cloud Monitoring syntax |
The query executes against all time series visible through the scoping project's metrics scope. This means one expression can aggregate CPU utilization, request latency, or custom application metrics across many monitored projects, and the same query pattern can be reused in both a dashboard chart and an alerting policy.
A cross-project alerting policy stored in the scoping project evaluates metric conditions across the full metrics scope and sends notifications when defined criteria are met. Each alerting policy defines the performance condition and the list of people or groups to notify through notification channels such as email, Cloud Mobile App, PagerDuty, or Slack. For example, a single policy can notify on VM CPU utilization exceeding 80% across development, staging, and production projects that share one scope. Policies can be created and managed by using the Google Cloud console, the Cloud Monitoring API, the Google Cloud CLI, or Terraform.
Each notification links to an incident, which is a persistent record for troubleshooting that typically lists status, links to logs, a chart of recorded metric data, labels, and duration. The alerting service also integrates with many Google Cloud services through recommended alerts and chart-based creation, where the policy logic is pre-configured and only the notification recipients are supplied. The scoping project also stores synthetic monitors that validate availability from outside the application. Uptime checks probe HTTP, HTTPS, and TCP endpoints for responsiveness and generate notifications when an endpoint fails, while a broken-link checker crawls a web page and reports broken links. Because these monitors live in the scoping project, their results, incidents, and dashboard widgets sit alongside cross-project metrics for unified operations.
Centralized observability joins three dependencies into one operating model: IAM and retention locks protect the central stores, aggregated sinks move every required log to a single bucket or dataset, and the metrics scope brings every required time series into a single scoping project. When access is separated by role, routing covers current and future projects, and alerts watch both infrastructure signals and changes to the observability configuration itself, operations, security, and development teams share one trustworthy view without sharing unrestricted control.
The scoping project stores dashboards, alerting policies, uptime checks and synthetic monitors, while the metrics scope defines which Google Cloud projects and AWS accounts are visible to that scoping project. Metric data remains stored in each monitored project, so removing a project from the metrics scope removes its metrics from the central view without deleting data in the source project.
Admin Activity, System Event and Access Transparency logs are included by default when routed through an aggregated sink to the central Logging bucket. Data Access and Policy Denied logs are exported centrally only if enabled in the source projects, and Admin Activity logs are always written and cannot be disabled or excluded.
Logs are stored for 30 days by default, 365 days is recommended for large enterprises, and custom retention can be configured from 1 day to 3650 days. Storage beyond 30 days incurs retention cost, and retention policies configured with Bucket Lock make the audit trail immutable for its retention window.
Your enterprise organization needs to centralize logging across all current and future projects into a dedicated project named logging-prod.
The design must meet the following requirements:
logging-prod._Default log buckets to control storage costs, while ensuring mandatory system audit logs remain stored in each originating project's _Required bucket.Which logging architecture should you implement?
Create a non-intercepting aggregated log sink at the organization level with the include-children flag targeting the custom Log Bucket URI in logging-prod directly, and grant the sink's writerIdentity the Logs Bucket Writer role on the destination project.
Create an intercepting aggregated log sink at the organization level with the include-children and intercept-children flags, set the sink destination directly to the custom Log Bucket URI in logging-prod, and grant the Logs Bucket Writer role.
Create an intercepting aggregated log sink at the organization level with the include-children and intercept-children flags set to route logs to the logging-prod project, configure a log sink in logging-prod to route incoming entries into the custom Log Bucket, and grant the aggregated sink's writerIdentity the Logs Writer role on logging-prod.
Deploy individual project-level log sinks across all existing projects to route Data Access logs to logging-prod, and disable the system-created _Default sink in every child project using default resource settings.
Last updated