Google ACE: Containers, App Hosting and Serverless Platforms — 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

Google Cloud offers a continuum of platforms for running containers and applications, from fully managed serverless to configurable Kubernetes clusters. Selecting and operating the right platform requires understanding control planes, scaling models, release mechanisms, networking, and security. This section consolidates operational guidance for Google Kubernetes Engine (GKE), Artifact Registry, Cloud Run, App Engine, and Cloud Functions, alongside patterns for secrets, safe rollouts, and diagnostics.

Kubernetes Engine: Clusters, Workloads, and Networking

GKE clusters provide a managed Kubernetes control plane with node pools that you size and secure. Choose Autopilot for minimal operational overhead and opinionated defaults, or Standard for granular control of nodes, networking, and add-ons. Use release channels and node auto-upgrade for predictable, safe upgrades; enable node auto-repair. Prefer Container-Optimized OS for hardened nodes unless specific packages require Ubuntu.

• Node pools and scheduling

  • Separate node pools by workload class (e.g., general, GPU, spot) and use taints/tolerations to steer Pods.
  • Enable cluster autoscaler and configure per-pool min/max. Be aware PodDisruptionBudgets and resource requests may block scale-in or leave Pods pending if requests exceed available node shapes.
  • Spot/preemptible nodes reduce cost but introduce eviction risk; combine with Deployment surge budgets and Pod topology constraints for resilience.

• Namespaces and multi-tenancy

  • Use namespaces to partition quotas, policies, and RBAC. Apply NetworkPolicies to restrict east-west traffic. Enforce Pod Security standards at namespace scope to avoid privileged workloads.

• Workloads

  • Deployments manage stateless Pods with rolling updates, surge/unavailable budgets, and quick rollbacks. Use readiness probes to gate traffic and liveness/startup probes for autohealing. Misconfigured readiness probes can blackhole traffic; test before production.
  • StatefulSets provide stable identities and ordered scaling for databases and quorum-based systems. Use a headless Service and a StorageClass that supports dynamic provisioning; plan for zonal PV locality.
  • DaemonSets schedule one Pod per node (e.g., logging/monitoring agents). They respect autoscaling and drain events and are ideal for node-wide telemetry.

• Services and Ingress

  • ClusterIP exposes in-cluster DNS and load-balancing. NodePort is primarily for troubleshooting. LoadBalancer provisions a Google Cloud external or internal TCP/UDP load balancer; use internal for private services.
  • GKE Ingress configures global HTTP(S) load balancing with managed certificates, URL maps, and Cloud Armor. For modern traffic management, prefer container-native load balancing (NEG) for per-Pod health checks and faster convergence. Ensure readiness endpoints reflect real app health; otherwise backend becomes unhealthy, causing 502s.

• Autoscaling

  • Horizontal Pod Autoscaler scales replicas by metrics like CPU or custom metrics via Cloud Monitoring; ensure Metrics Server is healthy. Vertical Pod Autoscaler can right-size requests; avoid conflicts with HPA by using VPA in “recommendation” mode for HPA-managed workloads or use the HPA+VPA compatible mode carefully.
  • Cluster autoscaler adds/removes nodes to fit Pods. If Pods request more resources than any node shape offers, they will never schedule; align requests/limits with node pool shapes.

Short examples:

• Roll back a broken release:
  • kubectl rollout undo deployment/web
• Inspect another context quickly:
  • kubectl config use-context CONTEXT && kubectl config view

Artifact Management, Supply Chain Security, and Safe Releases

Artifact Registry hosts container images per region with VPC Service Controls support. Adopt separate repos (or prefixes) for environments and enforce immutable tags; deploy by digest to remove ambiguity. Integrate Cloud Build or your CI to build and push with provenance metadata.

• Vulnerability management

  • Enable Artifact Analysis to scan images for OS and language CVEs. Break builds or blocks promotion on high-severity findings. Combine with Binary Authorization to require signatures/attestations (e.g., vulnerability policy pass, SLSA provenance) before admission to GKE.

