Google Cloud Associate Cloud Engineer: Cloud Planning

Topic snapshot

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Planning and Configuring a Cloud Solution

Your company is building an integration layer between an on-premises ERP system and Google Cloud. The ERP will publish order events to Pub/Sub and send occasional HTTPS callbacks. Each event can be processed in under 30 seconds, the logic is stateless, and the team wants to minimize infrastructure management while handling bursty traffic.

Which of the following design choices should you AVOID for this integration layer? (Select TWO.)

Options:

• A. Expose an HTTPS endpoint with Cloud Run to receive ERP callbacks, using a serverless VPC connector for private access to a Cloud SQL database.

• B. Build a Cloud Run service that maintains long-lived TCP sessions to the ERP system for several hours per request, storing all session state in memory on a single instance.

• C. Use GKE Autopilot to host multiple containerized microservices if the organization already standardizes on Kubernetes tooling and needs mesh-based connectivity with an existing Kubernetes environment.

• D. Provision a GKE Standard cluster with manually managed node pools solely to run a small set of Pub/Sub-driven integration workers, even though the team has little Kubernetes experience.

• E. Implement the Pub/Sub event processing using Cloud Run functions triggered directly by Pub/Sub, with stateless handlers that complete within 30 seconds.

Correct answers: B and D

Explanation: This scenario describes a classic event-driven, stateless integration between an on-premises system and Google Cloud, with short per-event processing times and bursty traffic. In such cases, serverless platforms like Cloud Run and Cloud Run functions are usually preferred because they scale automatically, charge per use, and minimize infrastructure management.

The options that should be avoided are those that either:

• Introduce unnecessary operational complexity for a simple, event-driven workload, or
• Misuse Cloud Run’s execution model, such as depending on long-lived sessions and in-memory state on a single instance.

By contrast, options that use Cloud Run or Cloud Run functions correctly (short-lived, stateless, HTTP/event-driven processing) or that use GKE Autopilot in an environment already standardized on Kubernetes are aligned with Google Cloud best practices for this type of integration.

Question 2

Topic: Planning and Configuring a Cloud Solution

You have a stateless HTTP API already packaged as a Docker container and stored in Artifact Registry. You want it to automatically scale up with traffic and scale down to zero when idle, without managing any VMs or Kubernetes clusters. Which Google Cloud compute option should you choose?

Options:

• A. Create a GKE Autopilot cluster and deploy the container with a Kubernetes Deployment and Service.

• B. Deploy the container image to a Cloud Run service.

• C. Create a managed instance group of Compute Engine VMs running the container via a startup script.

• D. Rewrite the API into separate functions and deploy them as Cloud Run functions.

Best answer: B

Explanation: The scenario focuses on a single discriminating factor: running an existing containerized HTTP workload in a fully managed, serverless way that scales to zero without managing VMs or Kubernetes clusters. On Google Cloud, Cloud Run (for containers) is designed exactly for this case.

With Cloud Run, you deploy a container image, and Google Cloud handles all infrastructure: provisioning, scaling based on request load, and scaling down to zero when there is no traffic. You do not manage servers, instance groups, or Kubernetes control planes.

Compute Engine and GKE both give more control over infrastructure but require you to manage at least some underlying resources. Cloud Run functions focus on individual functions and events and are not the best fit when you already have a full containerized web service ready to run.

Question 3

Topic: Planning and Configuring a Cloud Solution

Your security team requires a custom host-based security agent to run on every Kubernetes node with direct access to the node OS. You deployed your workloads to a new GKE Autopilot cluster. When you try to SSH to worker nodes to install the agent, there are no Compute Engine VM instances visible. What should you do to meet this requirement?

Options:

• A. Keep using the GKE Autopilot cluster and package the security agent as a sidecar container in each application Pod to simulate host-based protection.

• B. Create a new GKE Standard cluster and migrate the workloads, then deploy the security agent using node-level controls (for example, a DaemonSet or startup script).

• C. Enable OS Login on the existing GKE Autopilot cluster so you can SSH to the underlying worker nodes and install the agent manually.

• D. Change the existing GKE Autopilot cluster’s billing model from per-Pod to per-node so that the nodes become visible in Compute Engine for direct management.

Best answer: B

Explanation: GKE Autopilot is a fully managed mode where Google manages the nodes for you. You are billed per-Pod resource usage instead of per-node, and you do not manage or even directly see the underlying Compute Engine instances. This simplifies operations but also means you cannot SSH into nodes, change node images directly, or install arbitrary host-based agents that require OS-level access.

