GCP Professional Cloud Architect Practice Test

Create a single Cloud Billing Budget that covers all projects and sets two threshold rules: one at 90 % with email notifications to the FinOps list, and one at 100 % that publishes a message to a Cloud Pub/Sub topic. Deploy a Cloud Function subscribed to that topic. When triggered, the function calls the Cloud Billing API to disable billing (or set the spending limit to zero) on the dev and test projects and uses the Compute Engine API to stop their VM instances. This relies entirely on managed services-Budgets, Pub/Sub, Cloud Functions, and Cloud APIs-fulfilling both the alerting and automated remediation requirements without introducing additional infrastructure.

Other options fall short:

• Relying solely on Cloud Monitoring alerts cannot enforce hard spend stops and does not integrate directly with budgets.
• Purchasing CUDs and exporting data to BigQuery offers no enforcement or timely alerting.
• Manipulating quotas or policy constraints does not correlate with real-time spend and cannot guarantee shut-down exactly at 100 % of the budget.

Cloud Billing Budgets can be created per cost center (using billing sub-accounts, projects or labels) with threshold rules that publish budgetExceeded messages to Pub/Sub. Detailed cost data can be exported continuously to BigQuery, where Looker Studio (formerly Data Studio) can build a weekly dashboard that slices spend by cost center. The other options miss one or both requirements: Cloud Monitoring billing metrics do not provide fine-grained cost-center breakdowns; Recommender APIs and console cost tables cannot automate Pub/Sub alerts; committed use discounts and PDF reports do not satisfy the near-real-time alerting or interactive dashboard needs.

Cloud Pub/Sub provides globally distributed, highly durable ingestion that scales to millions of messages per second without manual sharding. A streaming Dataflow pipeline can branch the stream, writing near-real-time aggregates to BigQuery and archiving the unchanged raw events to a Cloud Storage Archive bucket, the lowest-cost tier for long-term retention. Dashboards can query the streamed aggregates in BigQuery within seconds, and BigQuery ML can train models directly on the data without export, satisfying the weekly retraining requirement. All chosen services encrypt data in transit and at rest and are HIPAA-eligible. The alternative designs either cannot meet the ingest scale and latency requirements (Cloud SQL, Firestore), rely on a deprecated service (IoT Core), or use a more expensive storage class, so they fail one or more stated constraints.

Cloud Functions scale horizontally based on incoming events with no servers to manage. When each service publishes events to a dedicated Cloud Pub/Sub topic, producers and consumers are fully decoupled, messages are durably stored and delivered at-least-once, and back-pressure is automatically absorbed. This satisfies independent scaling, asynchronous communication, and tolerance of downstream failures. Operating a RabbitMQ cluster on GKE requires additional administration, Cloud Tasks is intended for point-to-point task dispatch rather than broadcast event streams, and using Cloud SQL tables with App Engine is synchronous and tightly couples services.

The open-source Data Validation Tool (DVT) is designed specifically to verify large-scale data migrations. It runs Apache Beam pipelines (locally or on Dataflow) that connect to two heterogeneous data stores, compute row counts and configurable column aggregates (such as checksums), and write a summary of any discrepancies. Datastream's drift alerts focus on schema changes, not data accuracy. Cloud SQL Insights surfaces query performance, not data parity. Cloud Monitoring uptime checks report service availability, not detailed table-level comparisons.

Granting the Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) on the individual CryptoKey lets the service account call Encrypt and Decrypt-exactly what it needs to read and write data protected by the key. The role does not include administrative permissions such as update, disable, destroy, or setIamPolicy, so key management remains exclusively with the Security team. Granting roles/cloudkms.admin or project-level Owner would violate least-privilege by allowing key administration. Granting storage-specific roles does not give the service account the cryptographic permissions required to use the CMEK.

Running the workload on Cloud Run delivers automatic scaling from zero to thousands of container instances without manual VM management, aligning with the minimal-ops requirement and handling 20× traffic spikes. Deploying Cloud Run services in multiple regions behind a global external HTTPS load balancer and Cloud CDN keeps user latency low worldwide. A Dedicated Interconnect supplemented with HA VPN provides high-bandwidth, encrypted connectivity to the on-premises PostgreSQL instance until it is migrated. Cloud Deploy supports progressive rollouts (canary or blue/green) for Cloud Run, enabling zero-downtime releases. The other options either rely on regional or preemptible VM infrastructure that increases operational burden, lack a global front-end, or move the database prematurely, so they fail to meet one or more stated business requirements.

