GCP ACE Planning and configuring a cloud solution: 108 practice questions
12 of the 108 Planning and configuring a cloud solution questions in the Certsqill GCP ACE bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.
Preparing for GCP ACE? Take the free 5-min readiness check →
1. Memory-optimized machine family: Which Compute Engine machine family is designed for this requirement?
- General-purpose machine family (N2 series)Incorrect. N2 general-purpose machines balance CPU and memory for a wide range of workloads but top out at far less than 12 TB RAM. They are not designed for extreme memory requirements.
- Memory-optimized machine family (M2 series) ✓Correct. The M2 memory-optimized machine family is designed specifically for memory-intensive workloads like in-memory databases and analytics. M2 instances offer up to 12 TB of RAM, making them the correct choice for this scenario.
- Accelerator-optimized machine family (A2 series)Incorrect. A2 accelerator-optimized instances are designed for GPU-intensive workloads like machine learning training and HPC. While they can have significant RAM, they are not the family optimized for multi-TB in-memory analytics without GPU requirements.
- Compute-optimized machine family (C2 series)Incorrect. C2 compute-optimized instances prioritize high per-core CPU performance (Intel Cascade Lake) for CPU-intensive tasks like scientific modeling. They are not designed for ultra-high memory configurations.
Memory-optimized M2 instances support up to 12 TB of RAM, making them ideal for extreme in-memory analytics workloads.
2. GKE Autopilot mode: Which GKE mode should they choose?
- GKE Regional ClusterIncorrect. A GKE Regional Cluster distributes the control plane and nodes across multiple zones for high availability. Like Private Cluster, it is a cluster topology configuration, not a management mode — it does not automate node lifecycle management.
- GKE Standard modeIncorrect. GKE Standard mode gives you full control over node configuration, node pool management, and cluster settings. While Google manages the control plane, you are responsible for managing, scaling, and patching the nodes.
- GKE Autopilot mode ✓Correct. GKE Autopilot is a fully managed mode where Google manages the entire cluster infrastructure — nodes, node pools, scaling, patching, and security hardening. You pay per Pod resource requests and only interact with the Kubernetes control plane to deploy workloads.
- GKE Private ClusterIncorrect. A GKE Private Cluster is a network configuration option (nodes have only private IP addresses) that applies to both Standard and Autopilot modes. It is not an operational mode that eliminates node management.
GKE Autopilot mode delegates all node management (provisioning, scaling, patching) to Google, letting teams focus purely on workload deployment.
3. App Engine Standard Environment: Which App Engine environment meets these requirements?
- App Engine Flexible EnvironmentIncorrect. App Engine Flexible Environment runs on Compute Engine VMs and does not scale to zero — it maintains a minimum of one running instance. Startup times are also slower (minutes) compared to Standard.
- Cloud RunIncorrect. While Cloud Run also supports scale-to-zero and handles traffic spikes rapidly, the question is specifically asking about an App Engine environment. Cloud Run is a separate managed service, not an App Engine environment.
- App Engine Standard Environment with manual scalingIncorrect. Manual scaling in App Engine Standard requires a minimum of one running instance at all times, which prevents true scale-to-zero behavior. Automatic scaling is required for scale-to-zero.
- App Engine Standard Environment ✓Correct. App Engine Standard Environment supports scale-to-zero (instances can be scaled down to 0 when idle) and provides very fast cold-start scaling (within seconds). It runs in a sandbox and supports Python, Java, Node.js, Go, Ruby, and PHP.
App Engine Standard Environment supports scale-to-zero and near-instant scaling, making it ideal for variable traffic with cost optimization.
4. Cloud Run: Which compute service is the best fit?
- Cloud Run ✓Correct. Cloud Run is designed for deploying stateless containerized applications. It scales to zero when idle, scales up rapidly based on traffic, and supports configuring up to 1000 concurrent requests per container instance (max concurrency setting).
- Compute Engine with a managed instance groupIncorrect. While a managed instance group can autoscale, it does not scale to zero and requires managing VMs, OS patches, and instance templates. This is far more operational overhead than Cloud Run for a stateless containerized HTTP service.
- App Engine Flexible EnvironmentIncorrect. App Engine Flexible can run containers but it does not scale to zero (minimum 1 instance always running) and is heavier-weight for this use case. Cloud Run is more appropriate for containerized microservices with scale-to-zero requirements.
- Cloud Functions (1st gen)Incorrect. Cloud Functions 1st gen is designed for single-function event-driven code snippets, not full containerized applications. It handles only 1 concurrent request per instance and does not accept arbitrary Docker containers.
Cloud Run is the purpose-built service for stateless containerized HTTP workloads with scale-to-zero and configurable per-instance concurrency.
5. Archive storage class: Which Cloud Storage class is most appropriate?
- Nearline storage classIncorrect. Nearline is designed for data accessed about once per month (30-day minimum storage duration). It is more expensive per GB than Coldline or Archive and is not cost-optimal for data accessed once or twice per year.
- Archive storage class ✓Correct. The Archive storage class has the lowest storage cost and is designed for data accessed less than once a year. With a 365-day minimum storage duration and higher retrieval costs, it is ideal for compliance logs that are rarely accessed but must be retained long-term.
- Coldline storage classIncorrect. Coldline is designed for data accessed about once per quarter (90-day minimum storage duration). While cheaper than Nearline and Standard, it still costs more per GB/month than Archive. For data accessed only once or twice a year, Archive is more cost-effective.
- Standard storage classIncorrect. Standard storage has no minimum storage duration and the highest per-GB storage cost, making it appropriate for frequently accessed (hot) data. Using Standard for rarely accessed compliance logs would be significantly more expensive.
Archive storage class has the lowest storage cost and is purpose-built for data accessed fewer than once per year, ideal for long-term compliance retention.
6. Cloud SQL: Which GCP database service is the best fit?
- BigQueryIncorrect. BigQuery is a fully managed data warehouse optimized for analytical (OLAP) workloads with large-scale SQL queries over billions of rows. It is not designed for OLTP (transactional) workloads with 10,000 queries per second and low latency requirements.
- BigtableIncorrect. Cloud Bigtable is a NoSQL wide-column store designed for time-series data and analytics workloads at petabyte scale. It does not support SQL, JOINs, or ACID transactions in the traditional relational sense.
- Cloud SQL ✓Correct. Cloud SQL is Google's managed relational database service supporting MySQL, PostgreSQL, and SQL Server. It supports ACID transactions, complex SQL queries with JOINs, and scales to handle the described workload. It is the appropriate choice for relational data with complex queries.
- FirestoreIncorrect. Firestore is a NoSQL document database. While it supports ACID transactions at the document level, it does not support SQL JOINs or relational queries across collections. It is not designed for relational data models.
Cloud SQL is GCP's managed RDBMS supporting complex SQL JOINs and ACID transactions, appropriate for relational OLTP workloads.
7. Custom mode VPC with manually defined subnets and IP: Which VPC network configuration should they use?
- Default VPC network with automatic subnets per regionIncorrect. The Default VPC is an auto mode network with subnets pre-created in every region from fixed 10.128.0.0/9 ranges, so it cannot avoid overlap with the on-premises 10.0.0.0/8 space.
- Auto mode VPC using Google's predefined 10.128.0.0/9 IP rangesIncorrect. Auto mode creates one subnet per region from the fixed 10.128.0.0/9 block; those ranges can collide with on-premises 10.x addresses and can't be customized without converting to custom mode.
- Shared VPC with a host project sharing subnets to service projectsIncorrect. Shared VPC governs cross-project subnet sharing, not the network mode; the host VPC is still either auto or custom mode, so custom mode is what actually gives the required IP control.
- Custom mode VPC with manually defined subnets and IP ranges ✓Correct. Custom mode VPC allows you to define exactly which subnets exist, in which regions, and with which CIDR ranges. This prevents IP range conflicts with on-premises networks and gives full control over network topology for production environments.
Custom mode VPC provides full control over subnet creation and IP ranges, preventing conflicts with existing on-premises IP address spaces.
8. Global External Application Load Balancer Load Balancer): Which load balancer should they use?
- Global External Application Load Balancer (formerly HTTP(S) Load Balancer) ✓Correct. The Global External Application Load Balancer is a Layer 7 load balancer that supports: global anycast IP (single IP served from Google's edge PoPs), SSL termination, URL-map-based content routing, and backends across multiple regions. This matches all stated requirements.
- Regional Internal Application Load Balancer serving only private VPC trafficIncorrect. A Regional Internal Application Load Balancer handles private traffic inside one VPC region and offers no external anycast IP, so it cannot serve global internet users.
- Global External Proxy Network Load Balancer operating as a TCP ProxyIncorrect. The Global External Proxy Network Load Balancer works at Layer 4 (TCP); although it uses a global anycast IP, it cannot route on URL paths as required.
- Network Load Balancer providing regional pass-through Layer 4 routingIncorrect. The pass-through Network Load Balancer is regional and Layer 4, does not terminate SSL, and offers no URL path routing, so it fails the global HTTP requirements.
The Global External Application Load Balancer provides global anycast IP, SSL termination, and Layer 7 URL-path-based content routing for HTTPS applications.
9. A Managed Instance Group with autoscaling based: Which configuration achieves this?
- A Managed Instance Group behind an external load balancer, autoscaling on HTTP load balancing serving capacity together with CPU utilization targetsIncorrect. HTTP load balancing autoscaling scales on request rate or utilization, not on measured response latency; hitting specific latency thresholds needs a custom Cloud Monitoring metric.
- A Managed Instance Group autoscaling solely on average CPU utilization across instances, plus autohealing health checks for recoveryIncorrect. CPU-based autoscaling ignores the required HTTP latency thresholds; a custom latency metric is needed to scale on the 200ms/150ms triggers described.
- An Unmanaged Instance Group relying on manually written scaling scripts and custom external health monitoring for instance recoveryIncorrect. Unmanaged Instance Groups support neither autoscaling nor autohealing; they are heterogeneous VM collections, and manual scripts are brittle and not recommended.
- A Managed Instance Group (MIG) with autoscaling based on a custom Cloud Monitoring metric for HTTP latency and a health check for autohealing ✓Correct. MIGs support autoscaling based on custom Cloud Monitoring metrics (including application-level metrics like latency), in addition to CPU and HTTP load balancing serving capacity. Autohealing with a health check automatically recreates instances that fail health checks.
MIGs support custom Cloud Monitoring metric-based autoscaling for application-level metrics like latency, plus autohealing via health checks.
10. Cloud Functions 2nd generation: Which Cloud Functions generation should they use?
- Cloud Functions 2nd generation ✓Correct. Cloud Functions 2nd gen (built on Cloud Run) supports up to 60 minutes for HTTP functions, up to 1000 concurrent requests per instance, and HTTP triggers. It removes many limitations of 1st gen, including the 9-minute timeout and single-concurrency constraint.
- Cloud Functions 1st generationIncorrect. Cloud Functions 1st gen has a maximum timeout of 9 minutes for HTTP functions (60 minutes for background/event-driven) and handles only 1 concurrent request per instance. It does not meet the stated requirements.
- App Engine Standard EnvironmentIncorrect. App Engine Standard supports long-running requests but is designed for full web applications, not individual event-driven functions. It has different deployment and operational characteristics than Cloud Functions.
- Cloud RunIncorrect. While Cloud Run does meet these requirements and Cloud Functions 2nd gen is built on Cloud Run, the question asks specifically about Cloud Functions. Cloud Run is a separate service requiring a Docker container rather than function-level code.
Cloud Functions 2nd gen supports 60-minute timeouts, 1000 concurrent requests per instance, and is built on Cloud Run infrastructure.
11. Object Lifecycle Management rules configured on the bucket: Which feature should they configure?
- Cloud Storage Notifications invoking a Cloud Function per eventIncorrect. Wiring Notifications to a Cloud Function to change classes adds needless custom code and API calls when Object Lifecycle Management performs these transitions natively.
- Object Lifecycle Management rules configured on the bucket ✓Correct. Cloud Storage Object Lifecycle Management allows you to define rules with conditions (age, created before, number of versions, etc.) and actions (SetStorageClass to transition classes, Delete). Age-based rules automatically apply these transitions to all matching objects.
- Bucket Retention Policies applied to govern minimum file ageIncorrect. Retention Policies block deletion or changes before a minimum period for compliance; they do not transition storage classes or auto-delete by age as required.
- A Cloud Scheduler job running gsutil to transition filesIncorrect. A scheduled gsutil job is operationally complex and error-prone; Object Lifecycle Management is the purpose-built, fully managed feature for these transitions and deletions.
Object Lifecycle Management automates storage class transitions and deletions based on object age or other conditions without manual intervention.
12. Enable High Availability configuration with a standby: Which configuration provides this?
- Enable automated daily backups combined with point-in-time recovery for the instanceIncorrect. Backups with PITR guard against corruption or accidental deletion but are not an HA mechanism; restoring is manual and slow, failing the automatic-failover requirement.
- Deploy the Cloud SQL instance across a multi-region primary and replica configurationIncorrect. Cloud SQL has no native multi-region primary; HA is intra-region across zones, so a multi-region primary configuration does not exist for this failover need.
- Enable High Availability (HA) configuration with a standby instance in a different zone ✓Correct. Cloud SQL HA uses synchronous replication to a standby instance in a different zone within the same region. If the primary zone fails, Cloud SQL automatically fails over to the standby within 60 seconds with no data loss (synchronous replication guarantees this).
- Create an asynchronous read replica hosted in a separate zone and manually promote it on failureIncorrect. Read replicas use asynchronous replication and require manual promotion, so they neither guarantee zero data loss nor meet the no-manual-intervention requirement.
Cloud SQL HA uses synchronous cross-zone replication with automatic failover, ensuring zero data loss and no manual intervention on zone failure.
96 more Planning and configuring a cloud solution questions
The remaining 96 questions in this domain are part of the full GCP ACE bank — 500 questions, every option explained. Start with the free five-minute check and see your score per domain.
Test your GCP ACE readiness — freeOther GCP ACE domains
- Deploying and implementing a cloud solution — 158 questions →
- Ensuring successful operation of a cloud solution — 96 questions →
- Configuring access and security — 77 questions →
- Setting up a cloud solution environment — 61 questions →
- All 500 GCP ACE questions →