CCNA Planning and Configuring a Cloud Solution Questions

Setting min-instances to 1 keeps one container instance always warm, eliminating the cold start for the first request after idle periods. A max-instances value calibrated to peak traffic caps both concurrent capacity and monthly cost, preventing unbounded scaling. CPU throttled (the default) charges only for CPU time used while processing requests, so the idle warm instance costs nothing for CPU, making this configuration both cost-effective and responsive to unpredictable traffic spikes.

HA VPN uses two external IP addresses and two tunnels to the same on-premises peer, and when paired with two on-premises VPN gateways, it achieves a 99.99% SLA. It relies on BGP to automatically fail over if one tunnel or gateway becomes unavailable, providing true high availability and making it the correct choice here.

Cloud Run is correct because it runs stateless container images on a fully managed, serverless platform that scales automatically from zero to thousands of instances based on HTTP traffic. You only pay for requests while the container is processing, and you don't manage servers or clusters, so a stateless containerized web application can be deployed with a single command.

Cloud Run runs stateless containers in a fully managed environment that scales from zero to the number of concurrent requests and bills only for the CPU, memory, and requests consumed during a request. There is no infrastructure to provision, no idle capacity to pay for, and the platform enforces a request deadline, making it ideal for an HTTP-driven legacy application with unpredictable traffic. Its per-request billing and automatic scaling mean you pay nothing when the service is not being called.

Firestore is a fully managed NoSQL document database that stores data in documents organized into collections. It provides built-in real-time synchronization through client-side listeners, automatically pushing updates to subscribed apps whenever data changes, making it ideal for live, collaborative applications. It also includes offline support and strong consistency, which are key differentiators for real-time use cases.

The Google Cloud Pricing Calculator is the correct tool for estimating monthly costs before deployment. You can select specific Google Cloud products and configure parameters such as region, VM machine type, RAM, storage class, and committed usage discounts to generate a projected total. It accepts hypothetical inputs and even provides a machine configurator for GKE and Compute Engine, producing a line-itemized estimate suitable for budgeting and capacity planning.

Persistent Disk provides durable, block-level storage that behaves like a physical disk attached to your VM. It survives VM stops and deletions, supports snapshots, and offers zonal or regional redundancy for high availability. With performance tiers like pd-standard, pd-balanced, and pd-ssd, Persistent Disk directly meets the persistence and I/O requirements of a stateful application.

When you configure Compute Engine resources in the Google Cloud Pricing Calculator, the tool estimates the monthly run time for each VM and automatically applies the applicable sustained use discount. SUD tiers are calculated without any user action: resources running more than 25% of the month receive a discount that increases incrementally until reaching a maximum of 20% off for the portion of the month after a full month of usage. This auto-application makes the estimate reflect actual billing.

Archive is correct because it is the only Google Cloud storage class specifically designed for data accessed less than once a year, offering the lowest storage cost. It is ideal for long-term retention, regulatory archives, or disaster recovery backups, with the trade-off of higher retrieval fees and a 365-day minimum storage duration before deletion or class change.

Cloud NAT is a managed source network address translation service that enables instances without external IP addresses to make outbound connections to the internet while allowing only corresponding return traffic. It works with Cloud Router to automatically configure NAT for a VPC network and supports mapping of private IPs to a set of external IP addresses, making it the correct solution for this requirement.

CMEK lets you create and manage encryption keys in Cloud KMS, and Cloud Storage uses them to encrypt your objects server-side. You control the key lifecycle, including automatic rotation periods, and can grant or revoke access through IAM identities and conditions. This provides a central audit trail and the ability to disable or destroy keys instantly, which is exactly what the organization needs for sensitive data.

BigQuery external tables query Parquet data directly in Cloud Storage without loading or provisioning servers, so you pay only for the query bytes processed. This satisfies the one-time, ad-hoc, serverless and cost-minimising constraints, unlike loading into native tables or running Dataproc clusters.

Cloud NAT provides outbound internet connectivity for private instances lacking external IP addresses, translating their internal addresses to a shared external one. It satisfies the stem's constraint of no external IPs while enabling software update downloads without inbound exposure.

