Google ACE: Security, Compliance and Data Protection — Study Guide

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Part of the Google Associate Cloud Engineer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Security, compliance, and data protection on Google Cloud rely on a shared responsibility model and a secure-by-default, defense-in-depth approach. Google secures the physical infrastructure, foundational services, and default encryption, while you secure identity and access, data classification and retention, application configurations, and operational processes. Design for least privilege across the resource hierarchy, use groups over individuals, prefer managed identities and short-lived credentials, and layer controls so that the failure of any single control doesn’t result in compromise. Build observability and response workflows from the start so posture can be measured and improved continuously.

Identity and Access Foundations

• Shared responsibility and least privilege

  • Organize projects under a single organization with folders that mirror trust boundaries. Apply Organization Policy constraints to enforce secure defaults (for example, disallow public IPs, restrict locations, prevent service account key creation).
  • Grant IAM roles to Google Groups, not users, and prefer predefined roles over basic roles. Regularly review role bindings and remove unused entitlements.
  • Enable auditability and attribution. For admin OS access to VMs, use OS Login with per-user SSH keys; grant groups roles/compute.osLogin or roles/compute.osAdminLogin. Example:
    • gcloud compute project-info add-metadata –metadata enable-oslogin=TRUE
    • gcloud projects add-iam-policy-binding PROJECT_ID –member=‘group:ops@example.com’ –role=‘roles/compute.osAdminLogin’
  • Common failure modes: granting owner or editor to users, using project-wide SSH keys, and creating long-lived service account keys.

• Application access protection with BeyondCorp and Identity-Aware Proxy (IAP)

  • IAP terminates identity-aware access at Google’s edge for HTTPS apps and for TCP forwarding (SSH/RDP), eliminating the need to expose apps or bastions to the internet. Pair with context-aware access policies (Access Context Manager) to require device posture, IP ranges, or user groups.
  • Benefits: centralized authN/Z, strong attribution, reduced attack surface, and simplified firewall policy (deny inbound except load balancer/IAP).
  • Trade-offs: misconfiguration can lock out admins; keep a break-glass path (restricted project owner, out-of-band console access). Some legacy protocols or non-HTTP services may require IAP TCP forwarding or alternative controls.

• Service accounts and workload identity

  • Prefer attaching service accounts to Compute Engine, GKE with Workload Identity, Cloud Run, and Cloud Functions so workloads obtain short-lived tokens automatically. Avoid embedding keys; disable service account key creation with org policy. Scope IAM on service accounts narrowly (principle of least privilege).
  • Failure modes: granting roles/iam.serviceAccountUser broadly, which allows impersonation; overprivileged service accounts that become lateral-movement targets.

Data Protection and Key Management

• Encryption, Cloud KMS, CMEK, and envelope encryption

  • Google encrypts all data at rest and in transit by default. For additional control and segregation-of-duty, use Customer-Managed Encryption Keys (CMEK) in Cloud KMS. Many services (BigQuery, Cloud Storage, Pub/Sub, Compute Engine disks) support CMEK; services use envelope encryption where your CMEK wraps per-object or per-chunk DEKs.
  • Plan key hierarchy: key rings per region, crypto keys per data domain, and rotation every 90–365 days based on risk. Example rotation:
    • gcloud kms keys update KEY_NAME –keyring=KR –location=REGION –rotation-period=90d –next-rotation-time=YYYY-MM-DDT00:00:00Z
  • Access control: grant service accounts the Cloud KMS CryptoKey Encrypter/Decrypter role only on the needed keys. Monitor with Cloud KMS usage logs.
  • Failure modes and trade-offs: disabling or deleting a CMEK renders dependent data unreadable; plan incident runbooks, double-check IAM before rotation, and maintain key availability across deployments. Consider External Key Manager if you need to hold keys outside Google Cloud; account for added latency and external dependency risk.

• Secret Manager and eliminating hard-coded credentials

  • Store API keys, DB passwords, and tokens in Secret Manager with automatic versioning and IAM-based access. Integrate rotation via Cloud Scheduler → Pub/Sub → Cloud Functions/Run that updates the upstream system and writes a new secret version. Applications fetch secrets at startup or on demand and cache minimally.
  • Best practices: never commit secrets to code or images; avoid printing secrets to logs; grant roles/secretmanager.secretAccessor to workload identities; use labels to tag sensitivity.
  • Failure modes: embedding secrets in environment variables that get logged in crashes; forgetting to update downstream apps after rotation; broad IAM on secrets.