GKE Standard, on the other hand, gives you full control of the cluster’s nodes. Nodes are regular Compute Engine VM instances that you configure through node pools. You are billed for those VMs, and you can install custom host-level software, use DaemonSets with host access, adjust machine types, and control many more aspects of node behavior.

In this scenario, the security team requires a host-based agent on every node. That is a node-level requirement, which conflicts with the managed-node model of GKE Autopilot. To satisfy the requirement, you must use a cluster type that exposes nodes and supports node-level configuration. That means creating a GKE Standard cluster and migrating workloads to it, then deploying the agent using a DaemonSet or startup scripts.

This question highlights the trade-off between GKE Autopilot (fully managed, per-Pod billing, no node access) and GKE Standard (more operational responsibility, per-node billing, full node control) and tests your ability to choose the correct mode when node-level customization is needed.

Question 4

Topic: Planning and Configuring a Cloud Solution

Your company runs a web application on a GKE Autopilot cluster. A single deployment.yaml file is manually edited and applied with kubectl for dev, staging, and prod. You must reduce configuration drift, avoid copying manifests, and simplify per-environment tuning (for example, replica counts and resource limits). What should you do?

Options:

• A. Create a Helm chart for the application, move shared settings into templates, and use separate values-dev.yaml, values-staging.yaml, and values-prod.yaml files to override environment-specific parameters when deploying with helm upgrade --install.

• B. Use the same deployment.yaml file for all environments without changes, and rely on the cluster autoscaler in GKE Autopilot to handle different load patterns.

• C. Create three copies of deployment.yaml (dev, staging, prod) in a Git repository and have your CI pipeline run kubectl apply on each environment-specific file.

• D. Migrate the application from GKE to a single Cloud Run service and treat different Cloud Run revisions as separate environments.

Best answer: A

Explanation: The scenario describes a common anti-pattern: manually editing the same Kubernetes manifest file for each environment. This leads to configuration drift, copy-paste errors, and difficulty tuning settings such as replica counts and resource limits per environment.

Helm solves this by treating Kubernetes manifests as templates and separating configuration (values) from structure (templates). You define Deployments, Services, and other resources as parameterized templates, then provide different values.yaml files per environment to override parameters like image tags, replica counts, resource requests/limits, and hostnames.

Using helm upgrade --install with an environment-specific values file lets you reuse the same chart and safely apply per-environment differences without duplicating manifests. This is aligned with infrastructure as code best practices: DRY templates, centralized definitions, and small, clear configuration overlays for each environment.

Question 5

Topic: Planning and Configuring a Cloud Solution

Your company runs a public customer API with users in North America, Europe, and Asia behind a global external HTTP(S) load balancer. An internal reporting dashboard is accessed only by employees in a single region and must minimize networking costs. You are choosing Network Service Tiers for the external IPs. Which of the following configuration choices should you AVOID? (Select TWO.)

Options:

• A. Keep the customer API’s external IP address in Premium Tier so that traffic uses Google’s global backbone network.

• B. Assign a Standard Tier regional external IP address to the customer API’s global external HTTP(S) load balancer.

• C. Switch the reporting dashboard’s external IP address from Standard Tier to Premium Tier, even though your manager required minimizing networking costs for that tool.

• D. Use a Standard Tier external IP address for a regional TCP load balancer in front of the reporting dashboard, which is accessed only from the same region.

• E. Use Premium Tier for the customer API’s external IP and Standard Tier for the reporting dashboard’s external IP to match their different latency and cost requirements.

Correct answers: B and C

Explanation: Network Service Tiers let you choose between Premium Tier, which uses Google’s global backbone and Anycast IPs, and Standard Tier, which uses regional IPs and typically follows the public internet more, at lower cost.

For a globally used, latency-sensitive API behind a global external HTTP(S) load balancer, Premium Tier is the correct and required choice. Global external HTTP(S) load balancers only support Premium Tier anycast IPs. Attempting to use Standard Tier for that frontend would both fail technically and degrade the intended global routing model.

For an internal reporting dashboard that is accessed only from a single region and is explicitly cost-sensitive without strict latency requirements, Standard Tier is appropriate. It keeps networking costs lower while still providing sufficient performance for a regional workload.

The actions you should avoid are those that either misconfigure the global load balancer with an incompatible Standard Tier IP, or that ignore the clear requirement to minimize networking cost for the internal tool by unnecessarily upgrading it to Premium Tier.

Question 6

Topic: Planning and Configuring a Cloud Solution

Your company stores all HTTP access logs in a single Cloud Storage bucket using the Standard storage class. Compliance requires you to retain these logs for 7 years, but they are accessed only a few times per year for audits. Last month’s bill shows this bucket as one of the highest-cost items.