A firewall rule that allows egress traffic to the internet is mandatory for any outbound connectivity, even when Cloud NAT is used. Cloud NAT only translates the source IP, but the VPC firewall still evaluates all traffic and drops it unless a rule permits traffic to destination 0.0.0.0/0 with a source tag or service account you apply to the instance. Without an egress allow rule, the NAT translation never gets the chance to send packets, because the firewall is applied before the packet leaves the instance's VPC network.

Compute Engine is the correct choice because it provides unmodified, full control over the virtual machine, including the guest OS kernel. You can install custom kernel modules, load them via modprobe, and configure kernel parameters exactly as required by the legacy monolithic application. This is essential for a lift-and-shift migration where the application depends on specific low-level OS features or hardware drivers that cannot be abstracted away by a managed platform.

A Cloud VPN tunnel is a prerequisite, not an alternative to DMS: Database Migration Service connects to your on-premises MySQL over a private IP address, and the VPN provides the secure, encrypted network path across the public internet. Without this connectivity, DMS cannot establish the replication channel needed for continuous sync. High-bandwidth, low-latency Interconnect is the alternative when VPN bandwidth is insufficient.

Cloud Storage Object Lifecycle Management lets you define age-based rules that automatically transition objects from Standard to Nearline after 30 days, to Coldline after 90 days, and to Archive after 365 days. This reduces storage costs progressively while still making the logs retrievable for the required 7-year compliance window. Because objects remain in the bucket throughout, no data is deleted, and Archive class is specifically designed for long-term retention with the lowest per-GB cost.

Cloud NAT uses a Cloud Router to provide a managed Network Address Translation service that gives private instances (those with internal IPs only) a secure path to the internet for outbound connections. It maintains stateful sessions so return traffic is allowed, but unsolicited inbound connections are blocked, preserving the private nature of the network.

Take a snapshot of the disk while the VM is running to obtain a crash-consistent image of the filesystem; persistent disk snapshots are computed online and do not require stopping the instance. From that snapshot, create a new persistent disk with the desired storage class (for example, pd-balanced or pd-ssd). Then unmount the old disk, detach it from the VM, attach the newly created disk, and remount it at the same mount point; this limits downtime to the brief unmount/detach/attach/remount window rather than the entire snapshot and disk creation time.

This is the recommended design because web servers get public IPs (or are behind an external load balancer) to accept inbound user connections, while database servers remain in a separate private subnet with no public IP, preventing direct internet access. Cloud NAT on the database subnet allows outbound internet requests for updates or external APIs without exposing the database to inbound traffic. Separate subnets also enable granular VPC firewall rules and routing policies between tiers, reducing the blast radius if the web tier is compromised.

Cloud SQL for MySQL is a fully managed relational database service that provides automated backups, patching, replication, and high availability without requiring you to run MySQL yourself. It is a direct drop-in replacement for an existing MySQL database, preserving compatibility while eliminating the administrative burden of managing database infrastructure. This aligns with the migration goal of reducing operational overhead.

Cloud Run jobs directly execute a containerized batch process to completion, scaling to zero immediately after the job finishes, so you pay only for the duration of execution (per-second billing). It supports long-running jobs (up to 24 hours), can be scheduled via Cloud Scheduler, and provides automatic retries, environment configuration, and VPC connectivity without managing servers or clusters. This makes it the most operationally simple and cost-effective option for a daily 30-minute file processing job.

google.cloud.storage.object.v1.finalized is the correct Eventarc event type for Cloud Functions (2nd gen) that corresponds to a new object being uploaded or an existing object being overwritten in Cloud Storage. It is the standard event for processing a newly created object, matching the legacy 'object finalized' event but now delivered through Eventarc for 2nd gen functions.

Cloud Bigtable is a sparse, wide-column NoSQL store engineered for petabyte-scale time-series workloads, delivering consistent single-digit millisecond latency and linear horizontal scaling to millions of reads per second. Its row-key design suits the simple key-value timestamp structure, satisfying the stem's throughput and latency constraints.

BigQuery is the correct answer because it is a fully managed, serverless data warehouse designed for petabyte-scale analytics using standard SQL. It automatically handles infrastructure provisioning, scaling, and high availability, with a columnar storage format and a powerful distributed query engine (Dremel). BigQuery also includes built-in features like BigQuery ML for in-database machine learning, partitioning/clustering for performance, and a pay-per-query pricing model, making it a true serverless data warehouse rather than a provisioning-based service.