• Data classification, retention, and privacy

  • Classify data (public, internal, confidential, regulated) and tag assets with labels. Use BigQuery column-level security and row access policies for fine-grained control. For discovery and masking, use Sensitive Data Protection (DLP).
  • Implement retention: Cloud Storage Object Lifecycle (age-based class transitions, delete), bucket retention policies with holds, and BigQuery table or partition TTLs. Align retention to legal needs; longer retention increases risk and cost.
  • Privacy and residency: restrict resource locations with org policies; choose multi-regional vs regional storage based on sovereign and latency requirements. Produce evidence with audit logs and SCC posture dashboards.

Network and Edge Security

• Defense in depth for networks

  • Use VPC firewall rules with a default deny stance; allow only necessary source ranges and ports. Prefer Private Google Access and Private Service Connect to keep API traffic off the public internet. Log VPC Flow Logs and Firewall Rules Logging; review egress patterns regularly.
  • For outbound control, deny-all egress then explicitly allow necessary destinations via FQDN egress proxy or NAT plus proxy. Monitor Cloud NAT logs and configure DNS logging.

• VPC Service Controls (VPC SC), service perimeters, and access levels

  • Wrap supported Google APIs (for example, BigQuery, Storage, Pub/Sub) in service perimeters to mitigate data exfiltration risks, even if credentials are compromised. Use Access Context Manager to define access levels by user group, IP, or device posture, enabling context-aware policies.
  • Configure egress rules for legitimate cross-perimeter integrations and perimeter bridges when needed. Test with VPC SC dry-run mode to surface potential breaks before enforcement.
  • Failure modes: blocking CI/CD or cross-project jobs unintentionally, third-party integrations failing, or developers bypassing with unmanaged devices. Document exceptions and review regularly.

• Cloud Armor, DDoS protection, and WAF rules

  • Google’s global edge provides always-on L3/L4 DDoS protection. Cloud Armor adds L7 protections for external HTTP(S) load balancers, including rate limiting, geo/IP-based access, custom expressions, and preconfigured WAF rule sets.
  • Example to create and attach a basic WAF:
    • gcloud compute security-policies create web-waf
    • gcloud compute security-policies rules create 1000 –security-policy=web-waf –expression=“evaluatePreconfiguredWaf(‘sqli-v33-stable’)” –action=deny-403 –preview
    • Attach the policy to your HTTPS load balancer backend service.
  • Best practices: start rules in preview to reduce false positives, add allow rules for known-good traffic, and enable adaptive protection if eligible. Trade-offs: Cloud Armor enforces on HTTP(S) and proxy-based load balancers; network load balancers and internal LBs require other controls.

Security Operations and Compliance

• Security Command Center (SCC) and posture management

  • Use SCC as the control plane for risk visibility. The Standard tier aggregates misconfiguration findings and vulnerability data; the Premium tier adds threat detections (for example, Event Threat Detection, VM and Container Threat Detection) and attack path insights.
  • Triage findings by severity, assign owners, and track to closure. Export findings to BigQuery or Pub/Sub for SIEM integration and evidence. Continuously measure posture against organization policies and set alerting on regressions.

• Shielded VM, secure boot, vTPM, integrity monitoring, and OS hardening

  • Enable Shielded VM features to block rootkits and boot tampering: Secure Boot, vTPM, and Integrity Monitoring to detect changes in bootloaders and kernel. Some custom kernels or unsigned modules may fail Secure Boot; validate images before enabling.
  • Harden OS with OS Config for patch compliance, CIS-aligned baselines, minimal packages, no password SSH, and logging of sudo and auth events. Prefer IAP TCP forwarding for SSH and restrict ingress to 0.0.0.0/0.