What is the most appropriate change to reduce storage cost while still meeting the retention requirement?

Options:

• A. Create a lifecycle rule that transitions all log objects to Coldline after 30 days and deletes them after 1 year.

• B. Keep using the Standard storage class and enable object versioning on the bucket for better compliance.

• C. Change the bucket’s default storage class to Nearline and leave existing objects in the Standard class.

• D. Create a lifecycle rule that immediately transitions all existing and new log objects to the Archive storage class.

Best answer: D

Explanation: This scenario is about troubleshooting unexpectedly high Cloud Storage cost for long-retained, rarely accessed logs. The logs must be stored for 7 years but are only accessed a few times per year, which is a textbook case for a very cold storage class.

In Google Cloud Storage, the colder classes (Nearline, Coldline, Archive) trade off higher retrieval and operation costs for much lower storage cost. For data with long retention and minimal access, the total cost is dominated by storage, so choosing the lowest-cost storage class that still supports the retention and access pattern is best.

Archive storage is specifically optimized for data kept for at least 365 days and accessed very infrequently. Since the logs are accessed only during occasional audits over 7 years, moving them to Archive significantly reduces ongoing storage cost while preserving the ability to retrieve them when needed for compliance.

By using a lifecycle rule that transitions all objects to Archive, you systematically apply this cost optimization without breaking the retention requirement.

Question 7

Topic: Planning and Configuring a Cloud Solution

Your company is migrating its data platform to Google Cloud. You have a large existing on-premises Apache Kafka ecosystem that must continue to work with minimal code changes, and new microservices running on Cloud Run that need a fully managed, auto-scaling messaging service with as little operational overhead as possible. Which of the following actions/solutions will meet these requirements? (Select TWO.)

Options:

• A. Use Cloud Storage buckets as the central event bus, having all producers write objects to a bucket and all consumers poll the bucket for new files.

• B. Use Pub/Sub for new Cloud Run-based microservices so they can publish and subscribe using a fully managed, auto-scaling messaging service without managing brokers or partitions.

• C. Replace the existing Kafka deployment by migrating all producers and consumers directly to Pub/Sub, rewriting them to use Pub/Sub client libraries so only a single messaging technology is used.

• D. Deploy a self-managed Kafka cluster on Compute Engine VMs and migrate all workloads to it, so that you maintain full control over Kafka configuration and upgrades.

• E. Use Google Cloud Managed Service for Apache Kafka to host a managed Kafka cluster and repoint existing Kafka producers and consumers to the new managed Kafka endpoints with minimal code changes.

Correct answers: B and E

Explanation: This scenario is about choosing between Pub/Sub and Google Cloud Managed Service for Apache Kafka based on two distinct needs: preserving a large existing Kafka ecosystem with minimal changes, and providing a low-operations messaging option for new Google Cloud-native services.

Google Cloud Managed Service for Apache Kafka is intended for organizations that already rely heavily on Kafka APIs, tooling, and semantics. It lets you move Kafka into a managed environment while keeping clients mostly unchanged. This fits the requirement to keep the existing Kafka workloads working with minimal code changes.

Pub/Sub is a fully managed, horizontally scalable messaging service native to Google Cloud. It removes the need to manage brokers, partitions, or Zookeeper-like components, and integrates directly with Cloud Run and other services. This makes it ideal for new microservices that prioritize low operational overhead over strict Kafka compatibility.

Together, using managed Kafka for legacy Kafka workloads and Pub/Sub for new Cloud Run-based workloads provides the right mix of compatibility and operational simplicity without forcing a full rewrite of existing systems.

Question 8

Topic: Planning and Configuring a Cloud Solution

Your company is migrating several VM-based microservices to use Cloud NGFW with identity-based rules. You want network policies to follow workloads as they scale and change IPs. Which configuration is NOT aligned with this goal?

Options:

• A. Create Cloud NGFW rules that allow or deny traffic based solely on the current VM subnet and instance IP ranges, without referencing any service accounts.

• B. Assign a distinct service account to each microservice and reference those service accounts as the targets in Cloud NGFW rules.

• C. Keep IP-based Cloud NGFW rules only for a few external partner ranges while moving internal workload-to-workload access controls to service-account-based rules.

• D. Refactor existing broad subnet-based rules by replacing them with Cloud NGFW rules that target specific service accounts running sensitive back-end services.

Best answer: A