Cloud SQL with a regional (HA) configuration is the correct choice because it provides a fully managed relational database with automatic failover to a standby instance in a different zone within the same region. Data is synchronously replicated to the standby, so if the primary zone experiences an outage, Google Cloud promotes the standby with minimal disruption and no manual intervention. This gives the legacy monolithic application the ACID transactions, relational queries, and high availability it needs, at a cost and complexity level appropriate for moderate workloads.

Cloud Run scales container instances to zero when no requests arrive, billing only per request and consumed CPU/memory during execution. This satisfies the unpredictable-traffic and pay-only-when-serving constraints, unlike GKE node pools or Compute Engine VMs, which incur cost while idle.

Preemptible VMs are Compute Engine instances that are up to 80% cheaper than standard VMs and are ideal for fault-tolerant, batch workloads. They can be terminated by Google at any time within their maximum runtime of 24 hours, so the job must be checkpointed or designed to restart gracefully. Since the batch job runs daily and is inherently tolerant of interruption, using preemptible VMs maximizes cost savings without sacrificing correctness, making this the most cost-effective choice.

Cloud Functions (2nd gen) is a fully managed, event-driven compute service that can be triggered directly by Pub/Sub messages via Eventarc. It scales automatically from zero to thousands of concurrent invocations and bills only for the time your code runs, so there is no idle capacity or cluster infrastructure to manage. This makes it the most cost-effective and operationally simple choice for processing sporadic events.

Cloud Run executes stateless containers on a fully managed platform, where each instance only receives compute billing while actually processing a request and the service can scale down to zero when no traffic arrives. It automatically provisions instances based on concurrency and can start many instances to handle bursts, with optional min instances for latency-sensitive workloads. A containerized web application is an ideal fit because Cloud Run accepts any container image that listens on a port, and integrates directly with Cloud Build and Artifact Registry.

This is the exact HA VPN architecture: one regional HA VPN gateway exposes two external IP addresses (called interfaces) in the same region, and each interface forms its own IPsec tunnel to a different on-premises device. The two tunnels run as an active/active or active/standby pair using BGP dynamic routing, so if one on-premises device or tunnel fails, the Cloud Router can withdraw routes and send traffic through the surviving tunnel. This configuration is required to meet the 99.99% availability SLA for Cloud VPN.

Organization policies applied at the organization node are inherited by every folder and project, so new projects automatically receive the location and external IP restrictions. This central enforcement does not depend on application teams and satisfies the auditor requirement that all resources comply without per-project configuration.

Spot VMs offer deep discounts for interruptible workloads, and a managed instance group with automatic recreation replaces preempted instances so the batch job can resume. This combination matches the tolerance for interruptions, the cost goal, and the requirement to restart automatically with minimal manual effort.

Cloud SQL HA automatically fails over to a synchronous standby in a different zone, protecting against zonal outages. A read replica, created using binary log replication, serves read-only queries like reporting without burdening the primary. Together, these features satisfy both availability and performance needs, allowing the reporting workload to run in parallel with production.

This is correct because the HTTP request travels from an instance in subnet-a (source 10.0.1.0/24) to an instance in subnet-b (destination) on TCP port 80. An ingress rule on subnet-b with the source range set to 10.0.1.0/24 explicitly allows that inbound connection at the destination. In GCP, the destination subnet's ingress rules are the primary gate for allowing traffic to reach the target instance.

Cloud Run runs stateless containers in a fully managed serverless environment, scales automatically based on requests, and can scale to zero instances when idle so no cost accrues. It requires no Kubernetes knowledge and bills per request and resource usage, directly matching the startup's operational and cost constraints.

A managed instance group (MIG) is the correct backend infrastructure because it maintains a pool of identical VM instances across multiple zones, enabling the HTTP(S) load balancer to distribute traffic and automatically heal failed instances. MIGs support autoscaling based on load, which is essential for a scalable web application, and they provide the instance-level health checking that the load balancer relies on to route requests only to healthy VMs.

Cloud Functions (Gen 2) is the right choice because it offers first-class event triggers from Cloud Storage through Eventarc, letting you run code directly when an object is finalized or deleted. It is fully serverless, scales automatically from zero, and you only pay for execution time, which is ideal for a small startup. The maximum timeout of 60 minutes comfortably covers the stated 10-minute processing requirement, and the function is invoked automatically without any polling or VM management.

