PCA — Frequently Asked Questions

BigQuery is the analytics destination, but the scenario describes processing requirements — hourly jobs plus live-processing data as it arrives. Dataflow performs that unified batch and stream processing, after which results can be loaded into BigQuery for analysis.

Spark on Dataproc can run both, but Dataproc requires you to provision and manage clusters. With no existing code, Dataflow's serverless Beam model is the simpler, officially preferred answer.

Object storage has no rows or query engine and is built for batch-oriented file access, not a continuous per-click ingest stream. Bigtable handles the event-rate write volume and still supports the later analytical reads.

No — Cloud SQL is a relational OLTP service whose write throughput, connection count, and storage growth scale vertically and saturate far below a sustained event stream of this size.

A canary sends only a small share of traffic, so load-dependent performance bugs may never appear until full rollout. It limits blast radius but does not reproduce production load during testing.

The question permits adjusting either test or deployment procedures; fixing unrealistic test load removes the root cause before any deployment occurs.

While GCS is cheaper, it stores logs as flat files. Analyzing them requires custom scripts or manual inspection, which is slower and less scalable than using BigQuery's SQL interface for instant filtering.

Yes, there are storage and query costs associated with BigQuery. However, for organizations requiring frequent or detailed audits, the operational efficiency and reduced labor time often justify the expense.

Deployment Manager provisions Google Cloud infrastructure from templates (VMs, networks, disks); it does not create Kubernetes workload objects. A Deployment manifest must be submitted through kubectl against a running cluster's API server.

kubectl is a client for an existing Kubernetes API endpoint, so it cannot provision a GKE cluster. Creating a cluster on Google Cloud is done with gcloud container clusters create, the Console, or Terraform.

Google Cloud documentation states that read replicas do not provide failover capability; they are for read scaling. For HA failover, you need a regional HA configuration with a standby instance in another zone.

Yes. Simulating a zone failure directly tests whether the regional MIG can withstand the loss of compute resources in one zone, which is a core principle of resilience design.

While useful for monitoring, INFORMATION_SCHEMA tables are not retained as long as audit logs and are not considered an immutable audit trail for compliance.

No, bq ls lists jobs interactively and is not practical for aggregating historical data across multiple users and months programmatically.

BigQuery is an analytics warehouse built for batch loads and SQL scans; it cannot sustain continuous high-rate ingestion with millisecond point lookups, which Cloud Bigtable delivers.

Traffic has idle periods and cost must stay low, so Cloud Run's ability to scale to zero matters; a managed instance group must keep at least one VM running and billing.

Cloud CDN caches content at Google's edge locations and integrates directly with the HTTP(S) Load Balancer the question requires, delivering lower latency and higher reliability than serving straight from a bucket.

Cloud Run is purpose-built for containerized HTTP services with longer request timeouts and streaming, whereas Cloud Functions targets short-lived event-driven workloads and isn't ideal for public API backends.

At 1 Gbps, 10 TB transfers online in about 30 hours. Transfer Appliance requires shipping, loading, returning, and rehydrating data—totaling 1–3 weeks—so it is substantially slower for this volume and bandwidth.

That recommendation is conditional: appliance is preferred only when the online transfer time substantially exceeds the ~20-day appliance turnaround. Here 30 hours is far less than 20 days, so gsutil -m is the faster, cheaper option.

No, snapshots are project-scoped. You must either share the snapshot via IAM permissions or convert it to an Image and import it into Project B.

Option B implies using the snapshot directly. In GCP, you cannot attach a snapshot from Project A as a boot disk for an instance in Project B without first creating an Image from that snapshot.

Writing through gcsfuse is network-bound and far slower than Local SSD I/O, so the backup runs longer and the production database stays under read load for more time. Local SSD staging plus gsutil gives the fastest completion, which the question explicitly demands.

Cloud Persistent Disk snapshots capture an entire disk image, not a single logical database, and the snapshot process reads from the same persistent disk serving production traffic. That violates the requirement that backup activity must not impact disk performance.

Bigtable's performance depends on your schema design, row key layout, cluster sizing, and access patterns. Google's own documentation recommends running your typical workloads against Bigtable for capacity planning, so you must validate it under load.

Running load tests against production risks degrading real users, and recording every production transaction for replay is impractical and raises privacy concerns. Load testing should use a dedicated isolated environment with synthetic or anonymized data.

Appliances are recommended only if online transfer exceeds one week. On a 1 Gbps link, 10TB takes ~30 hours, making the appliance slower and more expensive.

No. The 5TB limit applies to single objects. You can split the database dump into multiple smaller files and upload them all concurrently using gsutil/gcloud.

Monitoring alerts track performance and uptime. While budget alerts exist, they lack the granular visibility needed to understand which resources drive costs without proper labeling.

While technically possible with custom pipelines, GCP's native and recommended workflow for detailed billing analysis is exporting to BigQuery, making option C incorrect in this context.

Replicas provide near-continuous data synchronization, keeping data loss within minutes (15 min RPO). Snapshots are point-in-time and can lose up to a day's worth of data if taken daily.

Yes, Google Cloud supports Global External TCP/UDP Load Balancing. The question specifies HTTP(S), but the principle of global health-check-based failover applies similarly to other protocols.

While Multi-Regional offers higher availability, it has lower write throughput limits and higher write latency due to cross-region replication. For ETL ingestion, speed and reliability of the initial upload are prioritized, making Regional buckets the better fit.

No. Directly uploading to Cloud Storage via HTTPS APIs is more secure, scalable, and reliable than hosting custom FTP servers on VMs, which adds management overhead and potential single points of failure.