GCP-ACE
Google Cloud Associate Cloud Engineer
The Google Cloud Associate Cloud Engineer certification validates the ability to deploy applications, monitor operations, and manage enterprise solutions on Google Cloud. This certification is designed for cloud professionals who perform day-to-day tasks to provision, configure, and maintain cloud solution environments.
The exam covers setting up a cloud solution environment, planning and configuring a cloud solution, deploying and implementing a cloud solution, ensuring successful operation of a cloud solution, and configuring access and security. Candidates should have hands-on experience with Google Cloud Console, Cloud Shell, gcloud CLI, and core services including Compute Engine, Google Kubernetes Engine, Cloud Storage, Cloud SQL, VPC networking, Cloud IAM, and Cloud Operations.
This certification is recommended for professionals with at least six months of hands-on experience working with Google Cloud. It validates the technical skills needed to work effectively with Google Cloud technologies and demonstrates the ability to use the Console and command-line interface to perform common platform-based tasks and maintain deployed solutions.
GCP-ACE Practice Exam 1
Comprehensive 50-question practice exam covering Google Cloud Associate Cloud Engineer topics including project setup, billing management, IAM configuration, compute and storage planning, VPC networking, and resource hierarchy.
GCP-ACE Practice Exam 2
Second comprehensive 50-question practice exam for the Google Cloud Associate Cloud Engineer certification covering cloud project management, compute and networking deployment, GKE operations, monitoring, and security best practices.
GCP-ACE Practice Exam 3
Third comprehensive 50-question practice exam for the Google Cloud Associate Cloud Engineer certification. Covers resource hierarchy design, hybrid networking, container orchestration, operational excellence, and identity management.
GCP-ACE Practice Exam 4
Fourth comprehensive 50-question practice exam for the Google Cloud Associate Cloud Engineer certification. Covers environment setup, compute and storage planning, infrastructure deployment, operational management, and security configuration.
GCP-ACE Practice Exam 5
Fifth practice exam for Google Cloud Associate Cloud Engineer certification. Covers all exam domains with scenario-based questions on cloud solution environment setup, planning and configuration, deployment and implementation, operations management, and access and security configuration.
GCP-ACE Practice Exam 6
Sixth practice exam for Google Cloud Associate Cloud Engineer certification. Covers all exam domains with scenario-based questions on cloud solution environment setup, planning and configuration, deployment and implementation, operations management, and access and security configuration.
Unlock All Content for GCP-ACE
6 Practice Test(s) + Flash Cards — 3 months access
or included with Monthly subscription / Content Bundle
Preview (10 / 120)
Flash Cards
cards covering key 120 concepts GCP-ACE
or included with Monthly subscription / Content Bundle
110 more cards available after unlock
Available Languages
Exam Topics
GCP-ACE Cheat Sheet
Quick reference guide - 6 sections
Google Cloud Associate Cloud Engineer (GCP-ACE)
The Associate Cloud Engineer certification validates your ability to deploy and manage applications, monitor operations, and maintain cloud projects on Google Cloud Platform. This is a hands-on, practitioner-level certification designed for cloud engineers who use the Google Cloud Console and the gcloud command-line interface to perform platform-based tasks on a daily basis. You are expected to be proficient in creating and managing Compute Engine virtual machines, configuring GKE clusters, deploying applications on App Engine and Cloud Run, managing Cloud Storage buckets and lifecycle policies, setting up VPC networks with firewall rules and load balancers, and configuring IAM policies that follow the principle of least privilege. The exam emphasizes real-world scenarios where you must choose the most appropriate Google Cloud service, configuration, or CLI command for a given requirement. Candidates typically have six months or more of hands-on experience working with Google Cloud in a production or lab environment. The exam tests not only your knowledge of individual services but also your ability to integrate them into complete solutions that are secure, cost-effective, and operationally sound. This certification is an excellent stepping stone toward the Professional Cloud Architect and other advanced Google Cloud certifications, and it demonstrates to employers that you can independently manage cloud infrastructure at scale.
Exam Details
| Exam Code | Associate Cloud Engineer |
| Duration | 120 minutes |
| Number of Questions | 50-60 questions |
| Passing Score | 70% (approximately) |
| Cost | $200 USD |
| Validity | 2 years (recertification required) |
| Question Types | Multiple choice and multiple select |
| Testing Options | Kryterion testing center or online proctored |
| Recommended Experience | 6+ months hands-on experience with Google Cloud |
| Certification Level | Associate |
Domain Weights
| Domain | Weight |
|---|---|
| Domain 1: Setting Up a Cloud Solution Environment | ~17.5% |
| Domain 2: Planning and Configuring a Cloud Solution | ~17.5% |
| Domain 3: Deploying and Implementing a Cloud Solution | ~25% |
| Domain 4: Ensuring Successful Operation of a Cloud Solution | ~20% |
| Domain 5: Configuring Access and Security | ~20% |
Study Tips
- Get extensive hands-on practice with the gcloud CLI; a large portion of exam questions test your ability to recall specific commands, flags, and their correct syntax for creating, updating, describing, and deleting resources across Compute Engine, GKE, App Engine, Cloud Run, and IAM
- Understand the resource hierarchy deeply: Organization, Folders, Projects, and Resources; know how IAM policies inherit downward through the hierarchy and that child policies can only add permissions, never remove those granted at a parent level
- Know the differences between all compute options (Compute Engine, GKE, App Engine Standard, App Engine Flexible, Cloud Run, and Cloud Functions) and be able to select the right service based on requirements like language support, scaling behavior, container support, cost model, and operational overhead
- Practice configuring VPC networks, subnets, firewall rules, Cloud NAT, and load balancers as networking questions appear across multiple domains and are commonly tested in scenario-based formats
- Study all database and storage services (Cloud SQL, Cloud Spanner, Bigtable, Firestore, BigQuery, Cloud Storage, Memorystore) so you can recommend the correct option for transactional, analytical, NoSQL, caching, or object storage workloads
- Review billing concepts including budgets, alerts, billing export to BigQuery, committed use discounts, sustained use discounts, labels for cost allocation, and how to set up programmatic budget notifications via Pub/Sub
- Use Qwiklabs and Google Cloud Skills Boost to practice in a real Google Cloud environment; the exam rewards practical experience over theoretical knowledge, and hands-on labs help cement gcloud command syntax and service configuration workflows
Resource Hierarchy and Projects
Google Cloud organizes resources into a hierarchy that governs ownership, access control, and policy inheritance. Every resource you create belongs to exactly one project, and projects are the fundamental organizational unit for billing, API enablement, and resource management. The Organization node sits at the top of the hierarchy and is tied to a Google Workspace or Cloud Identity domain. Folders provide grouping beneath the organization and can be nested to represent departments, teams, or environments such as development, staging, and production. IAM policies set at any level are inherited by all child resources below, and this inheritance is additive, meaning a child resource cannot restrict permissions granted at a parent level. Organization policies (distinct from IAM policies) set constraints on resource configurations and also inherit downward. Understanding this hierarchy is fundamental because it determines how billing flows, how IAM policies propagate, and how administrators delegate control across the organization.
| Hierarchy Level | Key Attributes | gcloud Commands |
|---|---|---|
| Organization | Root node; tied to Google Workspace or Cloud Identity domain; org policies apply globally; managed by Organization Admin role; automatically created when domain is verified | gcloud organizations list; gcloud organizations describe ORG_ID |
| Folder | Optional grouping layer; can be nested up to 10 levels deep; inherits org policies from parent; useful for department-level isolation and delegated administration; requires resourcemanager.folders.create permission | gcloud resource-manager folders create --display-name=NAME --organization=ORG_ID; gcloud resource-manager folders list --organization=ORG_ID |
| Project | Core billing and resource unit; unique project ID (immutable, globally unique), display name (mutable), project number (auto-assigned); must be linked to a billing account to use paid services; 30-day recovery period after deletion | gcloud projects create PROJECT_ID --name=NAME --folder=FOLDER_ID; gcloud projects list; gcloud projects describe PROJECT_ID |
| Resources | VMs, buckets, databases, clusters, functions, etc.; belong to exactly one project; inherit IAM from parent hierarchy; some are global (images), some regional (subnets), some zonal (VM instances) | Service-specific (e.g., gcloud compute instances list, gcloud storage ls) |
Exam Tip: A project ID is globally unique and immutable once created. A project name is mutable and not unique. Many exam questions test whether you know which identifier to use in commands and configurations. Always use project ID in gcloud commands, not the display name.
Billing Configuration
| Concept | Description |
|---|---|
| Billing Account | Defines who pays for GCP usage; can be linked to multiple projects; supports self-serve (credit card) or invoiced billing; requires Billing Account Administrator role to manage; Billing Account User role allows linking projects to the billing account |
| Budgets & Alerts | Set spending thresholds per billing account or per project; notification emails sent at configurable percentages (e.g., 50%, 90%, 100%); can trigger Pub/Sub topic for programmatic actions such as disabling billing or shutting down resources via Cloud Functions; budgets do NOT cap or stop spending by default |
| Billing Export | Export detailed billing data to BigQuery for advanced cost analysis, trending dashboards, and custom reports using SQL; also supports export to a Cloud Storage bucket as CSV files; BigQuery export includes resource-level cost breakdowns with labels and project attribution |
| Labels | Key-value metadata tags attached to resources for cost allocation, organization, and filtering; filter billing reports and exports by labels; examples: env:prod, team:frontend, cost-center:engineering; up to 64 labels per resource; keys must be lowercase, max 63 characters |
| Committed Use Discounts | 1 or 3-year commitments for predictable workloads; resource-based CUDs commit to specific vCPU and memory amounts; spend-based CUDs commit to a minimum hourly spend on specific services; up to 57% savings for 3-year resource CUDs; applies automatically to matching usage across the billing account |
| Sustained Use Discounts | Automatic discounts for Compute Engine VMs and GKE nodes running more than 25% of the month; no commitment required; up to 30% discount for VMs running the entire month; applies to N1 and N2 machine types (not E2); calculated and applied automatically on the billing invoice |
Exam Tip: Budgets and alerts only send notifications; they do not automatically stop or restrict resource usage. To actually stop spending when a budget is exceeded, you must set up a Cloud Function triggered via Pub/Sub that programmatically disables billing on the project using the Cloud Billing API.
Cloud SDK and gcloud Configuration
| Command | Purpose |
|---|---|
| gcloud init | Initialize or reinitialize gcloud configuration interactively; sets default project, region, and zone; walks through authentication; creates a named configuration called "default" if none exists |
| gcloud config set project PROJECT_ID | Set the active project for subsequent commands; avoids passing --project flag on every command; stored in the active configuration |
| gcloud config set compute/region REGION | Set default Compute Engine region; avoids passing --region on each command; common regions: us-central1, us-east1, europe-west1, asia-east1 |
| gcloud config set compute/zone ZONE | Set default Compute Engine zone; avoids passing --zone on each command; zones are within regions (e.g., us-central1-a, us-central1-b) |
| gcloud config configurations create NAME | Create a named configuration for managing multiple accounts or projects; each configuration stores its own project, account, region, and zone; switch with gcloud config configurations activate NAME |
| gcloud config list | Display all properties in the active configuration; shows current project, account, region, and zone; useful for verifying which context you are operating in before running commands |
| gcloud auth login | Authenticate your user account; opens a browser for OAuth consent; credentials stored locally in ~/.config/gcloud; used for interactive CLI sessions |
| gcloud auth application-default login | Set Application Default Credentials (ADC) for local development; used by client libraries (Python, Java, Go, Node.js) to authenticate API calls; separate from gcloud auth login credentials |
| gcloud auth activate-service-account | Authenticate using a service account key file; gcloud auth activate-service-account --key-file=KEY.json; used in CI/CD pipelines and automated scripts; prefer Workload Identity Federation when possible |
Enabling APIs and Services
Before you can use any Google Cloud service in a project, you must enable its API. This is a per-project setting and is required even if the same API is enabled in another project within the same organization. When you create resources through the Console, the required API may be enabled automatically, but when scripting with gcloud or deploying with infrastructure as code, you must explicitly enable the API first. Disabling an API does not delete resources created using it, but it prevents new API calls. Some APIs have dependencies that must also be enabled. The Compute Engine API, Kubernetes Engine API, Cloud Functions API, Cloud Run API, and Cloud Storage API are among the most commonly required for the ACE exam.
| Command | Purpose |
|---|---|
| gcloud services enable SERVICE_NAME | Enable an API (e.g., compute.googleapis.com, container.googleapis.com, cloudfunctions.googleapis.com, run.googleapis.com) |
| gcloud services list --enabled | List all currently enabled APIs in the active project |
| gcloud services list --available | Discover all available APIs that can be enabled in the project |
Compute Engine (Virtual Machines)
Compute Engine provides Infrastructure as a Service (IaaS) with full control over virtual machines running on Google's infrastructure. You choose the machine type, operating system image, disk configuration, networking, and availability options. Compute Engine is the most flexible compute option and is the right choice when you need full OS-level control, custom kernel modules, GPU-attached workloads, lift-and-shift migrations, or applications that are not designed for containers or serverless environments. For the ACE exam, you must be deeply familiar with gcloud compute commands for creating, managing, and troubleshooting VM instances.
| Feature | Description |
|---|---|
| Machine Families | General-purpose (E2 cost-optimized, N2/N2D balanced, T2D/T2A AMD/Arm), Compute-optimized (C2, C2D for HPC and gaming), Memory-optimized (M2, M3 for SAP HANA and large databases), Accelerator-optimized (A2, G2 for ML training and inference with GPUs); custom machine types let you specify exact vCPU and memory amounts |
| Persistent Disks | Network-attached block storage; types: pd-standard (HDD, lowest cost), pd-balanced (SSD, good balance), pd-ssd (SSD, highest IOPS), pd-extreme (SSD, highest throughput for databases); survive VM deletion; can be resized without downtime (only increase); snapshots for incremental backup; can attach read-only to multiple VMs |
| Local SSDs | Physically attached to the host machine; extremely low latency and high IOPS; data is ephemeral (lost on stop, preemption, or host maintenance); fixed sizes (375 GB per device); ideal for caches, scratch disks, and temporary processing |
| Instance Templates | Define machine type, boot disk image, network tags, labels, startup script, service account, and metadata; immutable once created; used by Managed Instance Groups (MIGs) to create identical VMs; update by creating a new template and performing a rolling update on the MIG |
| Managed Instance Groups | Group of identical VMs based on an instance template; supports autoscaling (based on CPU, LB utilization, Pub/Sub queue depth, or custom metrics), autohealing (health check-based VM recreation), rolling updates (canary or proactive), and multi-zone deployment for high availability; integrates with HTTP(S) and TCP/UDP load balancers |
| Spot / Preemptible VMs | Up to 60-91% cheaper than regular VMs; can be reclaimed by Google with 30 seconds notice; Spot VMs replace legacy Preemptible VMs with the same pricing model but no 24-hour maximum runtime; ideal for batch jobs, rendering, CI/CD, and data processing; not suitable for serving live user traffic |
| Sole-Tenant Nodes | Dedicated physical servers for your VMs only; required for bring-your-own-license (BYOL) scenarios, compliance requirements, or workloads that must not share hardware; node groups define the node type and autoscaling policy |
Exam Tip: Memorize the core VM creation command: gcloud compute instances create NAME --machine-type=TYPE --zone=ZONE --image-family=IMAGE_FAMILY --image-project=IMAGE_PROJECT. Know the difference between --metadata startup-script="INLINE_SCRIPT" and --metadata-from-file startup-script=FILE_PATH. Use --preemptible or --provisioning-model=SPOT for cost savings on fault-tolerant workloads.
Google Kubernetes Engine (GKE)
| Concept | Description |
|---|---|
| Cluster Modes | Standard mode: you manage node pools, configure autoscaling, and handle node upgrades; Autopilot mode: Google manages the node infrastructure entirely, you only define pods, pay per pod resource request, and Google enforces best practices (security, networking, resource management); Autopilot is recommended for most new clusters |
| Node Pools | Group of nodes with identical configuration within a cluster; each pool can have different machine types, disk sizes, and OS images; enable per-pool autoscaling with min and max node counts; use taints and tolerations to schedule specific workloads on specific node pools; preemptible/spot node pools for cost savings on fault-tolerant pods |
| Workload Identity | Recommended way for GKE pods to authenticate to Google Cloud APIs; maps Kubernetes service accounts to Google Cloud service accounts; eliminates need for service account key files inside pods; enabled per cluster and configured per namespace; replaces the insecure pattern of mounting JSON key files as secrets |
| Deployments & Services | Deployment manages pod replicas with declarative updates and rollbacks; Service types: ClusterIP (internal only), NodePort (static port on each node), LoadBalancer (external L4 with GCP network LB); Ingress resource creates an external HTTP(S) Load Balancer for URL-based routing and TLS termination |
| Key CLI Commands | gcloud container clusters create CLUSTER --zone=ZONE --num-nodes=3; gcloud container clusters get-credentials CLUSTER --zone=ZONE (configures kubectl context); kubectl apply -f deployment.yaml; kubectl get pods/services/deployments; kubectl scale deployment NAME --replicas=N; kubectl rollout status/undo deployment NAME |
Exam Tip: The command gcloud container clusters get-credentials is required before using kubectl against a GKE cluster. It writes cluster connection details to ~/.kube/config. For Autopilot clusters, use gcloud container clusters create-auto.
Serverless Compute Options
| Service | Best For | Key Features |
|---|---|---|
| App Engine Standard | Web apps in supported runtimes (Python, Java, Go, Node.js, PHP, Ruby) | Scales to zero; automatic versioning with traffic splitting for canary deployments; sandbox environment with limited system access; free daily quota for small apps; one App Engine app per project (cannot delete, only disable); deploy with gcloud app deploy |
| App Engine Flexible | Apps needing custom runtimes, native dependencies, or background processes | Runs in Docker containers on Compute Engine VMs; SSH access to instances; supports any language via custom Dockerfiles; does NOT scale to zero (minimum 1 instance); higher cost but more flexibility; longer deployment times |
| Cloud Run | Stateless containers triggered by HTTP requests, gRPC, events, or schedules | Scales to zero; any language or library via containers; pay per request (CPU allocated only during request processing) or always-on instances; concurrency settings (up to 1000 per instance); revision-based traffic splitting; deploy from source, Dockerfile, or container image; gcloud run deploy |
| Cloud Functions | Lightweight event-driven code: webhooks, ETL glue, event processing, IoT triggers | Event-driven triggers: HTTP, Pub/Sub, Cloud Storage, Firestore, Firebase, Eventarc; single-purpose functions; pay per invocation and execution time; Gen 2 (recommended) is built on Cloud Run and supports concurrency, longer timeouts (up to 60 min), and larger instances; Gen 1 limited to 9 min timeout and single concurrency |
Exam Tip: Cloud Run is the most versatile serverless option since it supports any language or binary via containers, handles both HTTP and event-driven workloads, and scales to zero. App Engine is limited to one application per project and cannot be deleted once created (only disabled). Cloud Functions Gen 2 is built on Cloud Run under the hood. When a question requires running containers without managing infrastructure, Cloud Run is almost always the answer.
Data Storage and Database Services
| Service | Type | When to Use |
|---|---|---|
| Cloud Storage | Object storage (blobs) | Unstructured data: images, videos, backups, logs, static website hosting, data lake staging; storage classes: Standard (hot), Nearline (30-day min), Coldline (90-day min), Archive (365-day min); lifecycle rules automate class transitions and deletion; gsutil or gcloud storage commands; globally unique bucket names |
| Cloud SQL | Managed relational (MySQL, PostgreSQL, SQL Server) | OLTP workloads up to 64TB; web app backends; CMS systems; regional HA with automatic failover using synchronous replication; read replicas for scaling reads; automated backups and point-in-time recovery; connect via Cloud SQL Auth Proxy for secure, IAM-based access |
| Cloud Spanner | Globally distributed relational | Horizontal scaling with strong consistency and SQL support; financial trading systems, global user directories; 99.999% SLA (multi-region); expensive but unmatched for globally consistent ACID transactions at scale |
| Firestore | NoSQL document database | Mobile and web apps; real-time sync and offline support; hierarchical data with collections and documents; serverless scaling; strong consistency; free daily quota; replaces Datastore (Firestore in Native mode vs Datastore mode) |
| Bigtable | NoSQL wide-column store | IoT time-series, financial data, ad tech analytics; sub-10ms latency at petabyte scale; HBase API compatible; no SQL support (use key-based access patterns); minimum 1 node cluster; ideal for high-throughput read/write workloads with simple key-value access |
| BigQuery | Serverless data warehouse | OLAP analytics over petabytes; standard SQL interface; separate storage and compute billing (on-demand or flat-rate slots); built-in ML with BigQuery ML; streaming inserts for real-time analysis; materialized views; external tables can query Cloud Storage, Bigtable, and Cloud SQL directly |
| Memorystore | Managed Redis / Memcached | In-memory caching and session storage; sub-millisecond latency; fully managed with HA and automatic failover (Redis); reduces database load for read-heavy applications; supports Redis data structures, Pub/Sub, and Lua scripting |
VPC Networking Fundamentals
A Virtual Private Cloud (VPC) in Google Cloud is a global resource that spans all regions automatically, unlike other cloud providers where VPCs are regional. Subnets within a VPC are regional resources, meaning a single subnet spans all zones within its region. When you create a project, a default VPC with auto-mode subnets is created automatically. You can also create custom-mode VPCs where you define subnets and IP ranges manually, which is recommended for production environments. VPCs provide network isolation, firewall rules, routes, and the foundation for all network communication between Google Cloud resources. Understanding VPC design is essential for the exam, especially around subnet IP addressing, Private Google Access, cross-project networking with Shared VPC, and VPC peering limitations.
| Concept | Description |
|---|---|
| Auto-mode VPC | Automatically creates one subnet per region with predefined IP ranges from the 10.128.0.0/9 block; new regions get subnets automatically; convenient for simple setups and development; can be converted to custom-mode (one-way, irreversible) |
| Custom-mode VPC | No subnets created automatically; you define each subnet with its own CIDR range (RFC 1918 private ranges); recommended for production; full control over IP address planning; avoids IP overlap issues when peering VPCs; can expand subnet ranges without downtime (only increase, never shrink) |
| Shared VPC | Host project owns the VPC network and subnets; service projects create resources (VMs, GKE clusters) in the shared subnets; centralizes network administration while delegating resource creation; requires Organization-level setup; ideal for multi-project organizations that need unified network policies and IP management |
| VPC Peering | Private connectivity between two VPCs using internal IPs; works across projects and organizations; non-transitive (if A peers with B and B peers with C, A cannot reach C through B); both sides must configure peering; IP ranges must not overlap; no single point of failure and no bandwidth bottleneck (uses Google's internal network fabric) |
| Private Google Access | Allows VMs without external IPs to reach Google APIs and services (Cloud Storage, BigQuery, Pub/Sub) over internal networking; enabled per subnet; does not apply to external, non-Google services; essential for VMs in private subnets that need to access GCS or other Google APIs |
| Cloud NAT | Managed Network Address Translation for VMs without external IPs to access the internet for outbound connections (package updates, API calls to external services); regional resource; does not allow unsolicited inbound connections; configured per VPC network and region; no VM-level configuration required |
Exam Tip: VPCs are global but subnets are regional. VPC Peering is non-transitive. Shared VPC is for centralized network management across projects within the same organization. Cloud NAT provides outbound-only internet access for private VMs. Private Google Access provides access to Google APIs without external IPs. Know when to use each.
Firewall Rules
| Property | Description |
|---|---|
| Direction | Ingress (incoming to VMs) or Egress (outgoing from VMs); each rule applies to one direction only; specify separately |
| Priority | 0 (highest priority) to 65535 (lowest); lower number wins when multiple rules match; default rules have priority 65534 (allow internal, allow SSH, allow RDP, allow ICMP) and 65535 (implied deny-all ingress, allow-all egress) |
| Action | Allow or Deny; cannot combine in a single rule; use priority ordering to build complex policies (e.g., deny a specific IP at priority 100, allow all at priority 1000) |
| Target | All instances in the VPC, instances with specific network tags (--target-tags), or instances running as a specific service account (--target-service-accounts); network tags are the most common targeting method |
| Source/Destination | IP ranges (CIDR), network tags (source only, for ingress), or service accounts; for ingress rules define source; for egress rules define destination; 0.0.0.0/0 means all IPv4 addresses |
Exam Tip: Default VPC pre-populates four allow rules: default-allow-internal (all protocols between VPC instances), default-allow-ssh (TCP:22 from 0.0.0.0/0), default-allow-rdp (TCP:3389), and default-allow-icmp. Custom-mode VPCs start with only the implied deny-all ingress and allow-all egress rules. Create rules with gcloud compute firewall-rules create.
Load Balancing Options
| Load Balancer | Scope | Use Case |
|---|---|---|
| External HTTP(S) LB | Global | Web applications; layer 7 URL-based routing; SSL termination with managed certificates; Cloud CDN integration; Cloud Armor WAF protection; single anycast IP serving users globally from nearest backend |
| Internal HTTP(S) LB | Regional | Internal microservices; gRPC and HTTP/2 support; proxy-based; runs in your VPC; not internet-facing; URL map routing for path-based internal traffic management |
| External TCP/UDP Network LB | Regional | Non-HTTP external traffic; preserves client IP; pass-through (no proxy, no SSL termination); gaming servers, VoIP, custom TCP/UDP protocols; backend service or target pool |
| Internal TCP/UDP LB | Regional | Internal non-HTTP services; load balance internal database or application tier traffic; pass-through within VPC; supports being used as a next hop for custom routes |
| SSL Proxy LB | Global | Non-HTTP SSL/TLS traffic; SSL offload at Google's edge; supports TCP with SSL termination; ideal for non-web SSL workloads that need global reach |
| TCP Proxy LB | Global | Non-HTTP, non-SSL TCP traffic; intelligent global routing to nearest healthy backend; terminates TCP connections at the edge; does not preserve client IP |
Hybrid Connectivity
| Option | Bandwidth | Description |
|---|---|---|
| Cloud VPN (HA VPN) | Up to 3 Gbps per tunnel | IPsec encrypted tunnels over the public internet; HA VPN provides 99.99% SLA with two tunnels in active/active or active/passive configuration; Classic VPN (legacy) provides 99.9% SLA; suitable for moderate bandwidth needs; encrypted by default; quick to set up |
| Dedicated Interconnect | 10 or 100 Gbps per link | Physical fiber connection at a Google colocation facility; lowest latency and highest bandwidth; 99.99% SLA with recommended redundant topology; not encrypted by default (add your own if required); for organizations with high-volume, latency-sensitive data transfer |
| Partner Interconnect | 50 Mbps to 50 Gbps | Connect through a supported service provider partner; for organizations that cannot reach a Google colocation facility; flexible bandwidth tiers; 99.99% SLA with redundant connections; provider handles the physical connection to Google |
| Cloud DNS | N/A | Managed authoritative DNS service; 100% availability SLA; public zones for internet-facing domains; private zones for VPC-internal name resolution; DNS peering for cross-VPC resolution; DNSSEC support for domain verification; managed with gcloud dns managed-zones and record-sets commands |
Exam Tip: For connecting on-premises to GCP: use Cloud VPN for encrypted, lower-bandwidth connections; use Dedicated Interconnect for high-bandwidth direct connections at a colocation facility; use Partner Interconnect when you cannot physically reach a Google colocation. HA VPN requires a Cloud Router for dynamic BGP routing.
Identity and Access Management (IAM)
Google Cloud IAM controls who (identity/principal) has what access (role) to which resource. IAM follows the principle of least privilege: grant only the minimum permissions necessary for a user or service account to perform their tasks. IAM policies are additive and inherit downward through the resource hierarchy. If a role is granted at the organization level, it applies to every folder, project, and resource below it. You cannot revoke a parent-level permission at a child level. Deny policies, a more recent feature, allow you to set explicit deny rules that override allow bindings at any level of the hierarchy. Understanding IAM is arguably the most critical skill for the ACE exam, as security questions span every domain and most scenario-based questions involve choosing the correct role or access configuration.
| IAM Concept | Description |
|---|---|
| Members (Principals) | Google Account (user:email), Service Account (serviceAccount:email), Google Group (group:email), Google Workspace domain (domain:example.com), Cloud Identity domain, allUsers (anyone on the internet, including unauthenticated), allAuthenticatedUsers (any authenticated Google account) |
| Basic Roles (Primitive) | Owner (full control + IAM management + billing management), Editor (read/write all resources but no IAM or billing), Viewer (read-only all resources); extremely broad permissions; avoid in production; useful only for quick development and testing scenarios |
| Predefined Roles | Fine-grained, service-specific roles created and maintained by Google; examples: roles/compute.instanceAdmin.v1, roles/storage.objectViewer, roles/container.clusterAdmin, roles/cloudsql.admin, roles/pubsub.publisher; the recommended approach for production IAM management |
| Custom Roles | User-defined roles with a specific set of permissions you select; created at organization or project level; useful when predefined roles grant too many or too few permissions; must be maintained manually as new permissions are added to the platform; can include permissions from multiple services in a single role |
| IAM Conditions | Add conditional expressions to IAM bindings; grant access based on attributes like resource type, resource name, date/time, or IP address; example: grant compute.instanceAdmin only for instances with a specific label or only during business hours; uses Common Expression Language (CEL) |
| Policy Binding & Inheritance | An IAM policy is a collection of bindings that connect principals to roles at a specific resource; policies inherit from org to folder to project to resource; effective policy = union of all inherited policies; use gcloud projects get-iam-policy and gcloud projects add-iam-policy-binding to manage |
Exam Tip: Key gcloud IAM command: gcloud projects add-iam-policy-binding PROJECT_ID --member=user:EMAIL --role=roles/ROLE_NAME. Remember that IAM policies are additive and inherited. You cannot remove a permission at a child level that was granted at a parent level (except with deny policies). Always prefer predefined roles over basic roles in production.
Service Accounts
| Type | Description |
|---|---|
| Default Service Account | Created automatically when you enable certain APIs (e.g., Compute Engine default SA: [email protected]; App Engine default SA: [email protected]); has Editor basic role by default which is overly permissive; best practice: replace with a user-managed SA with minimal roles |
| User-Managed Service Account | Created by you for specific workloads; format: SA_NAME@PROJECT_ID.iam.gserviceaccount.com; assign only necessary predefined roles; up to 100 per project; attach to VMs, Cloud Run services, GKE pods, and Cloud Functions; best practice for all production workloads |
| Google-Managed Service Account | Created and managed by Google Cloud services internally (e.g., Cloud Build SA, Dataflow SA); format varies by service; used for service-to-service operations; you typically should not modify their roles unless specifically required |
| Service Account Keys | JSON key files for external authentication; downloaded once and stored securely; maximum 10 keys per service account; rotate regularly; create with gcloud iam service-accounts keys create; AVOID creating keys when possible due to security risks of key leakage and management burden |
| Impersonation | A user or service account can impersonate another SA using the iam.serviceAccountTokenCreator role; avoids downloading and distributing key files; full audit trail is maintained showing who impersonated whom; preferred over key distribution for cross-project or temporary elevated access scenarios |
| Workload Identity (GKE) | Maps Kubernetes service accounts to Google Cloud service accounts; pods authenticate to Google APIs without key files; enabled per cluster; annotation on the Kubernetes SA specifies the Google SA to impersonate; the most secure way for GKE workloads to access Google Cloud services |
| Workload Identity Federation | Allows external workloads (AWS, Azure, on-premises, GitHub Actions) to authenticate to Google Cloud without service account keys; uses identity pools and providers to map external identities to Google Cloud IAM; eliminates key management for CI/CD pipelines and multi-cloud scenarios |
Exam Tip: Always prefer attaching a service account to a resource (VM, Cloud Run, Cloud Function) over downloading and distributing service account keys. Use Workload Identity for GKE pods and Workload Identity Federation for external CI/CD systems. The exam frequently tests scenarios where you must choose the most secure authentication method.
Organization Policies and Constraints
Organization policies are centralized constraints set by organization administrators to enforce governance rules across all projects and folders. Unlike IAM (which controls who can do what), organization policies control what can be done regardless of who has permission. They are set using constraints and can be applied at the organization, folder, or project level with inheritance. Organization policies complement IAM by adding guardrails that even project owners cannot override.
| Constraint | Purpose |
|---|---|
| gcp.resourceLocations | Restrict which regions or zones resources can be created in; enforce data residency and sovereignty requirements; deny list or allow list of locations |
| compute.vmExternalIpAccess | Restrict which VMs can have external IP addresses; enforce private-only networking; allowlist specific projects or VM instances that are permitted to use external IPs |
| iam.disableServiceAccountKeyCreation | Prevent creation of service account keys in the organization; enforce use of attached service accounts, Workload Identity, and Workload Identity Federation instead |
| compute.restrictVpcPeering | Control which VPCs can be peered; prevent unauthorized network connections between projects or organizations |
| iam.allowedPolicyMemberDomains | Restrict which domains can be added to IAM policies; prevent sharing resources with external Gmail accounts or other organizations |
Encryption and Key Management
- Google-Managed Encryption (Default): All data is encrypted at rest with AES-256 and in transit with TLS 1.2+; no configuration required; Google manages the key hierarchy including Data Encryption Keys (DEKs) and Key Encryption Keys (KEKs); keys are rotated automatically; this is sufficient for most workloads
- Customer-Managed Encryption Keys (CMEK): You create and manage encryption keys in Cloud KMS; control key rotation schedules, access policies, and key versions; can revoke access to encrypted data by disabling or destroying the key; supported by most GCP services including Compute Engine, Cloud Storage, BigQuery, Cloud SQL, and GKE; provides audit logging of all key operations
- Customer-Supplied Encryption Keys (CSEK): You provide your own AES-256 encryption key with each API call; Google uses it to encrypt your data and does not store the key; only supported by Compute Engine disks and Cloud Storage; provides maximum control but imposes the highest operational burden; if you lose the key, the data is permanently inaccessible
- Cloud KMS: Centralized key management service; supports symmetric encryption, asymmetric encryption, and asymmetric signing; protection levels: SOFTWARE (default) or HSM (Cloud HSM, FIPS 140-2 Level 3); automatic and manual key rotation; key versions allow gradual migration; IAM controls who can use, manage, or destroy keys
- Secret Manager: Store and manage API keys, passwords, database credentials, TLS certificates, and other sensitive configuration data; automatic versioning of secrets; IAM-based access control (secretmanager.secretAccessor role); integrates natively with Cloud Run, Cloud Functions, and GKE; access secrets via API, gcloud, or client libraries; rotation notifications via Pub/Sub
Cloud Monitoring
Cloud Monitoring (part of Google Cloud's operations suite, formerly Stackdriver) collects metrics, events, and metadata from Google Cloud services, hosted uptime probes, application instrumentation, and even AWS resources via cross-cloud monitoring. You can build custom dashboards to visualize infrastructure health and application performance, configure alerting policies to notify your team when metrics exceed thresholds, and create uptime checks to verify service availability from global locations. For the ACE exam, you must understand how to create alerting policies with notification channels, configure uptime checks for HTTP endpoints, interpret monitoring dashboards, and use metrics to inform autoscaling decisions.
| Feature | Description |
|---|---|
| Metrics | Built-in metrics for all GCP services (CPU utilization, memory usage, disk I/O, network throughput, request count, latency); custom metrics via OpenTelemetry or the Monitoring API; metrics scoping allows a single Monitoring project to view metrics from multiple GCP projects |
| Alerting Policies | Define conditions based on metric thresholds, absence of data, or rate of change; set notification channels: email, SMS, Slack, PagerDuty, Pub/Sub, webhooks; add documentation for incident responders; supports multi-condition policies (all conditions must be met); snooze alerts during maintenance windows |
| Uptime Checks | HTTP(S), TCP, or custom protocol checks from global probe locations; configurable check interval (1-15 minutes); alerting on consecutive failures from multiple regions; monitors both public URLs and private endpoints (via private check configuration); verify response body content and status codes |
| Dashboards | Customizable visualizations with line charts, bar charts, heatmaps, gauges, scorecards, and log panels; share across teams; JSON-based dashboard definitions for version control; pre-built dashboards for GKE, Compute Engine, Cloud SQL, and other services |
| Monitoring Agent | Ops Agent (recommended) collects detailed system-level metrics (memory, disk, network per process) and application logs from VMs; replaces legacy Monitoring and Logging agents; installed on Compute Engine VMs for deeper visibility beyond default hypervisor-level metrics |
Cloud Logging
| Concept | Description |
|---|---|
| Audit Log Types | Admin Activity logs: always enabled, free, 400-day retention; records administrative actions (creating VMs, modifying IAM); Data Access logs: disabled by default (except BigQuery), must be explicitly enabled, 30-day default retention, can be expensive at scale; System Event logs: automatic, records GCP system events (live migration, maintenance); Policy Denied logs: records when access is denied by organization policy or VPC Service Controls |
| Log Router & Sinks | All logs flow through the Log Router, which evaluates sink rules to determine where logs are sent; create sinks to route logs to: Cloud Storage (long-term archival at lowest cost), BigQuery (SQL-based analysis and dashboards), Pub/Sub (real-time streaming to external systems), or a Log Analytics bucket; sinks can filter logs using query expressions to route only specific log entries |
| Log-Based Metrics | Create custom Cloud Monitoring metrics from log entries using filter expressions; counter metrics count matching log entries; distribution metrics extract numeric values from log fields; use log-based metrics in alerting policies (e.g., alert when error log rate exceeds threshold); system log-based metrics are pre-defined by Google |
| Exclusion Filters | Prevent specific logs from being ingested into Cloud Logging to reduce storage costs; configured in the Log Router; logs excluded from ingestion are still available to sinks configured before the exclusion point; use carefully as excluded logs cannot be searched in the Logs Explorer |
| Logs Explorer | Web-based interface for searching, filtering, and analyzing logs in real time; supports structured query syntax and free-text search; filter by resource type, severity, time range, and custom fields; pin and save frequent queries; stream logs in real time for live debugging |
Exam Tip: Admin Activity audit logs are always enabled, free of charge, and retained for 400 days. Data Access audit logs are disabled by default (except for BigQuery) and must be explicitly enabled; they incur storage charges and have a 30-day default retention. Exporting logs to BigQuery using a sink allows powerful SQL-based analysis and long-term retention beyond the default period.
Cloud Trace, Error Reporting, and Profiler
| Service | Purpose |
|---|---|
| Cloud Trace | Distributed tracing for latency analysis; tracks requests as they traverse microservices; automatic instrumentation for App Engine, Cloud Run, and Cloud Functions; manual instrumentation with OpenTelemetry for Compute Engine and GKE; identifies performance bottlenecks in multi-service architectures |
| Error Reporting | Aggregates, deduplicates, and displays application errors and exceptions; groups similar errors together with occurrence count and affected user count; real-time email and mobile notifications for new errors; links directly to relevant log entries; supports most popular languages and frameworks |
| Cloud Profiler | Continuous CPU and heap memory profiling of production applications; extremely low overhead (typically less than 0.5% CPU impact); flame graphs for identifying hot code paths and memory leaks; supports Java, Go, Python, Node.js; helps optimize application performance and reduce compute costs |
Pub/Sub Messaging Service
| Concept | Description |
|---|---|
| Topics | Named resources to which publishers send messages; messages are retained for up to 31 days (configurable); a topic can have multiple subscriptions; publishers are decoupled from subscribers; create with gcloud pubsub topics create TOPIC_NAME |
| Subscriptions | Pull subscriptions: subscriber explicitly requests messages; Push subscriptions: Pub/Sub delivers messages to an HTTPS endpoint (Cloud Run, Cloud Functions, App Engine); BigQuery subscriptions: write messages directly to a BigQuery table; each subscription receives a copy of every message published to the topic |
| Delivery Guarantees | At-least-once delivery by default; exactly-once delivery available for specific subscription types; messages must be acknowledged (acked) by the subscriber or they will be redelivered after the ack deadline; dead-letter topics capture messages that fail processing after a configurable number of delivery attempts |
| Use Cases | Decoupling microservices; event-driven architectures; streaming data pipelines (Pub/Sub to Dataflow to BigQuery); budget alert notifications; Cloud Storage event notifications; log export streaming; IoT device telemetry ingestion |
Infrastructure as Code and Deployment Tools
| Tool | Description |
|---|---|
| Deployment Manager | Google Cloud native IaC; YAML configuration files with optional Jinja2 or Python templates for reusable components; declarative: you define desired state and DM handles creation, updates, and deletion; preview changes before applying; GCP-only (no multi-cloud support); being superseded by Terraform in many organizations |
| Terraform | HashiCorp IaC tool with HCL configuration language; plan (preview), apply (execute), and destroy workflow; state file tracks managed resources; supports multi-cloud and hybrid deployments; Google is a major contributor to the Google Cloud Terraform provider; widely adopted in the industry |
| Cloud Build | Serverless CI/CD platform; build, test, and deploy containers and applications; YAML-based build configuration (cloudbuild.yaml) defines steps; integrates with Cloud Source Repositories, GitHub, and Bitbucket; triggers on push, pull request, or tag events; builds run in isolated containers; deploy to GKE, Cloud Run, App Engine, or Compute Engine |
| Artifact Registry | Universal package repository for container images (Docker), language packages (Maven, npm, Python, Go), and OS packages (APT, YUM); replaces Container Registry; vulnerability scanning for container images; IAM-based access control; regional and multi-regional repositories; integrates with Cloud Build for automated image publishing |
| Cloud Source Repositories | Fully managed private Git repositories hosted on Google Cloud; mirror from GitHub or Bitbucket; integrate with Cloud Build for CI/CD triggers; IAM-based access control; free for up to 5 users and 50 GB of storage |
Cost Optimization Quick Reference
- Sustained Use Discounts: Automatic discounts (up to 30%) for N1 and N2 VMs running more than 25% of the month; no commitment required; applied automatically on your bill; does NOT apply to E2, Tau, or Autopilot GKE pods
- Committed Use Discounts: 1 or 3-year commitments for predictable workloads; resource-based CUDs (commit to vCPU and memory amounts, up to 57% savings for 3-year) or spend-based CUDs (commit to minimum hourly spend); applies automatically to matching usage across the entire billing account
- Spot VMs: Up to 60-91% discount for fault-tolerant, interruptible workloads; may be preempted at any time with 30 seconds notice; ideal for batch processing, data analytics, CI/CD builds, and rendering; use in MIGs with mixed instance policies combining regular and Spot VMs
- Right-Sizing Recommendations: The Cloud Console provides machine type recommendations for underutilized VMs based on actual CPU and memory usage metrics over the past 8 days; review regularly and resize instances to avoid paying for unused capacity
- Cloud Storage Lifecycle Policies: Automatically transition objects to cheaper storage classes (Standard to Nearline to Coldline to Archive) or delete objects after a configured number of days; set per-bucket lifecycle rules to optimize storage costs without manual intervention
- Autoscaling: Configure MIG autoscalers and GKE cluster autoscalers to scale based on CPU utilization, HTTP load balancing capacity, Pub/Sub queue depth, or custom Cloud Monitoring metrics; scale down during low-traffic periods to avoid paying for idle resources; set minimum instances to zero where possible (Cloud Run, App Engine Standard, Cloud Functions)
- Labels for Cost Allocation: Apply consistent labels (env, team, cost-center, application) to all resources; filter billing reports and BigQuery billing exports by labels to attribute costs to specific teams, projects, or workloads; establish a labeling policy organization-wide