Anthos Service Mesh (ASM) automatically injects Envoy sidecars that export server request-latency distribution metrics to Cloud Monitoring and send distributed traces to Cloud Trace without requiring any application-level instrumentation. Those latency histograms can be used to define an SLO on the 95th-percentile latency of the booking service, and Cloud Monitoring supports burn-rate alerting on that SLO, enabling paging when the 300 ms objective is violated. The other options either rely on simpler uptime checks that cannot express a percentile-based SLO, require developers to add OpenTelemetry libraries, or add and operate separate Prometheus/Jaeger stacks, all of which increase operational burden.

Creating a second multi-zonal MIG in another region and adding it to the existing global HTTP(S) load balancer provides compute capacity even if the original region is lost. A cross-region Cloud SQL read replica keeps data nearly up to date (seconds to minutes replication lag), satisfying a 15-minute RPO. Automating promotion of the replica and updating the application's connection string can bring the service back within the 5-minute RTO without changing platforms. Migrating to Cloud Spanner or Cloud Run would meet the objectives but introduces significant cost and re-engineering. Restricting resources to a single region, whether by expanding to more zones or changing the data store, does not address a regional outage and therefore fails the new requirements.

Cloud Run is designed to run stateless container images without infrastructure management. It supports any containerized application that listens for HTTP requests, so the existing ImageMagick-based container can be used unchanged. Eventarc can deliver Cloud Storage object-create events to Cloud Run, satisfying the event-driven trigger requirement. Cloud Run automatically scales instances up rapidly in response to traffic and back down to zero when idle, so the company pays only for actual request processing time.

Cloud Functions (1st gen) would require rewriting the service into a supported language runtime and does not allow bringing an arbitrary container image. GKE Autopilot removes some cluster management tasks but still incurs per-pod charges even when idle and does not scale to zero by default. A managed instance group on Compute Engine needs VM administration and keeps instances running, leading to higher idle cost.

Running the stateless application on Cloud Run in two European regions allows automatic scale-out from zero to many instances without manual intervention and can be fronted by a global external HTTP(S) Load Balancer that provides cross-regional fail-over. Storing data in Cloud SQL for MySQL with a highly available primary instance in europe-west1 and an asynchronous cross-region read replica in europe-west4 keeps data within the EU, delivers an RPO of seconds to minutes (well under 15 minutes), and-after scripted promotion-meets the 1-hour RTO target. Because Cloud SQL is priced per-instance and per-GB rather than per-node like Cloud Spanner, it offers lower total cost for typical ecommerce database sizes.

The GKE-only and single-region designs do not meet the regional fail-over requirement, while the App Engine plus Cloud Spanner option satisfies the objectives but violates the cost-optimization mandate. Nightly snapshot-based replication cannot achieve the required 15-minute RPO.

Creating a cross-region read replica of the Cloud SQL primary in another region keeps the replica asynchronously updated, and typical replication lag is seconds-well inside the 5-minute RPO. Promoting the replica to primary during a regional outage is a documented procedure that can be automated to finish in minutes, satisfying the 30-minute RTO. Deploying a second MIG in the same target region and adding it as a failover backend to the global external HTTP(S) load balancer lets traffic switch automatically when the original region is unreachable, with minimal incremental cost (only the replica instance and additional autoscaled VMs).

Enabling only regional HA for Cloud SQL or placing all resources in one region cannot survive a full-region failure. Relying on nightly exports and manual recreation would exceed both the 5-minute RPO and 30-minute RTO. Migrating to Cloud Spanner multi-region would meet the objectives but at a significantly higher ongoing cost than a single Cloud SQL primary plus one read replica, so it is not the lowest-cost solution that satisfies the requirements.

Google no longer requires customers to request or obtain explicit approval before running penetration tests as long as the activity is limited to the customer's own GCP resources and complies with the Acceptable Use Policy (AUP). The AUP forbids tests that could adversely affect Google services or other tenants, including any form of DoS or resource-exhaustion attack. Therefore the team may proceed without filing a request only if they omit the DoS portion of the plan; otherwise the activity would violate the AUP.

The other options are incorrect because:

