{"id":800,"date":"2026-04-16T05:01:53","date_gmt":"2026-04-16T05:01:53","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-audit-logs-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security\/"},"modified":"2026-04-16T05:01:53","modified_gmt":"2026-04-16T05:01:53","slug":"google-cloud-audit-logs-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-audit-logs-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security\/","title":{"rendered":"Google Cloud Audit Logs Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Security<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Cloud Audit Logs is the Google Cloud service that records \u201cwho did what, where, and when\u201d across Google Cloud resources. It produces audit trails for actions performed by users, service accounts, and Google Cloud systems, and makes those logs available through Cloud Logging.<\/p>\n\n\n\n<p>In simple terms: when someone creates a VM, changes an IAM policy, reads data from a storage bucket, or a request is denied by policy, Cloud Audit Logs captures the event so your team can investigate, alert, and prove compliance.<\/p>\n\n\n\n<p>Technically, Cloud Audit Logs is a class of logs generated by Google Cloud services and delivered into Cloud Logging log buckets. You can query them in Logs Explorer, route them with the Log Router to destinations (Cloud Storage, BigQuery, Pub\/Sub, or other log buckets), and control certain audit logging behavior (especially Data Access audit logs) through audit logging configuration in IAM policies.<\/p>\n\n\n\n<p>Cloud Audit Logs solves the core Security and operations problem of accountability and traceability in cloud environments\u2014supporting incident response, compliance audits, change management, insider-risk detection, and post-mortems with authoritative, service-generated evidence.<\/p>\n\n\n\n<blockquote>\n<p>Service name status: <strong>\u201cCloud Audit Logs\u201d is the current, official name<\/strong> in Google Cloud and is part of <strong>Cloud Logging<\/strong>. It is not a separate standalone product you \u201cdeploy\u201d; it is generated automatically by Google Cloud services and managed\/consumed through Cloud Logging.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Cloud Audit Logs?<\/h2>\n\n\n\n<p>Cloud Audit Logs is Google Cloud\u2019s auditing capability that records administrative operations and data access operations performed on Google Cloud resources. It is documented under Cloud Logging because audit log entries are ingested, stored, searched, and exported using Cloud Logging.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>To provide an audit trail of actions taken within Google Cloud projects, folders, and organizations so you can:\n&#8211; Investigate security incidents and operational issues\n&#8211; Monitor and alert on risky or unexpected activity\n&#8211; Meet compliance and governance requirements\n&#8211; Support forensics and accountability<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Captures <strong>administrative activity<\/strong> (for example: creating resources, changing IAM policies)<\/li>\n<li>Captures <strong>data access activity<\/strong> for supported services (for example: reading objects from Cloud Storage), when enabled\/configured<\/li>\n<li>Captures <strong>system events<\/strong> generated by Google Cloud services<\/li>\n<li>Captures <strong>policy-denied events<\/strong> when requests are denied by certain policy controls (coverage varies by service; verify in official docs)<\/li>\n<li>Integrates with Cloud Logging for <strong>search<\/strong>, <strong>analysis<\/strong>, <strong>routing\/exports<\/strong>, <strong>retention controls<\/strong>, and <strong>access control<\/strong><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (as you experience them)<\/h3>\n\n\n\n<p>Although Cloud Audit Logs itself is \u201cjust logs,\u201d in practice you work with these Google Cloud components:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Audit log types<\/strong> (log streams):<\/li>\n<li><strong>Admin Activity<\/strong><\/li>\n<li><strong>Data Access<\/strong><\/li>\n<li><strong>System Event<\/strong><\/li>\n<li><strong>Policy Denied<\/strong><\/li>\n<li><strong>Cloud Logging log buckets<\/strong> (where logs live)<\/li>\n<li><strong>Logs Explorer \/ Log Analytics<\/strong> (how you query)<\/li>\n<li><strong>Log Router<\/strong> (how you route\/export)<\/li>\n<li><strong>Sinks<\/strong> (routing rules to destinations)<\/li>\n<li><strong>IAM audit logging configuration<\/strong> (how you enable\/disable Data Access logging per service and per principal type)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed, provider-generated audit logging<\/strong>, consumed through <strong>Cloud Logging<\/strong>.<\/li>\n<li>No agents required for Cloud Audit Logs (this is not like VM OS auditd).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: project\/folder\/org and global nature<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Audit logs are generated for actions against resources in:<\/li>\n<li><strong>Projects<\/strong><\/li>\n<li><strong>Folders<\/strong><\/li>\n<li><strong>Organizations<\/strong><\/li>\n<li>You can create <strong>aggregated sinks<\/strong> at the folder or organization level to centralize logs from many projects.<\/li>\n<li>Audit logs are generally considered <strong>global\/control-plane logs<\/strong> even though they are stored in Cloud Logging resources that you create\/choose (log buckets can be regional; verify current bucket location behavior in Cloud Logging docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Cloud Audit Logs sits at the center of Security visibility in Google Cloud:\n&#8211; <strong>IAM<\/strong>: identities and authorization decisions appear in audit payloads\n&#8211; <strong>Cloud Logging<\/strong>: storage, query, retention, routing, sinks, and exclusions\n&#8211; <strong>Security Command Center (SCC)<\/strong>: may surface findings that you can validate and investigate using audit logs (integration patterns vary; verify)\n&#8211; <strong>Cloud Monitoring<\/strong>: alerting on log-based metrics and patterns (built via Cloud Logging\/Monitoring integration)\n&#8211; <strong>BigQuery<\/strong>: long-term analytics and compliance reporting via export\n&#8211; <strong>Pub\/Sub<\/strong>: near-real-time streaming to SIEM\/SOAR pipelines<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Cloud Audit Logs?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Compliance evidence<\/strong>: Many frameworks (SOC 2, ISO 27001, HIPAA, PCI DSS) require audit trails of privileged actions and data access.<\/li>\n<li><strong>Reduced breach impact<\/strong>: Faster investigations reduce downtime and blast radius.<\/li>\n<li><strong>Governance and accountability<\/strong>: Tie actions to principals (users\/service accounts) and change approvals.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Authoritative source<\/strong>: Logs are produced by Google Cloud services, not by your application code.<\/li>\n<li><strong>Broad coverage<\/strong>: Many Google Cloud APIs and services emit audit logs consistently.<\/li>\n<li><strong>Structured payloads<\/strong>: You can query fields like <code>protoPayload.methodName<\/code>, <code>resource.type<\/code>, <code>authenticationInfo<\/code>, and authorization details.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Change tracking<\/strong>: Answer \u201cwhat changed?\u201d during incidents.<\/li>\n<li><strong>Root cause analysis<\/strong>: Correlate operational outages with deployments, policy updates, or infrastructure changes.<\/li>\n<li><strong>Centralization<\/strong>: Export and retain audit logs across an organization for consistent operations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Detect privilege escalation<\/strong>: Identify IAM policy changes, role grants, service account key creation, etc.<\/li>\n<li><strong>Monitor sensitive data access<\/strong>: Enable Data Access logs for high-risk datasets and storage.<\/li>\n<li><strong>Policy enforcement visibility<\/strong>: Track denied requests to validate policy controls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Server-side logging<\/strong>: No performance overhead on your workloads for generating audit events.<\/li>\n<li><strong>Export and filter at scale<\/strong>: Use Log Router sinks to centralize, filter, and manage volume.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Cloud Audit Logs when you need:\n&#8211; Audit trails for Google Cloud administrative actions\n&#8211; High-trust forensics for \u201cwho did what\u201d\n&#8211; Long-term governance and centralized retention\n&#8211; Integration with SIEM, data lakes, or analytics platforms<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it (or not rely on it alone)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Host-level auditing<\/strong>: If you need OS-level syscalls, file integrity monitoring, or process-level auditing on VMs, use OS agents\/tools (for example, auditd) in addition to Cloud Audit Logs.<\/li>\n<li><strong>Application event logging<\/strong>: Cloud Audit Logs is not a substitute for application logs (business events, debug logs, tracing).<\/li>\n<li><strong>Complete data exfiltration visibility<\/strong>: Data Access logs can help, but coverage varies by service and configuration. You may also need VPC Flow Logs, Cloud IDS, DLP, or egress controls.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Cloud Audit Logs used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Financial services and fintech<\/li>\n<li>Healthcare and life sciences<\/li>\n<li>Retail\/e-commerce<\/li>\n<li>SaaS and B2B platforms<\/li>\n<li>Government and education<\/li>\n<li>Media and gaming (especially for access tracking and operational forensics)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Security engineering \/ SecOps<\/li>\n<li>Platform engineering and cloud center of excellence (CCoE)<\/li>\n<li>SRE and operations<\/li>\n<li>DevOps and CI\/CD platform teams<\/li>\n<li>Compliance and risk teams (consumers of reports)<\/li>\n<li>Data engineering teams (audit analytics in BigQuery)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Kubernetes platforms (GKE control plane and IAM-driven operations)<\/li>\n<li>Data platforms (BigQuery, Cloud Storage, Dataproc\u2014service-dependent)<\/li>\n<li>Serverless platforms (Cloud Run, Cloud Functions\u2014service-dependent)<\/li>\n<li>Infrastructure as Code (Terraform, Deployment Manager\u2014activity appears as API calls)<\/li>\n<li>Identity-heavy systems (service accounts, workload identity federation)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Single-project startups using default logging<\/li>\n<li>Multi-project enterprises using:<\/li>\n<li>centralized organization-level log sinks<\/li>\n<li>separate security projects (\u201clog archive\u201d projects)<\/li>\n<li>SIEM streaming via Pub\/Sub<\/li>\n<li>long-retention storage in Cloud Storage\/BigQuery<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: Usually enable Admin Activity logs everywhere; selectively enable Data Access logs for crown-jewel resources; export centrally with controlled retention and restricted access.<\/li>\n<li><strong>Dev\/test<\/strong>: Often reduce Data Access logging to control volume\/cost; still keep Admin Activity logs to debug and audit changes.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Cloud Audit Logs is commonly used in Google Cloud Security and operations.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Track IAM policy changes (privilege escalation detection)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Unauthorized users grant themselves Owner or add powerful roles.<\/li>\n<li><strong>Why Cloud Audit Logs fits<\/strong>: Admin Activity logs record IAM policy set operations with principal identity and request metadata.<\/li>\n<li><strong>Scenario<\/strong>: Security team alerts when <code>SetIamPolicy<\/code> is called on a project or critical service account.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Investigate \u201cwho deleted the resource?\u201d<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A Cloud Storage bucket, BigQuery dataset, or VM disappears.<\/li>\n<li><strong>Why it fits<\/strong>: Admin Activity logs show delete operations and actor identity.<\/li>\n<li><strong>Scenario<\/strong>: During an outage, you find the exact principal and timestamp for a deletion API call.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Monitor access to sensitive Cloud Storage buckets (Data Access logs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Need evidence of reads\/writes to regulated data.<\/li>\n<li><strong>Why it fits<\/strong>: Data Access audit logs can capture object read\/write operations (service-dependent).<\/li>\n<li><strong>Scenario<\/strong>: Enable Data Access logging for a PHI bucket and export logs to a restricted archive.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Validate organization policies and denial controls<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams complain \u201cGoogle Cloud is blocking my deploy,\u201d but you need proof and reason.<\/li>\n<li><strong>Why it fits<\/strong>: Policy Denied logs can provide visibility into denied requests due to policy enforcement (coverage varies).<\/li>\n<li><strong>Scenario<\/strong>: An org policy restricts external IPs; denied API calls appear for troubleshooting and governance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Build an audit log archive with immutable retention<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Compliance requires long retention and tamper resistance.<\/li>\n<li><strong>Why it fits<\/strong>: Route audit logs to a dedicated log bucket \/ Cloud Storage bucket with retention policies and restricted access.<\/li>\n<li><strong>Scenario<\/strong>: Export Admin Activity logs to a centralized project and apply locked retention (where supported; verify current capabilities in Cloud Logging and Cloud Storage).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) SIEM integration (near real-time detections)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: SOC needs centralized detections and correlations.<\/li>\n<li><strong>Why it fits<\/strong>: Export audit logs to Pub\/Sub and forward to SIEM (Splunk, Chronicle, etc.).<\/li>\n<li><strong>Scenario<\/strong>: Stream audit events to a detection pipeline that flags suspicious service account key creation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Post-incident forensics and timeline reconstruction<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: After compromise, you need a precise timeline of attacker actions.<\/li>\n<li><strong>Why it fits<\/strong>: Admin Activity + Data Access + denied logs provide high-quality evidence.<\/li>\n<li><strong>Scenario<\/strong>: Reconstruct the chain: IAM changes \u2192 resource creation \u2192 data access \u2192 log exports manipulation attempts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Detect unusual API usage patterns<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: API keys\/service accounts behave abnormally.<\/li>\n<li><strong>Why it fits<\/strong>: Audit logs include method names, resources, and authentication info.<\/li>\n<li><strong>Scenario<\/strong>: Alert on rare methods (e.g., enabling service account key creation) or spikes in sensitive API calls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Prove change management compliance for infrastructure automation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Need evidence that CI\/CD did approved changes.<\/li>\n<li><strong>Why it fits<\/strong>: Audit logs show which service account executed deployments and what changed.<\/li>\n<li><strong>Scenario<\/strong>: Tie Terraform pipeline service account actions to change tickets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Cross-project governance and centralized monitoring<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Hundreds of projects, inconsistent logging practices.<\/li>\n<li><strong>Why it fits<\/strong>: Organization-level sinks centralize audit logs; consistent retention and access.<\/li>\n<li><strong>Scenario<\/strong>: CCoE sets up org sink to a dedicated security project; teams query via controlled views.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Detect data-plane access to BigQuery datasets (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Need audit of queries\/data reads for sensitive analytics datasets.<\/li>\n<li><strong>Why it fits<\/strong>: BigQuery emits Data Access audit logs (configuration and cost\/volume considerations apply; verify details).<\/li>\n<li><strong>Scenario<\/strong>: Export BigQuery Data Access logs and build weekly access reports.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Track service usage and API enablement changes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: New APIs enabled unexpectedly (risk of shadow IT).<\/li>\n<li><strong>Why it fits<\/strong>: Admin Activity logs can record service enable\/disable operations.<\/li>\n<li><strong>Scenario<\/strong>: Alert when sensitive APIs are enabled outside of approved workflows.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on what Cloud Audit Logs provides today in Google Cloud, and what matters operationally.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 1: Admin Activity audit logs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Records administrative operations that modify configuration or metadata (for example, creating resources, changing IAM policies).<\/li>\n<li><strong>Why it matters<\/strong>: These events are the backbone of change accountability.<\/li>\n<li><strong>Practical benefit<\/strong>: Quick answers for \u201cwho changed what?\u201d during outages and investigations.<\/li>\n<li><strong>Caveats<\/strong>: Coverage depends on service; not every action across every service is identical. Admin Activity logs are generally always on, but confirm service-specific behavior in docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 2: Data Access audit logs (Data Read \/ Data Write \/ Admin Read)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Records operations that read\/write user data or read certain resource metadata at scale.<\/li>\n<li><strong>Why it matters<\/strong>: This is where you get visibility into sensitive data access.<\/li>\n<li><strong>Practical benefit<\/strong>: Detect suspicious reads, prove access controls, and support compliance reports.<\/li>\n<li><strong>Caveats<\/strong>:<\/li>\n<li>Often <strong>not enabled by default<\/strong> for all services\/projects due to volume\/cost and sensitivity.<\/li>\n<li>Access to view these logs is typically more restricted (\u201cprivate logs\u201d behavior; verify exact IAM roles in docs).<\/li>\n<li>Volume can be very high for data-heavy services.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 3: System Event audit logs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Records system-generated events (service actions not directly initiated by a user).<\/li>\n<li><strong>Why it matters<\/strong>: Helps distinguish human-initiated changes from platform\/system actions.<\/li>\n<li><strong>Practical benefit<\/strong>: Better incident timelines; fewer false accusations during outages.<\/li>\n<li><strong>Caveats<\/strong>: Not all services emit System Event logs in the same way.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 4: Policy Denied audit logs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Records when requests are denied due to certain policy controls.<\/li>\n<li><strong>Why it matters<\/strong>: Visibility into enforcement is crucial for governance and troubleshooting.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster diagnosis of \u201cwhy is this failing?\u201d and evidence of policy effectiveness.<\/li>\n<li><strong>Caveats<\/strong>: Exact sources of denial logging and supported policies vary; verify in official documentation for your use case.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 5: Structured log payload with authentication and authorization context<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Includes fields like:<\/li>\n<li>Principal identity (<code>authenticationInfo<\/code>)<\/li>\n<li>Authorization checks (<code>authorizationInfo<\/code>)<\/li>\n<li>API method (<code>methodName<\/code>)<\/li>\n<li>Target resource and service<\/li>\n<li>Request metadata (often includes caller IP \/ user agent; details vary)<\/li>\n<li><strong>Why it matters<\/strong>: Enables precise filtering, detections, and forensics.<\/li>\n<li><strong>Practical benefit<\/strong>: Build reliable queries and alerts like \u201call IAM policy changes by non-CI service accounts.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 6: Integration with Cloud Logging storage, search, and analysis<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Audit logs are stored and queried using Cloud Logging.<\/li>\n<li><strong>Why it matters<\/strong>: Central place to search across services and projects.<\/li>\n<li><strong>Practical benefit<\/strong>: Use Logs Explorer queries for investigations; use Log Analytics for deeper analysis (where available).<\/li>\n<li><strong>Caveats<\/strong>: Costs and retention depend on Cloud Logging configuration and pricing SKUs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 7: Log Router exports (sinks) and centralized aggregation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Routes audit logs to:<\/li>\n<li>Cloud Storage<\/li>\n<li>BigQuery<\/li>\n<li>Pub\/Sub<\/li>\n<li>Other Cloud Logging buckets<\/li>\n<li><strong>Why it matters<\/strong>: Enables SIEM pipelines, long retention, and cross-project centralization.<\/li>\n<li><strong>Practical benefit<\/strong>: Keep security logs in a dedicated project with locked-down access.<\/li>\n<li><strong>Caveats<\/strong>: Export destinations have their own costs and IAM configuration requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 8: Audit logging configuration control (especially Data Access)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Configure which Data Access logs are recorded for a service and principal type.<\/li>\n<li><strong>Why it matters<\/strong>: Balances Security visibility vs. cost and sensitive log exposure.<\/li>\n<li><strong>Practical benefit<\/strong>: Turn on Data Read logs only for a \u201ccrown jewels\u201d project, or exclude certain high-volume operations.<\/li>\n<li><strong>Caveats<\/strong>: Configuration is policy-driven and can be complex in large organizations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 9: Works with log-based metrics and alerting (via Cloud Logging\/Monitoring)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Convert matching audit log entries into metrics and alerts.<\/li>\n<li><strong>Why it matters<\/strong>: Turn passive logging into proactive detection.<\/li>\n<li><strong>Practical benefit<\/strong>: Alert on \u201cservice account key created\u201d or \u201cIAM policy changed\u201d within minutes.<\/li>\n<li><strong>Caveats<\/strong>: Alert design needs tuning to avoid noise; costs may apply for advanced monitoring\/alerting features (verify Cloud Monitoring pricing).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>A user, service account, or Google Cloud system calls a Google Cloud API.<\/li>\n<li>The target Google Cloud service emits an audit log entry (Admin Activity, Data Access, System Event, or Policy Denied).<\/li>\n<li>The audit log entry is ingested into <strong>Cloud Logging<\/strong> and stored in a <strong>log bucket<\/strong>.<\/li>\n<li>The <strong>Log Router<\/strong> can route the entry to:\n   &#8211; Default bucket storage\n   &#8211; Additional log buckets\n   &#8211; Export destinations via sinks (Cloud Storage, BigQuery, Pub\/Sub)<\/li>\n<li>Security\/ops teams query logs, build alerts, and export to SIEM or archive storage.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane\/API call<\/strong> \u2192 generates audit event<\/li>\n<li><strong>Audit event<\/strong> \u2192 Cloud Logging ingestion<\/li>\n<li><strong>Storage\/retention<\/strong> \u2192 log buckets<\/li>\n<li><strong>Routing<\/strong> \u2192 Log Router and sinks<\/li>\n<li><strong>Consumption<\/strong> \u2192 Logs Explorer, Log Analytics, Monitoring alerting, exports<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Logging<\/strong>: storage, routing, query, retention, log buckets, views<\/li>\n<li><strong>IAM<\/strong>: audit config management and access control to logs<\/li>\n<li><strong>Cloud Monitoring<\/strong>: alerts on log-based metrics<\/li>\n<li><strong>Cloud Storage \/ BigQuery \/ Pub\/Sub<\/strong>: export destinations<\/li>\n<li><strong>Security Command Center \/ SIEM tools<\/strong>: downstream consumption (integration depends on tool)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Audit Logs depends on Google Cloud services emitting audit entries and on Cloud Logging for ingestion\/storage\/routing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Audit logs record identities used in the request (user\/service account).<\/li>\n<li>Access to <strong>view<\/strong> audit logs is governed by IAM roles on the project\/folder\/org and Logging resources.<\/li>\n<li>Export permissions:<\/li>\n<li>Creating sinks requires Logging permissions.<\/li>\n<li>Destinations require IAM grants to the sink writer identity.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>No VPC networking is required to \u201creceive\u201d Cloud Audit Logs; they are generated and delivered within Google-managed control plane.<\/li>\n<li>Export destinations may involve networking considerations:<\/li>\n<li>Pub\/Sub subscribers or SIEM forwarders might run in your VPC.<\/li>\n<li>BigQuery access is API-based.<\/li>\n<li>Cross-project exports are IAM-driven.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat audit logs as <strong>security telemetry<\/strong>:<\/li>\n<li>Restrict access (principle of least privilege)<\/li>\n<li>Centralize in a security project<\/li>\n<li>Set retention per compliance needs<\/li>\n<li>Monitor for tampering attempts (e.g., sink changes or logging exclusions)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  A[User \/ Service Account] --&gt; B[Google Cloud API Call]\n  B --&gt; C[Google Cloud Service]\n  C --&gt; D[Cloud Audit Logs]\n  D --&gt; E[Cloud Logging Log Bucket]\n  E --&gt; F[Logs Explorer \/ Queries]\n  E --&gt; G[Log Router Sink]\n  G --&gt; H[Cloud Storage \/ BigQuery \/ Pub\/Sub]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[Google Cloud Organization]\n    P1[Project A]\n    P2[Project B]\n    P3[Project C]\n  end\n\n  subgraph Logging[Central Logging \/ Security Project]\n    LB[Dedicated Log Bucket\\n(retention + restricted access)]\n    S1[Org-level Sink\\nAudit Logs Filter]\n    BQ[BigQuery Dataset\\n(Security Analytics)]\n    CS[Cloud Storage Bucket\\n(Archive \/ WORM policies)]\n    PS[Pub\/Sub Topic\\n(SIEM Streaming)]\n  end\n\n  P1 --&gt;|Admin Activity + (optional) Data Access| S1\n  P2 --&gt;|Admin Activity + (optional) Data Access| S1\n  P3 --&gt;|Admin Activity + (optional) Data Access| S1\n\n  S1 --&gt; LB\n  S1 --&gt; BQ\n  S1 --&gt; CS\n  S1 --&gt; PS\n\n  subgraph Consumers[Security &amp; Ops Consumers]\n    SOC[SOC \/ SIEM]\n    IR[Incident Response]\n    COMP[Compliance Reporting]\n  end\n\n  PS --&gt; SOC\n  BQ --&gt; COMP\n  LB --&gt; IR\n  CS --&gt; COMP\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<p>Before starting the hands-on tutorial and production usage, ensure you have the following.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Google Cloud account \/ project<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud billing account and at least one Google Cloud project.<\/li>\n<li>Billing enabled (some exports\/destinations can incur cost).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You need permissions to:\n&#8211; View logs in Cloud Logging\n&#8211; Configure audit log settings (for Data Access)\n&#8211; Create log sinks and set destination IAM<\/p>\n\n\n\n<p>Common roles (exact needs vary):\n&#8211; <code>roles\/logging.viewer<\/code> or <code>roles\/logging.privateLogViewer<\/code> (for private\/Data Access logs)\n&#8211; <code>roles\/logging.configWriter<\/code> (to create\/modify sinks)\n&#8211; <code>roles\/resourcemanager.projectIamAdmin<\/code> or appropriate IAM admin permissions (to configure audit logging via IAM policies)\n&#8211; Storage permissions for destination bucket IAM changes (e.g., <code>roles\/storage.admin<\/code> on the destination bucket\/project)<\/p>\n\n\n\n<blockquote>\n<p>Verify least-privilege role requirements in official docs for your environment.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud Console access<\/li>\n<li><code>gcloud<\/code> CLI installed and authenticated:<\/li>\n<li>Install: https:\/\/cloud.google.com\/sdk\/docs\/install<\/li>\n<li><code>gsutil<\/code> (included with Cloud SDK; still widely used for Cloud Storage operations)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Audit Logs is a Google Cloud control-plane capability.<\/li>\n<li>Cloud Logging resources (log buckets) and export destinations can be regional\/multi-regional depending on service. <strong>Verify current Cloud Logging bucket location behavior<\/strong> and supported regions in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas \/ limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Logging has quotas for ingestion, API requests, and sinks; audit logs contribute to volume.<\/li>\n<li>Export destinations (Pub\/Sub, BigQuery, Cloud Storage) have their own quotas.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Logging API is typically available by default, but ensure relevant APIs are enabled for:<\/li>\n<li>Cloud Logging<\/li>\n<li>Cloud Storage (for the lab)<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Cloud Audit Logs pricing is best understood through <strong>Cloud Logging pricing<\/strong>, because audit logs are ingested and stored as logs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (what you pay for)<\/h3>\n\n\n\n<p>Costs can come from:\n1. <strong>Log ingestion volume<\/strong> (GB ingested)\n2. <strong>Log storage\/retention<\/strong> (depending on retention configuration and log bucket settings)\n3. <strong>Log analytics\/query features<\/strong> (depending on enabled features and SKU; verify current Cloud Logging tiers)\n4. <strong>Exports<\/strong>:\n   &#8211; <strong>Cloud Storage<\/strong>: object storage charges + operations\n   &#8211; <strong>BigQuery<\/strong>: storage + query costs\n   &#8211; <strong>Pub\/Sub<\/strong>: message throughput + delivery costs\n5. <strong>Downstream SIEM<\/strong>: third-party licensing and ingestion fees<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier and \u201cfree audit logs\u201d<\/h3>\n\n\n\n<p>Google Cloud historically treats certain audit logs (commonly Admin Activity and System Event) as included\/free for ingestion, while <strong>Data Access<\/strong> logs can be billable due to volume. However, pricing and free allowances can change by SKU and over time.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Always confirm<\/strong> with the official Cloud Logging pricing page:<\/li>\n<li>https:\/\/cloud.google.com\/logging\/pricing<\/li>\n<li>Use the pricing calculator for end-to-end estimates:<\/li>\n<li>https:\/\/cloud.google.com\/products\/calculator<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Key cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enabling <strong>Data Access<\/strong> logs broadly (especially Data Read) for high-throughput services<\/li>\n<li>Exporting to BigQuery and running frequent queries<\/li>\n<li>Long retention in log buckets or archive buckets<\/li>\n<li>Duplicating exports (multiple sinks to multiple destinations)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Compliance retention<\/strong>: long retention multiplies storage cost<\/li>\n<li><strong>SIEM ingestion<\/strong>: can dwarf Google Cloud costs<\/li>\n<li><strong>Alert noise<\/strong>: operational cost to triage excessive alerts<\/li>\n<li><strong>Cross-team access<\/strong>: administrative overhead of securing private logs properly<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Log exports are Google-managed, but downstream consumers (for Pub\/Sub) may incur egress depending on where subscribers run.<\/li>\n<li>BigQuery queries from outside the region or exports across regions can have cost implications\u2014verify per service and location.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost (practical levers)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable <strong>Data Access audit logs only where needed<\/strong>:<\/li>\n<li>Start with \u201ccrown jewel\u201d projects\/resources<\/li>\n<li>Focus on Data Write first (often lower volume than Data Read)<\/li>\n<li>Use <strong>Log Router filters<\/strong> to export only what you need.<\/li>\n<li>Use <strong>exclusions carefully<\/strong> (but never exclude critical audit trails without a formal risk decision).<\/li>\n<li>Prefer <strong>Cloud Storage<\/strong> for low-cost long-term archive (then query selectively) vs. querying everything in BigQuery.<\/li>\n<li>Use <strong>separate buckets\/projects<\/strong> to isolate high-volume logs and control retention.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A small team might:\n&#8211; Rely on Admin Activity logs in the default log bucket\n&#8211; Enable Data Access logs only for one sensitive Cloud Storage bucket\/project\n&#8211; Export only Admin Activity logs to a low-cost Cloud Storage bucket with a modest retention policy<\/p>\n\n\n\n<p>Costs depend on:\n&#8211; Audit log volume (GB\/month)\n&#8211; Storage retention duration\n&#8211; Any BigQuery\/Pub\/Sub usage<\/p>\n\n\n\n<p>Use:\n&#8211; Cloud Logging pricing: https:\/\/cloud.google.com\/logging\/pricing\n&#8211; Calculator: https:\/\/cloud.google.com\/products\/calculator<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In an enterprise:\n&#8211; Org-level sinks exporting:\n  &#8211; Admin Activity for all projects\n  &#8211; Data Access for a subset of regulated projects\n&#8211; Dual destinations:\n  &#8211; Pub\/Sub to SIEM (near-real-time)\n  &#8211; BigQuery for analytics and compliance dashboards\n  &#8211; Cloud Storage archive for long retention<\/p>\n\n\n\n<p>Cost planning should include:\n&#8211; \uc608\uc0c1 log volume growth\n&#8211; SIEM ingestion limits\n&#8211; Retention policies by log class\n&#8211; Query patterns (BigQuery cost control via partitioning, scheduled queries, and access governance)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab shows how to (1) generate Cloud Audit Logs, (2) enable and view Data Access logs for Cloud Storage, and (3) export selected audit logs to a Cloud Storage bucket using a Log Router sink.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>View Cloud Audit Logs in Logs Explorer<\/li>\n<li>Enable Cloud Storage Data Access audit logs (so object reads\/writes appear)<\/li>\n<li>Create a Log Router sink to export Cloud Audit Logs to Cloud Storage<\/li>\n<li>Validate exported log objects and clean up resources<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Prepare two Cloud Storage buckets:\n   &#8211; One \u201cwork\u201d bucket to generate audit events\n   &#8211; One \u201carchive\u201d bucket to receive exported audit logs\n2. Enable Data Access audit logs for Cloud Storage at the project level (Console-based)\n3. Generate data access events (upload\/download objects)\n4. Query and verify Cloud Audit Logs in Logs Explorer\n5. Create a Cloud Logging sink with a filter for audit logs\n6. Validate that logs are exported to the archive bucket\n7. Clean up (delete sink and buckets; optionally revert audit configuration)<\/p>\n\n\n\n<blockquote>\n<p>Cost safety: Cloud Storage buckets and a small number of objects are low-cost, but <strong>enabling Data Access logs can increase Cloud Logging ingestion<\/strong> depending on activity. Perform only a few operations during the lab.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Select a project and set up your CLI environment<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open Cloud Shell <strong>or<\/strong> use a local terminal with <code>gcloud<\/code> installed.<\/li>\n<li>Set your project ID:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"YOUR_PROJECT_ID\"\ngcloud config set project \"${PROJECT_ID}\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>Confirm active account:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth list\ngcloud config list\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; <code>gcloud config set project<\/code> succeeds and <code>gcloud config list<\/code> shows the correct project.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create Cloud Storage buckets (work + archive)<\/h3>\n\n\n\n<p>Pick a globally unique bucket suffix:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export RAND_SUFFIX=\"$(date +%Y%m%d)-$RANDOM\"\nexport WORK_BUCKET=\"cal-work-${PROJECT_ID}-${RAND_SUFFIX}\"\nexport ARCHIVE_BUCKET=\"cal-archive-${PROJECT_ID}-${RAND_SUFFIX}\"\n<\/code><\/pre>\n\n\n\n<p>Create the buckets (choose a location that works for you). If you use <code>gcloud storage<\/code>, ensure it\u2019s available in your Cloud SDK; otherwise use <code>gsutil<\/code>. Below uses <code>gsutil<\/code> (widely available):<\/p>\n\n\n\n<pre><code class=\"language-bash\"># Choose a location (example: US multi-region). Adjust as needed.\nexport LOCATION=\"US\"\n\ngsutil mb -p \"${PROJECT_ID}\" -l \"${LOCATION}\" \"gs:\/\/${WORK_BUCKET}\"\ngsutil mb -p \"${PROJECT_ID}\" -l \"${LOCATION}\" \"gs:\/\/${ARCHIVE_BUCKET}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Both buckets are created successfully.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil ls -p \"${PROJECT_ID}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Enable Cloud Storage Data Access audit logs (Console)<\/h3>\n\n\n\n<p>Data Access logs are commonly the logs you must explicitly enable to see object-level reads\/writes.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In Google Cloud Console, go to:\n   &#8211; <strong>IAM &amp; Admin<\/strong> \u2192 <strong>Audit Logs<\/strong>\n   &#8211; Direct link (may require selecting project): https:\/\/console.cloud.google.com\/iam-admin\/audit<\/li>\n<li>Ensure your project is selected.<\/li>\n<li>Find <strong>Cloud Storage<\/strong> (may appear as \u201cGoogle Cloud Storage\u201d).<\/li>\n<li>Enable Data Access logging for the desired log types:\n   &#8211; <strong>Data Read<\/strong> (reads like object GET\/download; potentially high volume)\n   &#8211; <strong>Data Write<\/strong> (writes like uploads\/deletes)\n   &#8211; Optionally <strong>Admin Read<\/strong> (read metadata\/list operations; verify exact meaning per service)<\/li>\n<li>Save changes.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Data Access audit logging for Cloud Storage is enabled for the project.<\/p>\n\n\n\n<p><strong>Notes<\/strong>\n&#8211; UI labels can change; follow the official guide if the UI differs:\n  &#8211; https:\/\/cloud.google.com\/logging\/docs\/audit\/configure-data-access<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Generate audit events (upload and download an object)<\/h3>\n\n\n\n<p>Create a small test file and upload it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">echo \"hello cloud audit logs\" &gt; hello-audit.txt\ngsutil cp hello-audit.txt \"gs:\/\/${WORK_BUCKET}\/hello-audit.txt\"\n<\/code><\/pre>\n\n\n\n<p>Now download it (to generate a read event):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil cp \"gs:\/\/${WORK_BUCKET}\/hello-audit.txt\" .\/hello-audit-downloaded.txt\n<\/code><\/pre>\n\n\n\n<p>Optionally list objects (may generate metadata\/admin-read type events depending on service behavior and configuration):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil ls \"gs:\/\/${WORK_BUCKET}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Upload\/download succeeds.\n&#8211; Audit logs should be generated for these operations (Data Access for object operations, Admin Activity for certain administrative actions).<\/p>\n\n\n\n<p><strong>Important<\/strong>\n&#8211; Audit logs can take a short time to appear (often minutes).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: View Cloud Audit Logs in Logs Explorer<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open <strong>Cloud Logging \u2192 Logs Explorer<\/strong>:\n   &#8211; https:\/\/console.cloud.google.com\/logs\/query<\/li>\n<li>Use a query to find Cloud Storage Data Access audit logs:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-text\">logName:\"cloudaudit.googleapis.com\/data_access\"\nresource.type=\"gcs_bucket\"\nresource.labels.bucket_name=\"&lt;YOUR_WORK_BUCKET_NAME&gt;\"\n<\/code><\/pre>\n\n\n\n<p>Replace <code>&lt;YOUR_WORK_BUCKET_NAME&gt;<\/code> with your bucket, for example:\n<code>resource.labels.bucket_name=\"cal-work-...\"<\/code><\/p>\n\n\n\n<p>You can also filter by method name (field names may vary by service log schema, but commonly present in <code>protoPayload<\/code>):<\/p>\n\n\n\n<pre><code class=\"language-text\">logName:\"cloudaudit.googleapis.com\/data_access\"\nresource.type=\"gcs_bucket\"\nprotoPayload.methodName:\"storage.objects\"\nresource.labels.bucket_name=\"&lt;YOUR_WORK_BUCKET_NAME&gt;\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You see log entries corresponding to object upload\/download\/list operations.\n&#8211; Each entry should include information such as:\n  &#8211; Who made the call (principal)\n  &#8211; What method was called\n  &#8211; Which resource was accessed\n  &#8211; Whether it was permitted\/denied (when applicable)<\/p>\n\n\n\n<p><strong>Verification tips<\/strong>\n&#8211; Expand a log entry and look for:\n  &#8211; <code>protoPayload.authenticationInfo<\/code>\n  &#8211; <code>protoPayload.methodName<\/code>\n  &#8211; <code>resource.labels<\/code>\n  &#8211; <code>timestamp<\/code><\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create a Log Router sink to export audit logs to the archive bucket<\/h3>\n\n\n\n<p>Now you will export Cloud Audit Logs to Cloud Storage.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">6.1 Create the sink<\/h4>\n\n\n\n<p>Create a sink that exports audit logs. Start with Admin Activity + Data Access, but filter to Cloud Storage and your work bucket to keep volume low.<\/p>\n\n\n\n<pre><code class=\"language-bash\">export SINK_NAME=\"cal-audit-to-storage-${RAND_SUFFIX}\"\n\ngcloud logging sinks create \"${SINK_NAME}\" \\\n  \"storage.googleapis.com\/${ARCHIVE_BUCKET}\" \\\n  --log-filter='(\n    logName:\"cloudaudit.googleapis.com\"\n    AND resource.type=\"gcs_bucket\"\n    AND resource.labels.bucket_name=\"'\"${WORK_BUCKET}\"'\"\n  )'\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Sink is created.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">6.2 Grant the sink writer identity permission to write to the archive bucket<\/h4>\n\n\n\n<p>Describe the sink to get the <code>writerIdentity<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud logging sinks describe \"${SINK_NAME}\" --format=\"value(writerIdentity)\"\n<\/code><\/pre>\n\n\n\n<p>It will look like a service account, for example:\n<code>serviceAccount:cloud-logs@system.gserviceaccount.com<\/code> or a unique writer identity.<\/p>\n\n\n\n<p>Grant it permission to write objects to the destination bucket:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export WRITER_IDENTITY=\"$(gcloud logging sinks describe \"${SINK_NAME}\" --format=\"value(writerIdentity)\")\"\n\ngsutil iam ch \"${WRITER_IDENTITY}:objectCreator\" \"gs:\/\/${ARCHIVE_BUCKET}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; IAM change succeeds and the sink can write to the archive bucket.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil iam get \"gs:\/\/${ARCHIVE_BUCKET}\" | head -n 50\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Generate more events and confirm export<\/h3>\n\n\n\n<p>Generate a few more actions:<\/p>\n\n\n\n<pre><code class=\"language-bash\">echo \"second event\" &gt; hello-audit-2.txt\ngsutil cp hello-audit-2.txt \"gs:\/\/${WORK_BUCKET}\/hello-audit-2.txt\"\ngsutil cp \"gs:\/\/${WORK_BUCKET}\/hello-audit-2.txt\" .\/hello-audit-2-downloaded.txt\n<\/code><\/pre>\n\n\n\n<p>Wait a few minutes, then check the archive bucket:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil ls \"gs:\/\/${ARCHIVE_BUCKET}\/**\" | head\n<\/code><\/pre>\n\n\n\n<p>Depending on export format and partitioning behavior, you should see objects written under a prefix structure managed by Cloud Logging.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; New objects appear in the archive bucket representing exported log entries.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Logs Explorer shows audit entries<\/strong>\n   &#8211; Query includes <code>logName:\"cloudaudit.googleapis.com\/data_access\"<\/code>\n   &#8211; Entries exist for Cloud Storage operations on your work bucket<\/p>\n<\/li>\n<li>\n<p><strong>Sink exists and has a writer identity<\/strong>\n   &#8211; <code>gcloud logging sinks describe<\/code> returns <code>writerIdentity<\/code><\/p>\n<\/li>\n<li>\n<p><strong>Archive bucket receives exported objects<\/strong>\n   &#8211; <code>gsutil ls gs:\/\/ARCHIVE_BUCKET\/**<\/code> shows exported log objects<\/p>\n<\/li>\n<li>\n<p><strong>Entries match your filter<\/strong>\n   &#8211; Exported objects correspond to your work bucket activity (may require downloading and inspecting objects; format depends on exporter)<\/p>\n<\/li>\n<\/ol>\n\n\n\n<p>To download one exported object for inspection:<\/p>\n\n\n\n<pre><code class=\"language-bash\"># Example: copy the first exported object you see\nEXPORTED_OBJ=\"$(gsutil ls \"gs:\/\/${ARCHIVE_BUCKET}\/**\" | head -n 1)\"\ngsutil cp \"${EXPORTED_OBJ}\" .\/exported-log-object\nls -l .\/exported-log-object\n<\/code><\/pre>\n\n\n\n<p>(Exported files may be compressed or newline-delimited JSON depending on exporter behavior; exact format can change\u2014verify in Cloud Logging export docs.)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>No Data Access logs appear<\/strong>\n   &#8211; Confirm you enabled Data Access logs for Cloud Storage in <strong>IAM &amp; Admin \u2192 Audit Logs<\/strong>\n   &#8211; Wait a few minutes; ingestion is not always instant\n   &#8211; Make sure you have permission to view private logs (try <code>roles\/logging.privateLogViewer<\/code>)<\/p>\n<\/li>\n<li>\n<p><strong>Sink exports nothing<\/strong>\n   &#8211; Re-check the sink filter (typos in bucket name, logName, resource type)\n   &#8211; Temporarily broaden the filter to confirm export works:<\/p>\n<ul>\n<li>Use only <code>logName:\"cloudaudit.googleapis.com\"<\/code> (be careful\u2014this increases volume)<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>Permission denied writing to archive bucket<\/strong>\n   &#8211; Ensure you granted the sink <code>writerIdentity<\/code> <code>objectCreator<\/code> on the destination bucket\n   &#8211; Confirm the IAM binding is on the correct bucket<\/p>\n<\/li>\n<li>\n<p><strong>You see Admin Activity logs but not Data Access<\/strong>\n   &#8211; This usually indicates Data Access isn\u2019t enabled or you can\u2019t view private logs\n   &#8211; Verify per-service Data Access logging configuration and viewer permissions<\/p>\n<\/li>\n<li>\n<p><strong>Confusing fields in log entries<\/strong>\n   &#8211; Many audit logs store key data under <code>protoPayload<\/code>. Expand the JSON payload in Logs Explorer and search within it for <code>principalEmail<\/code>, <code>methodName<\/code>, and <code>resourceName<\/code>.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing cost and reduce clutter:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Delete the sink:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">gcloud logging sinks delete \"${SINK_NAME}\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>Delete buckets (this deletes objects too; be careful):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">gsutil -m rm -r \"gs:\/\/${WORK_BUCKET}\"\ngsutil -m rm -r \"gs:\/\/${ARCHIVE_BUCKET}\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>(Optional) Disable Data Access audit logs again\n&#8211; Go back to <strong>IAM &amp; Admin \u2192 Audit Logs<\/strong>\n&#8211; Uncheck Data Read\/Data Write for Cloud Storage\n&#8211; Save<\/li>\n<\/ol>\n\n\n\n<blockquote>\n<p>In real environments, disabling audit logs should be a formal security decision.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Centralize audit logs<\/strong> with organization-level sinks into a dedicated security\/log-archive project.<\/li>\n<li>Use <strong>separate destinations<\/strong> for different needs:<\/li>\n<li>Pub\/Sub for near-real-time detections<\/li>\n<li>BigQuery for analytics and reporting<\/li>\n<li>Cloud Storage for long-term low-cost archive<\/li>\n<li>Apply <strong>defense in depth<\/strong>: keep logs in Cloud Logging even if you export (avoid single point of failure).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Restrict access to audit logs, especially Data Access logs:<\/li>\n<li>Use least privilege roles (<code>logging.viewer<\/code> vs <code>logging.privateLogViewer<\/code>).<\/li>\n<li>Prefer group-based access and just-in-time access for incident responders.<\/li>\n<li>Lock down sink management:<\/li>\n<li>Limit who can create\/modify sinks and exclusions.<\/li>\n<li>Monitor changes to sinks\/exclusions via Admin Activity logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable Data Access logs selectively:<\/li>\n<li>Start with critical projects\/resources only<\/li>\n<li>Prefer Data Write over Data Read if cost\/volume is a concern<\/li>\n<li>Use sink filters to export only relevant subsets.<\/li>\n<li>Review retention:<\/li>\n<li>Keep what compliance requires, not \u201ceverything forever.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid overly broad exports to BigQuery if you don\u2019t need them\u2014BigQuery can scale, but costs can grow with query volume.<\/li>\n<li>For streaming to SIEM, prefer Pub\/Sub with appropriate subscription and backpressure handling.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use multiple exports only when justified; each sink adds operational and cost overhead.<\/li>\n<li>Treat the log archive project as production infrastructure:<\/li>\n<li>Strong IAM controls<\/li>\n<li>Infrastructure as Code for sink definitions<\/li>\n<li>Change control for audit config updates<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Document your standard investigation queries (runbooks).<\/li>\n<li>Create alerting for high-risk audit events:<\/li>\n<li>IAM policy changes<\/li>\n<li>Service account key creation<\/li>\n<li>Logging sink\/exclusion changes<\/li>\n<li>Disabling audit logging configuration<\/li>\n<li>Periodically test log export pipelines (table\/data presence checks).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize names:<\/li>\n<li><code>org-audit-to-bq<\/code><\/li>\n<li><code>org-audit-to-pubsub-siem<\/code><\/li>\n<li><code>project-audit-archive-bucket<\/code><\/li>\n<li>Use labels\/tags on projects to drive policy:<\/li>\n<li><code>data_classification=regulated<\/code><\/li>\n<li><code>env=prod<\/code><\/li>\n<li>Apply consistent retention based on classification.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Audit Logs record the identity used for the API call (user or service account).<\/li>\n<li>Access to <strong>read logs<\/strong> is controlled by IAM on Logging resources.<\/li>\n<li>Data Access logs are often treated as <strong>more sensitive<\/strong> (\u201cprivate\u201d) because they can reveal accessed data\/resource names and user activity patterns.<\/li>\n<\/ul>\n\n\n\n<p>Recommended controls:\n&#8211; Grant <code>roles\/logging.privateLogViewer<\/code> only to a small set of trusted responders.\n&#8211; Use log views (where applicable in Cloud Logging) to restrict what different teams can see (verify current Logging views capabilities in docs).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Logs in Cloud Logging are encrypted at rest by Google by default.<\/li>\n<li>For stricter controls, evaluate CMEK options for Cloud Logging buckets if needed (verify availability and constraints in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Audit Logs themselves do not require opening network access.<\/li>\n<li>Export destinations:<\/li>\n<li>Cloud Storage access is controlled by IAM and bucket policies.<\/li>\n<li>Pub\/Sub subscribers might run outside Google Cloud\u2014secure with IAM, VPC-SC (if used), and subscriber auth.<\/li>\n<li>BigQuery access should be scoped with dataset-level IAM, views, and column-level controls where needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Audit logs can contain sensitive metadata (resource names, principals, sometimes request metadata).<\/li>\n<li>Do not treat exported audit logs as non-sensitive; secure them like security telemetry.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging about audit logging (meta-auditing)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Monitor for:<\/li>\n<li>sink deletions\/updates<\/li>\n<li>logging exclusions<\/li>\n<li>audit configuration changes in IAM policies<\/li>\n<li>These are high-signal events in incident response.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Map audit log retention and integrity controls to your framework requirements.<\/li>\n<li>Implement:<\/li>\n<li>centralization<\/li>\n<li>restricted access<\/li>\n<li>retention policies<\/li>\n<li>documented review procedures<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enabling Data Access logs everywhere without access controls \u2192 sensitive user activity becomes broadly visible.<\/li>\n<li>Allowing many users to modify sinks\/exclusions \u2192 attackers can disrupt your telemetry.<\/li>\n<li>Not exporting\/archiving logs \u2192 limited retention hinders investigations.<\/li>\n<li>Not testing exports \u2192 \u201cwe thought we had logs\u201d becomes \u201cwe don\u2019t.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Centralize logs in a security-owned project with a break-glass process.<\/li>\n<li>Use IaC for sinks and audit config, peer-reviewed.<\/li>\n<li>Use organization policies\/controls to prevent disabling critical logging (where possible; verify policy options).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Not all services log the same things<\/strong>: Audit log coverage varies by Google Cloud service and API method.<\/li>\n<li><strong>Data Access log volume can be huge<\/strong>: Enabling Data Read on high-traffic data services can significantly increase log ingestion and downstream costs.<\/li>\n<li><strong>Viewer permissions differ<\/strong>: Some audit logs (especially Data Access) can require elevated permissions to view.<\/li>\n<li><strong>Latency exists<\/strong>: Audit logs can arrive with delay; don\u2019t assume millisecond real-time behavior.<\/li>\n<li><strong>Export format nuances<\/strong>: Exported logs to Cloud Storage\/BigQuery may differ in structure and partitioning. Always validate downstream parsing.<\/li>\n<li><strong>Sinks can create duplicates<\/strong>: Multiple sinks exporting overlapping filters can duplicate events and cost.<\/li>\n<li><strong>Centralization complexity<\/strong>: Org-level sinks are powerful but require careful IAM and project structure.<\/li>\n<li><strong>Retention assumptions<\/strong>: Default retention and paid retention options can change; verify current Cloud Logging retention policies.<\/li>\n<li><strong>Policy Denied coverage<\/strong>: Which denials emit Policy Denied logs can vary; confirm for your policy types and services.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Cloud Audit Logs is the native audit trail for Google Cloud API activity. Alternatives are usually complementary, not replacements.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Cloud Audit Logs (Google Cloud)<\/strong><\/td>\n<td>Auditing Google Cloud control plane and supported data access<\/td>\n<td>Provider-generated, structured, integrates with Cloud Logging\/Router<\/td>\n<td>Data Access can be high-volume\/cost; coverage varies by service<\/td>\n<td>You need authoritative audit trails in Google Cloud<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Logging (Google Cloud)<\/strong><\/td>\n<td>Central log storage\/search\/routing (includes audit logs + app logs)<\/td>\n<td>Unified logging platform, sinks, retention, queries<\/td>\n<td>Not specifically \u201caudit\u201d only; you must manage access and cost<\/td>\n<td>Use alongside Cloud Audit Logs (it\u2019s the platform you use to manage them)<\/td>\n<\/tr>\n<tr>\n<td><strong>Security Command Center (Google Cloud)<\/strong><\/td>\n<td>Security posture management and findings<\/td>\n<td>High-level security insights and findings<\/td>\n<td>Not a full raw audit trail; depends on integrations<\/td>\n<td>Use SCC for posture + triage, and Cloud Audit Logs for evidence<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS CloudTrail<\/strong><\/td>\n<td>Auditing AWS actions<\/td>\n<td>Similar concept for AWS<\/td>\n<td>Not applicable to Google Cloud resources<\/td>\n<td>Choose for AWS environments<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Activity Log \/ Azure AD audit logs<\/strong><\/td>\n<td>Auditing Azure subscription and identity activity<\/td>\n<td>Similar concept for Azure<\/td>\n<td>Not applicable to Google Cloud resources<\/td>\n<td>Choose for Azure environments<\/td>\n<\/tr>\n<tr>\n<td><strong>OS audit tools (auditd, Sysmon, etc.)<\/strong><\/td>\n<td>Host-level auditing<\/td>\n<td>Deep host visibility<\/td>\n<td>Doesn\u2019t cover cloud control plane<\/td>\n<td>Use in addition to Cloud Audit Logs for VM\/endpoint telemetry<\/td>\n<\/tr>\n<tr>\n<td><strong>Custom application audit logging<\/strong><\/td>\n<td>App-specific business events<\/td>\n<td>Tailored to your domain<\/td>\n<td>Not authoritative for cloud control plane; easy to miss events<\/td>\n<td>Use together with Cloud Audit Logs<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example (regulated industry)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A financial services company must prove that only approved identities accessed regulated datasets, and must retain logs for audits while keeping access restricted.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>Enable Admin Activity logs everywhere (default behavior).<\/li>\n<li>Enable Data Access logs only for regulated projects (BigQuery datasets, Cloud Storage buckets).<\/li>\n<li>Create an <strong>organization-level sink<\/strong> exporting Cloud Audit Logs to:<ul>\n<li>A dedicated Cloud Logging bucket in a security project for fast investigation<\/li>\n<li>Cloud Storage archive bucket with retention policy for long-term compliance<\/li>\n<li>Pub\/Sub for SIEM detections<\/li>\n<\/ul>\n<\/li>\n<li>Restrict visibility to private logs to the SOC group only.<\/li>\n<li><strong>Why Cloud Audit Logs was chosen<\/strong>:<\/li>\n<li>Native, authoritative source of who\/what\/when for Google Cloud actions<\/li>\n<li>Integrates cleanly with routing and exports<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Faster incident response with reliable evidence<\/li>\n<li>Compliance-ready retention and reporting pipeline<\/li>\n<li>Reduced risk of undetected privileged changes<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A SaaS startup needs basic accountability (who changed IAM, who deployed) without building a complex SIEM pipeline.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>Use Logs Explorer to investigate Admin Activity logs.<\/li>\n<li>Create a project-level sink exporting only Admin Activity logs to a Cloud Storage bucket for longer retention.<\/li>\n<li>Create a small set of alerts (e.g., IAM policy changes, service account key creation).<\/li>\n<li><strong>Why Cloud Audit Logs was chosen<\/strong>:<\/li>\n<li>Works out-of-the-box with minimal setup<\/li>\n<li>Low operational overhead compared to self-managed audit infrastructure<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Basic compliance evidence for SOC 2 readiness<\/li>\n<li>Faster debugging of \u201cwhat changed\u201d incidents<\/li>\n<li>Controlled cost by avoiding broad Data Access logging<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Is Cloud Audit Logs a separate product I need to enable?<\/strong><br\/>\n   Cloud Audit Logs are generated by Google Cloud services and delivered through Cloud Logging. You typically don\u2019t \u201cinstall\u201d it. Admin Activity logs are generally on by default, while Data Access logs often require explicit configuration.<\/p>\n<\/li>\n<li>\n<p><strong>What are the main Cloud Audit Logs types?<\/strong><br\/>\n   Admin Activity, Data Access, System Event, and Policy Denied.<\/p>\n<\/li>\n<li>\n<p><strong>Do Admin Activity logs include IAM policy changes?<\/strong><br\/>\n   Yes\u2014IAM policy changes are a primary use case and typically appear in Admin Activity logs.<\/p>\n<\/li>\n<li>\n<p><strong>Why don\u2019t I see Data Access logs for my bucket\/dataset?<\/strong><br\/>\n   Data Access logs often must be enabled in <strong>IAM &amp; Admin \u2192 Audit Logs<\/strong>, and you may need additional permissions (commonly private log viewing). Also allow time for logs to appear.<\/p>\n<\/li>\n<li>\n<p><strong>Are Data Access logs \u201csensitive\u201d?<\/strong><br\/>\n   They can be. They may reveal which principal accessed which resource and when, and can include metadata that should be restricted.<\/p>\n<\/li>\n<li>\n<p><strong>How do I export audit logs to BigQuery?<\/strong><br\/>\n   Create a Log Router sink with BigQuery as the destination. Then control access to the dataset with IAM. Follow Cloud Logging export docs to ensure correct dataset location and permissions.<\/p>\n<\/li>\n<li>\n<p><strong>How do I export audit logs to a SIEM?<\/strong><br\/>\n   Common pattern: Log Router sink \u2192 Pub\/Sub topic \u2192 SIEM forwarder\/connector. Some SIEMs also support Cloud Storage or BigQuery ingestion.<\/p>\n<\/li>\n<li>\n<p><strong>Can attackers delete or disable audit logs?<\/strong><br\/>\n   They can try\u2014if they have permissions to modify logging sinks, exclusions, or audit configuration. Best practice is to restrict these permissions and centralize logs in a security project with strong controls.<\/p>\n<\/li>\n<li>\n<p><strong>How long are Cloud Audit Logs retained?<\/strong><br\/>\n   Retention is governed by Cloud Logging bucket retention configuration and your exports\/archives. Default retention and configurable retention options can change\u2014verify current Cloud Logging retention documentation.<\/p>\n<\/li>\n<li>\n<p><strong>Do audit logs cover every single API call?<\/strong><br\/>\n   Not necessarily. Coverage varies by service and method, and Data Access logging may be optional. Always verify your critical services\u2019 audit logging coverage.<\/p>\n<\/li>\n<li>\n<p><strong>Can I filter out noisy audit logs?<\/strong><br\/>\n   Yes\u2014use Log Router filters for exports, and exclusions carefully. For Security, be cautious about excluding logs needed for forensics.<\/p>\n<\/li>\n<li>\n<p><strong>What fields should I learn to query first?<\/strong><br\/>\n   Commonly: <code>logName<\/code>, <code>resource.type<\/code>, <code>protoPayload.methodName<\/code>, <code>protoPayload.authenticationInfo<\/code>, <code>protoPayload.authorizationInfo<\/code>, and timestamps.<\/p>\n<\/li>\n<li>\n<p><strong>Why do I see multiple log entries for one action?<\/strong><br\/>\n   Some operations involve multiple API calls (or retries), and multiple services can emit related logs. Also, exports through multiple sinks can duplicate data downstream.<\/p>\n<\/li>\n<li>\n<p><strong>Can I centralize audit logs across all projects?<\/strong><br\/>\n   Yes\u2014use organization-level (or folder-level) aggregated sinks to route logs to a central project\/destination.<\/p>\n<\/li>\n<li>\n<p><strong>Do audit logs help with \u201cwho accessed data\u201d reporting?<\/strong><br\/>\n   Yes, when Data Access logging is enabled and supported for the service. For high-volume datasets, plan carefully for cost, retention, and access controls.<\/p>\n<\/li>\n<li>\n<p><strong>What\u2019s the difference between Cloud Audit Logs and application logs?<\/strong><br\/>\n   Audit logs capture platform\/API activity; application logs capture your application\u2019s business and runtime events. Most organizations need both.<\/p>\n<\/li>\n<li>\n<p><strong>Can I use Cloud Audit Logs for real-time alerting?<\/strong><br\/>\n   Yes\u2014build alerts via Cloud Logging\/Monitoring (log-based metrics) or stream to Pub\/Sub and detect in a SIEM.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Cloud Audit Logs<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Cloud Audit Logs overview: https:\/\/cloud.google.com\/logging\/docs\/audit<\/td>\n<td>Canonical explanation of log types, payloads, and behavior<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Configure Data Access logs: https:\/\/cloud.google.com\/logging\/docs\/audit\/configure-data-access<\/td>\n<td>Step-by-step guidance for enabling\/disabling Data Access logging<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Cloud Logging Log Router overview: https:\/\/cloud.google.com\/logging\/docs\/routing\/overview<\/td>\n<td>Explains routing model, sinks, exclusions, and flow<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Export logs \/ sinks: https:\/\/cloud.google.com\/logging\/docs\/export<\/td>\n<td>Practical guidance for exporting to Storage\/BigQuery\/Pub\/Sub<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Cloud Logging pricing: https:\/\/cloud.google.com\/logging\/pricing<\/td>\n<td>Up-to-date pricing model for ingestion, retention, and features<\/td>\n<\/tr>\n<tr>\n<td>Official tool<\/td>\n<td>Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Build a real estimate using your expected log volumes and destinations<\/td>\n<\/tr>\n<tr>\n<td>Official console<\/td>\n<td>Logs Explorer: https:\/\/console.cloud.google.com\/logs\/query<\/td>\n<td>Main interface for querying and investigating audit logs<\/td>\n<\/tr>\n<tr>\n<td>Official docs<\/td>\n<td>Logging quotas and limits: https:\/\/cloud.google.com\/logging\/quotas<\/td>\n<td>Helps plan scale and avoid ingestion\/query\/export issues<\/td>\n<\/tr>\n<tr>\n<td>Official YouTube<\/td>\n<td>Google Cloud Tech channel: https:\/\/www.youtube.com\/@googlecloudtech<\/td>\n<td>Videos on Logging\/Security patterns (search within channel for audit logs)<\/td>\n<\/tr>\n<tr>\n<td>Trusted labs<\/td>\n<td>Google Cloud Skills Boost (search \u201cAudit Logs\u201d): https:\/\/www.cloudskillsboost.google\/<\/td>\n<td>Hands-on labs (availability varies; search for current audit\/logging labs)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>The following are training providers to explore for learning Google Cloud Security topics such as Cloud Audit Logs. Details can change\u2014verify on each website.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>DevOps + cloud operations; logging\/monitoring fundamentals<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Engineers and students<\/td>\n<td>DevOps, SCM, CI\/CD; operational practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations teams<\/td>\n<td>Cloud operations, governance, reliability<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, operations engineers<\/td>\n<td>Reliability engineering, monitoring, incident response<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops and automation teams<\/td>\n<td>AIOps concepts, automation, analytics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>These sites can be explored as trainer platforms\/resources. Validate current offerings and credentials directly.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps \/ cloud training content<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps coaching and mentoring<\/td>\n<td>Engineers seeking structured learning<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>DevOps consulting\/training resources<\/td>\n<td>Small teams and project-based learners<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and learning<\/td>\n<td>Ops teams needing practical help<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>Below are consulting companies to consider for Google Cloud logging\/auditing programs. Confirm service scope and references directly with each company.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting<\/td>\n<td>Architecture, implementation, automation<\/td>\n<td>Centralized audit log exports; IAM hardening for logging; SIEM pipeline design<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud consulting<\/td>\n<td>Training + implementation support<\/td>\n<td>Build org-level sinks; implement log-based alerting for IAM changes; operational runbooks<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting services<\/td>\n<td>DevOps\/SRE process and tooling<\/td>\n<td>Logging pipeline reviews; cost optimization for high-volume audit logs; access controls and governance<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Cloud Audit Logs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud fundamentals:<\/li>\n<li>Projects, folders, organizations<\/li>\n<li>IAM principals, roles, policies<\/li>\n<li>Basic networking concepts (for export consumers)<\/li>\n<li>Cloud Logging fundamentals:<\/li>\n<li>Logs Explorer queries<\/li>\n<li>Log buckets and retention concepts<\/li>\n<li>Log Router and sinks (high level)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Cloud Audit Logs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Advanced Cloud Logging:<\/li>\n<li>Centralized logging architecture<\/li>\n<li>Log views and access segmentation (verify current features)<\/li>\n<li>Log-based metrics and alerting patterns<\/li>\n<li>SIEM\/SOAR integrations:<\/li>\n<li>Pub\/Sub pipelines, schema normalization<\/li>\n<li>Google Cloud Security services:<\/li>\n<li>Security Command Center<\/li>\n<li>Organization policies, IAM Deny (if used)<\/li>\n<li>Detection engineering:<\/li>\n<li>Threat modeling for cloud control plane abuse<\/li>\n<li>Alert tuning and incident response playbooks<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Security Engineer \/ Security Analyst<\/li>\n<li>SRE \/ Production Engineer<\/li>\n<li>Platform Engineer<\/li>\n<li>DevOps Engineer<\/li>\n<li>Cloud Architect<\/li>\n<li>Compliance \/ GRC analyst (consumer of reports and evidence)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Google Cloud certifications that commonly align with audit logging knowledge include:\n&#8211; Professional Cloud Security Engineer\n&#8211; Professional Cloud Architect\n&#8211; Associate Cloud Engineer<\/p>\n\n\n\n<p>(Always verify current certification blueprints on Google Cloud\u2019s certification site.)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a \u201csecurity audit dashboard\u201d in BigQuery using exported Admin Activity logs.<\/li>\n<li>Create log-based alerts for:<\/li>\n<li>IAM policy changes<\/li>\n<li>Service account key creation<\/li>\n<li>Sink\/exclusion modifications<\/li>\n<li>Implement an org-level sink to a dedicated log archive project with strict IAM.<\/li>\n<li>Compare Data Access log volume\/cost across two configurations and document tradeoffs.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Admin Activity log<\/strong>: Audit log type for administrative\/configuration actions (e.g., create\/delete resources, change IAM).<\/li>\n<li><strong>Data Access log<\/strong>: Audit log type for reading\/writing user data (Data Read\/Data Write) and certain metadata reads (Admin Read).<\/li>\n<li><strong>System Event log<\/strong>: Audit log type for system-generated service events.<\/li>\n<li><strong>Policy Denied log<\/strong>: Audit log type emitted when a request is denied due to certain policy enforcement (coverage varies).<\/li>\n<li><strong>Cloud Logging<\/strong>: Google Cloud\u2019s managed logging platform where audit logs are stored, searched, and routed.<\/li>\n<li><strong>Log bucket<\/strong>: A container in Cloud Logging that stores logs with retention settings.<\/li>\n<li><strong>Log Router<\/strong>: Cloud Logging component that routes logs to buckets and destinations based on sinks and filters.<\/li>\n<li><strong>Sink<\/strong>: A routing rule that sends matching logs to a destination (Storage\/BigQuery\/Pub\/Sub\/log bucket).<\/li>\n<li><strong>Exclusion<\/strong>: A rule that drops matching logs (reduces volume\/cost, but can reduce visibility).<\/li>\n<li><strong>Principal<\/strong>: The identity making a request (user, group, service account, federated identity).<\/li>\n<li><strong>Service account<\/strong>: Non-human identity used by workloads\/automation.<\/li>\n<li><strong>protoPayload<\/strong>: Common audit log payload field containing method, authentication info, authorization info, and request\/response metadata.<\/li>\n<li><strong>methodName<\/strong>: The API method invoked (useful for detections and investigations).<\/li>\n<li><strong>resource.type<\/strong>: Logging resource type (e.g., <code>gcs_bucket<\/code>) used for filtering and analysis.<\/li>\n<li><strong>SIEM<\/strong>: Security Information and Event Management system for centralized security analytics.<\/li>\n<li><strong>Retention policy<\/strong>: How long logs are kept before deletion; can be configured in Cloud Logging buckets and Cloud Storage.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Cloud Audit Logs is Google Cloud\u2019s native audit trail for Security and operations: it records administrative actions, system events, policy denials, and (when enabled) data access events across supported services. It matters because it provides authoritative evidence for incident response, compliance, and change accountability.<\/p>\n\n\n\n<p>In Google Cloud, Cloud Audit Logs is managed and consumed through Cloud Logging\u2014where you query logs, control retention, and route\/export them using the Log Router and sinks. Cost and risk are primarily driven by Data Access audit logs and long retention\/export strategies, so production designs should be deliberate: enable what you need, centralize securely, restrict access to private logs, and monitor for logging configuration changes.<\/p>\n\n\n\n<p>Next step: learn Cloud Logging routing and exports in depth, then build a centralized organization-level audit logging architecture with least-privilege access and tested alerting for high-risk events.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Security<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[51,10],"tags":[],"class_list":["post-800","post","type-post","status-publish","format-standard","hentry","category-google-cloud","category-security"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/800","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=800"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/800\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}