Firestore is a flexible, scalable NoSQL document database designed natively for mobile app development, with real-time listeners that push data changes to clients instantly and offline data persistence that automatically syncs when connectivity returns. Its client SDKs for iOS, Android, and web handle multi-device synchronization, conflict resolution, and data integrity out of the box, making it the ideal choice for this real-time mobile backend use case.

Create two node pools, e.g. a regular pool for critical services and a spot/preemptible pool for non-critical work, then taint the spot pool with a key such as spot=true:NoSchedule. Critical pods are deployed without the matching toleration, so the Kubernetes scheduler will never place them on spot nodes; non-critical pods include the toleration and can use the cheaper spot capacity. This precisely controls placement while keeping a single cluster and simplifying operations.

Cloud Run is the correct choice because it directly runs stateless HTTP container images in a fully managed, serverless environment, scaling from zero to handle traffic and back to zero when idle. You are billed only for compute resources used during request processing, not for paused instances, and it handles TLS, revisions, and autoscaling natively.

A Service provides the stable virtual IP and load-balancing layer that distributes traffic across the application's pods, and it is the resource an Ingress or external load balancer targets for SSL termination, satisfying the exposure requirement in the stem.

Comparing on-demand query pricing for the identical workload establishes the break-even baseline: if on-demand costs less than the flat-rate commitment, committing wastes money. This directly addresses minimising commitment risk by quantifying whether reserved capacity is justified for the nightly batch job.

Coldline storage is designed for data that is expected to be accessed at most once per 90 days, making it a perfect match for a 90-day retention period. The lower per-GiB storage price compared to Standard and Nearline, combined with lifecycle deletion at 90 days, minimizes cost without incurring early deletion fees (Coldline has a 90-day minimum storage duration). This directly satisfies the requirement to store event logs for 90 days and then delete them.

Cloud SQL for PostgreSQL is a fully managed, PostgreSQL-compatible database service that supports the same SQL dialect, extensions, and client protocols as standard PostgreSQL. It enables a straightforward migration path for on-premises PostgreSQL databases using tools like Database Migration Service or pg_dump/pg_restore. Cloud SQL also provides automated backups, high availability, and scaling, making it the optimal choice for a direct PostgreSQL migration without application code changes.

Cloud Functions (2nd gen) is built on Cloud Run infrastructure and, unlike the 1st gen, supports deploying custom container images directly. It provides a fully managed, event-driven serverless execution environment that scales to zero and brings the same container runtime benefits as Cloud Run, while adding event-triggering capabilities like Pub/Sub, Cloud Storage, and HTTP invocations.

Cloud SQL for PostgreSQL is the managed relational database service natively compatible with PostgreSQL, so your existing schema, queries, and tools carry over. It automates daily backups with transaction log-based PITR by default, offers high availability via a regional failover replica, and carries a 99.95% SLA for the Standard and Enterprise editions. This directly satisfies the stated requirements without requiring you to operate the database infrastructure.

BigQuery is Google Cloud's serverless, highly scalable data warehouse optimized for analytical queries on massive datasets. It separates storage from compute, uses columnar storage and a distributed query engine, and offers pay-per-query pricing, so you only pay for the data scanned. With features like partitioning, clustering, and BI Engine, it is the ideal choice for complex analytical workloads without managing infrastructure.

After purchasing a capacity commitment, you must create a reservation and then create an assignment that associates that reservation with specific projects (or folders/organizations). Once the assignment is in place, query jobs issued from those assigned projects consume the reserved slots, and their usage is billed at the flat-rate, on-demand pricing no longer applies.

Cloud Run is a managed serverless container platform that executes your container image on demand, automatically scaling instances from zero to thousands based on incoming HTTP traffic and billing only for resources used during request processing. It is purpose-built for stateless HTTP workloads and supports common features like health checks, environment variables, secrets, and gRPC, all without requiring you to provision or manage any servers. For a containerized web application, this directly satisfies the requirement with minimal operational effort and can scale to zero when idle.

Custom mode VPC is the correct choice because it begins with no subnets and lets the engineer explicitly define each subnet's IP CIDR range and region. This provides full control over the address space, including private or publicly routable blocks, to avoid conflicts and meet design requirements. For a task that requires setting custom subnet IP ranges per region, this mode is the only way to do so natively.