• Forensic logging, incident triage, containment, and remediation

  • Logging to enable forensics: Admin Activity and Data Access audit logs, VPC Flow Logs, Firewall Rules Logging, Cloud DNS logs, load balancer logs, and Cloud KMS and Secret Manager access logs. Export to a centralized log project and BigQuery with appropriate retention and access controls.
  • Triage and containment playbook:
    • Validate indicators with SCC findings and correlated logs.
    • Contain by revoking suspicious tokens, disabling compromised service accounts, adding deny firewall rules or temporarily isolating instances with tags.
    • Preserve evidence: snapshot disks, export logs, capture memory if required using approved tooling, and record chain-of-custody.
    • Remediate: rotate secrets and keys, patch vulnerabilities, rebuild from known-good images, add detections to prevent recurrence, and perform post-incident review to strengthen controls.

Practical Problem Scenario

Nimbus Finance runs web and API workloads behind external HTTP(S) load balancers, processes regulated data in BigQuery and Cloud Storage, and allows engineers remote admin access. A recent red-team exercise demonstrated risks of data exfiltration via compromised credentials and lateral movement. The operations team must harden access, protect data, and improve detection without disrupting delivery.

1. Enforce OS Login with admin attribution

• Steps: Enable OS Login project-wide; add compute.osAdminLogin to the engineers group; remove project-wide SSH keys.
• Rationale: Per-user SSH keys and IAM-based role grants provide clear attribution and simple revocation. Eliminating shared keys reduces lateral movement.

2. Gate remote access with IAP and context-aware access

• Steps: Place the admin UI behind an HTTPS load balancer protected by IAP; require membership in the ops group and corporate IP/device posture via Access Context Manager.
• Rationale: Zero-trust access removes public exposure and centrally enforces identity and device conditions, reducing phishing and credential-stuffing risk.

3. Implement Cloud Armor WAF with staged enforcement

• Steps: Create a Cloud Armor policy; enable preconfigured WAF rules for SQLi/XSS in preview; add a rate-limiting rule for /login; monitor logs; then enforce.
• Rationale: Preview reduces false positives; targeted rate limits blunt credential stuffing and bots without harming legitimate traffic.

4. Wrap data services in VPC Service Controls

• Steps: Create a service perimeter for BigQuery and Cloud Storage projects; define egress rules for approved CI/CD and analytics jobs; require access levels based on group and network.
• Rationale: Perimeters mitigate data exfiltration using valid credentials by restricting where and how protected data can be accessed.

5. Apply CMEK with Cloud KMS and schedule rotation

• Steps: Create regional key rings and crypto keys for BigQuery and Storage; grant only service accounts roles/cloudkms.cryptoKeyEncrypterDecrypter; set a 180-day rotation schedule; monitor key usage logs.
• Rationale: CMEK enforces separation of duties and controlled cryptographic boundaries; rotation limits blast radius if a key is exposed.

6. Centralize secrets with Secret Manager and automate rotation

• Steps: Move database and third-party tokens into Secret Manager; grant least-privilege access to workloads; implement a Cloud Scheduler → Pub/Sub → Cloud Run job to rotate secrets and create new versions.
• Rationale: Eliminates hard-coded credentials; versioning and automation ensure predictable, auditable rotation with minimal downtime.

7. Strengthen host security with Shielded VM and OS hardening

• Steps: Enable Secure Boot, vTPM, and Integrity Monitoring on all Compute Engine instances; enforce no password SSH; use OS Config to patch weekly and apply CIS baselines.
• Rationale: Prevents boot-level tampering, detects drift, and reduces exploitable surface on compute nodes.

8. Increase observability and posture management with SCC

• Steps: Enable SCC Premium across the organization; configure real-time notifications to Pub/Sub; export findings and logs to BigQuery; build dashboards for key KPIs (open high findings, mean time to remediate).
• Rationale: Unified visibility shortens detection-to-response windows and provides compliance evidence.

9. Prepare and test an incident playbook

• Steps: Document triage steps, privileged break-glass accounts, and containment actions (IAM disable, firewall isolate, revoke tokens); practice quarterly; enforce log retention and object holds in the evidence project.
• Rationale: Practiced workflows reduce errors under pressure and preserve forensic integrity for root cause analysis and regulatory reporting.

10. Validate changes and minimize disruption

• Steps: Use VPC SC dry run and Cloud Armor preview to detect breakage; roll out by environment with canaries; maintain a rollback plan and change windows.
• Rationale: Controlled rollout mitigates availability risks from tightened security while achieving the targeted reduction in exfiltration and access risk.

← Monitoring · All domains · Reliability →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Google →