Explanation: Cloud NGFW supports identity-based network controls by allowing you to target rules at service accounts rather than only at IP addresses or subnets. This lets policies follow workloads as they scale, move between subnets, or have their IPs reassigned. It also simplifies rule management and improves security by enforcing least privilege at the identity level.

A configuration that continues to rely solely on IP ranges for internal workloads ignores the main benefit of identity-based controls. While IP-based rules may still be appropriate at certain boundaries (for example, for specific partner IPs), using them as the primary mechanism for workload-to-workload access is an anti-pattern when identity-based targeting is available and desired.

Question 9

Topic: Planning and Configuring a Cloud Solution

You are designing Cloud NGFW policies for a production VPC that hosts a public web application behind an external HTTP(S) load balancer and several internal microservices. Security requires least privilege while still allowing the app to serve internet users and call external APIs. Which TWO Cloud NGFW configuration actions should you AVOID? (Select TWO.)

Options:

• A. Create a high‑priority ingress rule that allows TCP ports 80 and 443 from source 0.0.0.0/0 to the external HTTP(S) load balancer’s front-end IP as the only public entry point.

• B. Add a high‑priority egress rule that allows all protocols and all ports from the production subnet to destination 0.0.0.0/0 to simplify initial troubleshooting, leaving it in place for normal operations.

• C. Enable logging on Cloud NGFW rules that control production ingress and egress traffic, and export the logs to Cloud Logging for analysis and alerting.

• D. Create a high‑priority ingress rule that allows all TCP and UDP ports from source 0.0.0.0/0 to all VM instances in the production subnet so that no traffic is accidentally blocked.

• E. Create an egress rule from the application subnet that allows only TCP port 443 to 0.0.0.0/0 so the app can reach external APIs while blocking other outbound ports.

Correct answers: B and D

Explanation: Cloud NGFW policies should enforce least privilege for both ingress and egress while still allowing required application flows. Rules need to be as specific as possible in terms of source, destination, protocols, and ports, and permissive, wide‑open rules should be avoided—especially in production.

Allowing only HTTP/HTTPS traffic from the internet to a public load balancer is a standard pattern because the load balancer terminates user connections and then forwards traffic internally according to tighter rules. Similarly, outbound traffic from application subnets should be constrained to only the protocols and destinations that the application actually needs.

Overly broad any‑any rules (all protocols, all ports, any destination/source) defeat the purpose of Cloud NGFW by creating unnecessary attack surface and making it harder to enforce security policies or detect abuse. These are particularly risky when applied to entire production subnets with internet‑wide reachability.

Question 10

Topic: Planning and Configuring a Cloud Solution

Which TWO of the following statements about choosing between regional, dual-region, and multi-region Cloud Storage locations are INCORRECT? (Select TWO.)

Options:

• A. A multi-region Cloud Storage bucket is usually the best choice when all workloads run in a single region and you want the lowest cost and the lowest write latency.

• B. A regional Cloud Storage bucket stores data in a single region, which typically provides the lowest latency for applications running in that same region.

• C. A dual-region Cloud Storage bucket maintains copies of data in two distinct regions, improving disaster recovery compared to a single-region bucket.

• D. If an application must keep data within a specific country, choosing a multi-region location that spans multiple countries is appropriate because cross-border replication improves disaster recovery without affecting residency requirements.

• E. When most users are concentrated in two specific regions, a dual-region Cloud Storage bucket can balance low latency for both regions with higher availability than a single-region bucket.

Correct answers: A and D

Explanation: This question tests understanding of when to use regional, dual-region, and multi-region Cloud Storage locations to balance latency, cost, and disaster recovery, and to respect data residency requirements.

Regional buckets keep data in a single region and are typically best when your compute and users are primarily in that region, giving low latency and lower cost. Dual-region buckets replicate data between two specific regions, improving disaster recovery and often serving users or compute in those two regions with relatively low latency. Multi-region buckets spread data across multiple regions in a broader geographic area, which is useful for serving a widely distributed user base and for high availability, but they generally cost more and may not satisfy strict locality requirements.

The incorrect statements either misrepresent multi-region as the best/cheapest choice for single-region workloads or suggest that using a multi-region that spans multiple countries is compatible with strict country-level data residency, which it is not.

Continue with full practice

Use the Google Cloud Associate Cloud Engineer Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try Google Cloud Associate Cloud Engineer on Web View Google Cloud Associate Cloud Engineer Practice Test

Related focused pages

• Free Google Cloud Associate Cloud Engineer Full-Length Practice Exam
• Cloud Environment Setup
• Deploying Cloud Solutions
• Cloud Operations
• Configuring Access and Security

Free review resource

Read the Google Cloud Associate Cloud Engineer Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.