Preemptible VMs cost up to 60–80% less than standard on-demand VMs and are explicitly designed for fault-tolerant, batch workloads that can be interrupted. Compute Engine can terminate a preemptible VM at any time, but it will always run for at least 30 seconds, and the job should be coded to handle early termination by persisting progress to durable storage. Because this nightly batch job is by nature interruptible and short-lived, preemptible VMs are the cost-optimal choice and align with Google's best practices for batch processing.

Dedicated Interconnect provides a direct, private physical connection between an on-premises data center and Google Cloud, typically via a co-location facility with one or more 10 Gbps or 100 Gbps links. This dedicated, high-bandwidth link bypasses the public internet, delivering more consistent latency, higher throughput, and an SLA covering availability (up to 99.99% when configured with redundant connections). It is the correct choice here because it is purpose-built for hybrid cloud connectivity that requires reliable, secure, and dedicated bandwidth between a data center and Google Cloud.

Committed use discount (1 year) is the correct choice because it aligns with the scenario of running an n2-standard-4 instance consistently over a year. In the Google Cloud Pricing Calculator, selecting a 1-year CUD for compute resources like vCPUs and memory typically yields a discount of approximately 20-30% compared to on-demand pricing. The calculator has a dedicated field to add this commitment, and choosing it directly answers the question by reducing the estimated cost. This is the best option among the list since other discounts either do not apply or are automatically included.

Cloud SQL is a fully managed relational database service offering MySQL, PostgreSQL, and SQL Server engines with automated backups, point-in-time recovery, and integrated high availability, making it ideal for OLTP workloads using SQL. It provides strong ACID consistency and a 99.95% SLA at a predictable price point for databases under 10 TB, which fits the stated need without over-provisioning. This combination of managed operations, relational features, and reasonable cost makes Cloud SQL the correct choice.

Cloud Storage is the correct choice because it is a durable, highly available object storage service with a global namespace and public HTTPS ingestion and serving endpoints. It provides strong consistency, configurable permissions, and can integrate with Cloud CDN for low-latency delivery of cached content, making it ideal for user-generated photos, videos, and documents. Lifecycle policies can cost-effectively archive older content, and resumable uploads support large files from mobile and web clients.

Global HTTP(S) Load Balancing is a correct choice because it uses a single anycast IP to route user traffic to the closest healthy backend across multiple Google Cloud regions. It automatically detects and drains unhealthy backends, supports autoscaling, and provides layer 7 content-based routing. This service delivers the required high availability for the web application's compute and network layer.

Sustained use discounts are applied automatically when a VM runs for more than 25% of a billing month (approximately 186 hours), without requiring any upfront commitment or configuration. For a VM running 12 hours daily, monthly usage is roughly 360 hours, so the discount kicks in automatically after the threshold is crossed, reducing the bill by up to 20-30% based on the on-demand price — exactly the kind of predictable, usage-based discount this team can estimate.

Object Lifecycle Management is a native Cloud Storage feature that lets you define rules to automatically delete or transition objects based on conditions like age. A rule with action 'Delete' and condition 'Age: 30 days' will remove objects that are at least 30 days old. This directly satisfies the developer's requirement for scheduled deletion, making it the correct choice.

Creating a cross-region read replica in europe-west1 is correct because Cloud SQL supports read-only replicas in a different region, using asynchronous replication to serve queries close to the users. This reduces read latency for European users while keeping writes on the primary instance. The replica can also be manually promoted to a standalone primary for disaster recovery, but it does not require an HA configuration or additional on-premises infrastructure.

Cloud Run is Google Cloud's fully managed serverless container platform that executes stateless containers on a Knative-based infrastructure, making it ideal for an HTTP web application. It automatically scales to zero when there is no traffic, so you pay nothing during idle periods, and it scales up to thousands of concurrent instances based on incoming requests, with per-request billing that only charges from the moment a request starts to when it finishes. Cloud Run supports any OCI-container image, meaning you can package a web server (e.g., Nginx, Express, Django) and it will handle TLS certificates, domain mapping, and load balancing natively. For variable traffic patterns of a stateless HTTP app, Cloud Run offers the perfect balance of elasticity, cost-efficiency, and operational simplicity.