• Image promotion

  • Promote by copying an image digest from dev to staging/prod repos or by retagging in a promotion repo; avoid mutable “latest.” Automate with Cloud Build triggers conditioned on tests and scan results.

• Secrets and configuration

  • Prefer Secret Manager with least-privileged access. On GKE, use the Secret Manager CSI driver with Workload Identity so nodes never see long-lived secrets. For KRM configs, separate ConfigMap (non-secret) from Secret (sensitive) and mount read-only.
  • For serverless, mount secrets via direct Secret Manager bindings; avoid embedding secrets in environment variables unless strictly necessary.

• Rollback and release patterns

  • Kubernetes: use rolling updates with maxUnavailable=0 for no-downtime and maxSurge tuned to capacity; canary with two Deployments behind one Service or use Service mesh for gradual percentages. Protect critical workloads with PodDisruptionBudgets and minReadySeconds.
  • Cloud Run and App Engine: use revisions/versions and traffic splitting for canaries and blue/green. Keep previous revisions warm to reduce rollback latency.
  • Failure modes: mutable tag drift, scan time gaps, and mis-specified readiness probes are common causes of outages. Use image digests, pre-deploy checks, and synthetic health probes.

Serverless Application Platforms

Cloud Run provides container-native, request-driven compute with automatic scale-to-zero and per-request identity enforcement.

• Cloud Run services and jobs

  • Services handle HTTP; concurrency controls the number of simultaneous requests per instance (tune for latency vs efficiency). Jobs handle non-HTTP batch/cron and can be parallelized.
  • Revisions are immutable snapshots. Traffic splitting enables canary by percentage. Set min instances to reduce cold starts; use CPU allocation during idle if background work is required.
  • Identity: assign a dedicated service account per service/revision with least privilege. Restrict invocation via IAM (Cloud Run Invoker) or make public if necessary. For end-user auth, use signed IAP tokens or Cloud Run’s built-in authentication with Identity Platform.

• Networking

  • Use Serverless VPC connectors to reach private VPC resources. Choose egress: all traffic through connector, or only private RFC1918 ranges. Be aware of connector’s throughput quotas; scale connector size and region-align it with the service. For outbound internet with private IP-only resources, combine with Cloud NAT.
  • Private Service Connect can privately consume producer services or expose internal endpoints. For ingest via external HTTP(S), use Cloud Load Balancing with serverless NEGs.

App Engine offers two environments:

• Standard
  • Sandboxed, scales rapidly, supports automatic, basic, or manual scaling. Automatic scaling with min_idle_instances provides pre-warmed capacity. Fast cold start and simple deployment model; limited OS-level customizations and a fixed runtime set.
• Flexible
  • Runs Docker on Compute Engine VMs with more control over system libraries and networking. Slower instance lifecycle and higher baseline cost; suitable when custom runtimes or native libraries are needed.
• Services and versions
  • Split traffic by version (random, cookie, or IP). Each service can scale independently. Use gradual rollouts and maintain a previous version for instant rollback.

Cloud Functions provides event-driven single-purpose functions.

• Triggers: Pub/Sub, Cloud Storage, HTTP, Eventarc for many sources. Make handlers idempotent; some triggers retry on failure leading to duplicate processing.
• Runtime configuration: environment variables, Secret Manager bindings, max instances, memory/CPU. Control concurrency for HTTP functions to balance latency and cost.
• Common pitfalls: unbounded concurrency or non-idempotent side effects cause data duplication; ensure DLQs for Pub/Sub; set appropriate timeouts.

Platform Selection, Networking, and Operational Ownership

Select a platform based on required control, scaling characteristics, portability needs, and operations budget.

• Control vs overhead

  • Highest control: GKE Standard (node OS, networking, security add-ons) with corresponding ops overhead.
  • Balanced: GKE Autopilot (no node management, opinionated security).
  • Lowest overhead: Cloud Run, App Engine, Cloud Functions (no nodes, managed scaling), but constrained by runtime and request models.

• Scaling and workload fit

  • Spiky request workloads: Cloud Run/App Engine Standard excel; Functions for event-driven handlers.
  • Stateful or custom networking: GKE with StatefulSets and CNI features.
  • Portability: containers on GKE/Cloud Run; Functions are less portable due to FaaS model.

