Professional Cloud Architect · 18% of the exam

Analyze and optimize technical and business processes: free practice questions

5 sample questions from our 45-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real Google Cloud exam.

1. A data analytics team at a large enterprise runs ad-hoc BigQuery queries using on-demand pricing. They are considering purchasing BigQuery slot reservations (flat-rate pricing) to reduce costs. The team's query workload averages 200 slots during the day but spikes to 2,000 slots for 30 minutes each morning during a daily batch job. Which slot reservation strategy should the architect recommend?

  • A. Purchase 2,000 slots as a baseline reservation to guarantee capacity for all workloads including the morning spike.
  • B. Purchase 200 slots as a baseline reservation for consistent daytime queries, and use BigQuery Flex Slots (short-term commitments) to handle the 30-minute morning spike.✓ Correct
  • C. Stay on on-demand pricing because the daily batch spike means average slot utilization is too low to justify any reservation.
  • D. Purchase 200 slots as a baseline reservation and set the project's query concurrency limit to prevent the morning batch job from exceeding allocated slots.
Explanation

The optimal strategy is to commit to the predictable baseline (200 slots) at a lower per-slot rate, while handling the short-lived spike with Flex Slots, which can be purchased for as little as 60 seconds and cancelled quickly. This avoids over-committing to 2,000 slots for a workload that only needs them for 30 minutes per day. Option A is incorrect because purchasing 2,000 slots to handle a 30-minute daily spike is extremely wasteful; the remaining ~23.5 hours those 1,800 excess slots sit idle, paying full reservation cost for unused capacity. Option C is incorrect because a consistent 200-slot daytime baseline is exactly the type of predictable workload that benefits from slot reservations over on-demand pricing; dismissing reservations entirely ignores the baseline savings opportunity. Option D is incorrect because setting a concurrency limit to cap the batch job at 200 slots would severely throttle and slow the morning batch job rather than handling the spike appropriately, creating a different operational problem.

2. A company stores audit log data in a BigQuery table partitioned by log_date. The table has grown to 800 TB over 5 years. Compliance requires retaining all data for 7 years, but queries almost never access data older than 90 days. The team wants to minimize ongoing storage costs while maintaining compliance and query performance for recent data. Which strategy best achieves this? (Select TWO)

  • A. Set a BigQuery table partition expiration of 90 days to automatically delete partitions older than 90 days.
  • B. Configure BigQuery long-term storage pricing by ensuring partitions older than 90 days are not modified, allowing them to automatically qualify for the lower long-term storage rate.✓ Correct
  • C. Export partitions older than 90 days to Cloud Storage (Nearline or Coldline) and delete them from BigQuery, using BigQuery external tables over Cloud Storage for compliance access if needed.✓ Correct
  • D. Use BigQuery table clones for the last 90 days of data to reduce active storage costs while keeping the original table for compliance.
  • E. Enable BigQuery Flex Slots for queries on recent data to reduce slot costs for the high-frequency recent-data queries.
  • F. Compress the older partitions using ZSTD compression within BigQuery to reduce their storage footprint.
Explanation

Long-term storage pricing in BigQuery automatically applies a ~50% storage discount to any table or partition that has not been modified for 90 consecutive days — this requires no configuration change and directly reduces the cost of the 5 years of rarely-touched historical data. Exporting partitions older than 90 days to Cloud Storage Nearline/Coldline and deleting them from BigQuery is the most cost-effective approach for rarely accessed data, as Cloud Storage Coldline is significantly cheaper than even BigQuery long-term storage; BigQuery external tables allow querying that data for compliance purposes without re-importing it. Option A (partition expiration of 90 days) would delete data older than 90 days, violating the 7-year compliance retention requirement. Option D (table clones) are a copy-on-write feature useful for experimentation, not for tiering storage costs across time ranges. Option E (Flex Slots) addresses query compute cost, not storage cost. Option F is incorrect: BigQuery does not expose a user-configurable ZSTD compression setting per partition; storage compression is managed internally by BigQuery.

3. A growing SaaS company runs a Cloud Run service that processes customer invoices. The service experiences predictable traffic spikes every weekday from 9 AM to 6 PM and is nearly idle overnight and on weekends. The engineering team wants to reduce costs while ensuring the service can handle peak load without cold-start latency impacting users. Which configuration best meets these requirements?

  • A. Set minimum instances to 0 and maximum instances to 100, relying on Cloud Run's automatic scaling to handle all traffic.
  • B. Set minimum instances to a value that covers baseline peak load during business hours and configure CPU is always allocated to eliminate cold starts.✓ Correct
  • C. Deploy the service on a GKE Autopilot cluster with Horizontal Pod Autoscaler to benefit from node-level bin packing during off-peak hours.
  • D. Use Cloud Scheduler to send warmup requests every minute overnight to prevent Cloud Run instances from scaling to zero.