• Google does not offer an approval queue or authorization token for routine penetration tests, and filing a special request is unnecessary.
• Cloud Security Command Center does not issue "tokens" for destructive testing, nor does it override the AUP.
• IAM-specific probes are treated the same as any other penetration test; no separate notification channel exists.

Horizontal Pod Autoscaler (HPA) adds or removes pod replicas in response to metrics such as CPU load, letting the service grow when demand rises and shrink when it falls. However, replicas can only start if the cluster has spare capacity. Cluster Autoscaler (CA) watches for Pending pods and, when none of the current nodes can fit them, increases the node pool size; it also scales nodes back down when they sit unused. Using HPA without CA could still leave replicas Pending, while CA alone would not increase pod count when CPU rises. Combining HPA with CA lets pods and nodes grow together during peaks and both contract during off-hours, minimizing cost. Moving the workload to Cloud Run or relying on Vertical Pod Autoscaler would not satisfy the requirement to stay on the existing GKE deployment or would not address pod-level scaling needs.

Cloud Run allows multiple revisions of the same service to be active at once and supports fine-grained traffic splitting between them. By directing a small percentage of production traffic to the new revision first, the team can monitor live metrics and gradually increase the percentage when healthy. Reverting is instantaneous-simply shift all traffic back to the previous revision. Creating an entirely separate service behind a load balancer resembles blue-green deployment but duplicates resources. An in-place rolling update without traffic control offers no safe observation window, and moving the workload to GKE introduces unnecessary complexity for this requirement.

Highly available (HA) Cloud VPN creates redundant IPsec tunnels over the public internet and exchanges routes with Cloud Router. Because it uses existing ISP links, it can be provisioned in software within minutes, provides encryption in transit, and carries a 99.99 % SLA when at least two tunnels are established in separate zones. Dedicated and Partner Interconnects meet or exceed the availability goal but require ordering and provisioning physical circuits that can take weeks and incur additional cost. Classic VPN is quick to deploy but its 99.9 % SLA does not meet the stated availability requirement. Therefore, HA Cloud VPN is the best fit for a fast, temporary, highly available connection that relies on existing internet bandwidth.

Installing the Ops Agent on each Compute Engine VM streams host metrics and logs directly to Cloud Monitoring and Cloud Logging. Cloud Run already exports service-level metrics and container stdout/stderr to the same back-ends, so a unified dashboard can be built without additional collectors. In Cloud Logging, a logs-based metric filtered on textPayload:"payment_failed" can count matching entries; attaching an alerting policy to this metric meets the notification requirement. Finally, enabling the Cloud Trace API and adding the language-specific Trace agent or OpenTelemetry exporter to the services allows spans to be sent to Cloud Trace, producing end-to-end request traces that highlight the slowest downstream call. The other options either rely on self-managed stacks, batch processing, or tools (uptime checks, Cloud Profiler) that do not meet all three observability goals.

During planning you translate the findings from discovery into a concrete, risk-mitigated migration design. Defining an explicit rollback strategy and cutover sequencing is part of that design work: it uses the inventory and performance data gathered in discovery and is required before you launch DMS jobs or validation tests in execution. Cataloging schemas and measuring utilization are discovery tasks, while starting DMS continuous replication and running post-migration performance tests are execution-phase activities.

Google Cloud evaluates firewall rules from the lowest numeric priority to the highest and stops at the first match. Because the default ingress rule "allow-ssh" (priority 65534) would still permit SSH from anywhere, a higher-priority deny is needed after a specific allow from the bastion subnet. Likewise, two egress rules are required: an early allow to 10.16.0.0/16 followed by a broader deny to 0.0.0.0/0. Targeting the rules at the "app-tier" tag prevents any effect on other VMs, so four tag-scoped rules (allow + deny for both directions) are the minimal compliant set; deleting or changing default rules would impact other workloads, and omitting the deny-SSH rule would leave the servers exposed.

Creating a cross-region read replica for the existing Cloud SQL instance keeps the database fully managed while streaming changes asynchronously to another region with typical replication lag in seconds, well within the 5-minute RPO. In a regional outage, administrators can promote the replica to primary and redirect application traffic, a process that is normally completed in minutes, satisfying the 1-hour RTO. The alternative options either rely on time-consuming backup restores, introduce significantly higher operational complexity, or require migrating to a more expensive service such as Cloud Spanner, so they do not fit the stated cost and simplicity constraints.