• Serverless networking, egress, and private services

  • Use VPC connectors for private access; monitor connector utilization to avoid throttling. Set egress to “all” only when necessary; otherwise limit to private ranges to reduce cost and risk.
  • For private ingress, consider internal HTTP(S) load balancing with serverless NEGs or Private Service Connect.
  • For data exfiltration control, pair with VPC Service Controls where supported and restrict egress routes via firewall and Cloud NAT.

• Diagnostics and operational ownership

  • Standardize on Cloud Logging with structured logs (JSON) and trace/span IDs across services for correlation. Use Cloud Monitoring dashboards, uptime checks, SLOs, and alerting policies.
  • For GKE: enable Cloud Ops for GKE, scrape app metrics via Prometheus or Cloud Monitoring, and use DaemonSets for node-level telemetry.
  • For serverless: leverage built-in request logs, Error Reporting, Trace, and Profiler. Set per-service SLOs and alerts on latency, error rate, and saturation (concurrency, instance CPU).
  • Ownership model: define who owns runtime parameters (scaling, concurrency), IAM, and release pipelines. Regularly test rollbacks and disaster scenarios.

Practical Problem Scenario

Acme Retail plans to expose a new checkout API while modernizing internal services. Requirements: public low-latency API with canary rollouts, private access to an internal inventory database in a VPC, supply chain enforcement, and clear rollback with minimal ops overhead.

1. Choose Cloud Run for the public API and GKE Autopilot for the internal inventory service.

• Rationale: Cloud Run minimizes ops overhead for stateless HTTP, supports revisions and traffic splitting; GKE Autopilot provides Kubernetes features for stateful/internal services without node management.

2. Build, scan, and store images in Artifact Registry with provenance.

• Rationale: Cloud Build produces container images; Artifact Analysis scans for CVEs. Storing digests and provenance enables Binary Authorization to enforce that only scanned, signed images run.

3. Enforce admission policies.

• Rationale: Enable Binary Authorization on the GKE cluster to require signatures and policy attestations. For Cloud Run, configure deploy automation to gate promotion on vulnerability policy pass.

4. Configure networking with a Serverless VPC connector and Cloud NAT.

• Rationale: The Cloud Run API must reach the inventory service and Cloud SQL privately. A VPC connector allows private RFC1918 egress; Cloud NAT provides outbound internet for dependency downloads without external IPs on private resources. Keep connector and services in the same region and right-size its throughput.

5. Secure identities and permissions.

• Rationale: Assign a dedicated service account to the Cloud Run service with least privilege (e.g., Cloud SQL Client, invoke permissions to internal endpoints if needed). For GKE, use Workload Identity so Pods assume service accounts without node-level credentials.

6. Implement safe release and rollback.

• Rationale: Deploy the API to a new Cloud Run revision and split 5% traffic for canary. Monitor latency, error rate, and saturation; then ramp to 100% or rollback instantly by reverting traffic to the prior revision. In GKE, use Deployment rolling updates with readiness probes and a small canary Deployment behind the same Service to validate before full rollout.

7. Configure observability and SLOs.

• Rationale: Emit structured JSON logs with trace IDs from both platforms to Cloud Logging. Create SLOs on p95 latency and 5xx rate; attach alerting policies. Use Error Reporting and Trace for root cause analysis. For GKE, deploy a DaemonSet for node metrics and enable Cloud Ops for GKE.

8. Validate failure modes and capacity.

• Rationale: Load test to verify VPC connector throughput, Cloud Run concurrency, and GKE HPA behavior. Confirm readiness probe accuracy to prevent blackholing. Test binary authorization deny paths and image rollback by digest to ensure recoverability under supply chain enforcement.

This approach delivers a low-ops, secure public API, controlled internal services, private networking, enforceable supply chain security, and rapid rollback, aligned with Google Cloud operational best practices.

← Compute Engine and Virtual Machine Operations · All domains · VPC Networking →

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

Browse Google →