Explanation

Setting a minimum instance count during business hours ensures instances are pre-warmed and avoids cold-start latency for peak traffic, while 'CPU always allocated' ensures those minimum instances remain ready. This balances cost (idle overnight instances scale to zero) and performance. Option A scales to zero but incurs cold-start latency that impacts users. Option C adds GKE operational overhead and is more expensive for a stateless HTTP workload that Cloud Run handles natively. Option D uses warmup requests to fight the symptom (cold starts) rather than the cause, wastes invocation costs overnight, and doesn't guarantee instance readiness at the moment of a real request.

4. A media company runs a real-time video analytics pipeline on GCP. Their Cloud Run service ingests event data and writes aggregated results to a BigQuery table named `video_events`, which is partitioned by `event_timestamp` (TIMESTAMP, hourly granularity) and clustered by `content_id` and `region`. Analysts report that many of their queries still perform full table scans and incur high on-demand costs. Upon investigation, the team discovers that most analytical queries filter on `region` and `content_id` but span large, unbounded time ranges (e.g., the last 90 days). A smaller subset of queries filter on exact hourly windows. The team is considering additional BigQuery optimizations. Which TWO actions will MOST effectively reduce query costs and improve performance for the majority of analyst queries?

  • A. Replace the hourly TIMESTAMP partitioning with DATE partitioning on `event_timestamp` to reduce partition pruning overhead for queries spanning multiple days✓ Correct
  • B. Enable BigQuery BI Engine reservations sized to the table's hot data footprint to cache frequently accessed aggregations and accelerate dashboard queries
  • C. Add `content_id` and `region` as the leading columns in the clustering order, ensuring the existing clustering already benefits filter pushdown — no schema change is needed
  • D. Materialize a pre-aggregated summary table partitioned by DATE and clustered by `region` and `content_id`, and direct the 90-day range queries to this materialized view✓ Correct
  • E. Increase the number of BigQuery slots by purchasing a flex commitment reservation so that full table scans complete faster, reducing perceived query latency
  • F. Partition the table by `region` using integer-range partitioning instead of timestamp partitioning, since most queries filter on `region` rather than time
Explanation

**Option A (correct):** Switching from hourly TIMESTAMP partitioning to DATE partitioning dramatically reduces the number of partitions the query engine must evaluate for queries spanning 90-day ranges. With hourly partitioning, a 90-day query touches up to 2,160 partitions; with DATE partitioning it touches only 90, improving partition pruning and lowering costs. **Option D (correct):** Creating a pre-aggregated materialized summary table (or materialized view) partitioned by DATE and clustered by `region` and `content_id` directly targets the majority of queries that span large time ranges. Queries read far less data from a smaller, pre-aggregated table, which is the most impactful cost-reduction technique for this pattern. **Option B (incorrect):** BI Engine is a fast in-memory analysis service primarily suited to accelerating BI dashboard tools (Looker Studio, Connected Sheets) for a fixed hot dataset. It does not reduce bytes billed for on-demand ad-hoc SQL queries that scan large historical ranges, so it does not address the root cause. **Option C (incorrect):** The clustering order `content_id, region` is already described as the existing schema. Asserting no change is needed ignores that the queries still perform full table scans due to poor partition pruning on wide time ranges — the real problem is the partitioning granularity, not the cluster column order. **Option E (incorrect):** Purchasing more slots (flex commitments) does not reduce the amount of data scanned; on-demand pricing is billed per byte scanned regardless of slot count. More slots improve concurrency and speed but not cost for on-demand queries. **Option F (incorrect):** BigQuery supports partitioning by INTEGER RANGE, DATE/TIMESTAMP/DATETIME, and ingestion time — but partitioning by a string column like `region` using integer-range partitioning is not directly applicable without a mapping. More importantly, region cardinality is typically low (e.g., 5–20 values), making it a good clustering column but a poor partition key, as it would create very few partitions with uneven data distribution.

5. A company's SRE team is configuring error budgets for a critical payments API. The SLO is defined as 99.95% availability measured over a rolling 28-day window. In the past 28 days, the API served 10,000,000 requests and has already experienced 3,500 failed requests. How many additional failed requests can the service absorb before exhausting its error budget?

  • A. 1,500 requests✓ Correct
  • B. 5,000 requests
  • C. 500 requests
  • D. 6,500 requests
Explanation

Total error budget = 10,000,000 × (1 - 0.9995) = 5,000 allowed failures. With 3,500 already consumed, the remaining budget is 5,000 - 3,500 = 1,500 requests. Option B (5,000) is the total budget ignoring already-consumed failures. Option C (500) would apply if 4,500 failures had already occurred, not 3,500. Option D (6,500) incorrectly adds the already-failed requests to the total budget instead of subtracting them.

40 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free