Task 5.1: Optimizing resources.

• ARun the job with Flexible Resource Scheduling (FlexRS)

  Correct

  FlexRS runs batch jobs at a discounted rate and starts them within six hours, so even a 06:30 start finishes before 09:00.

• BConvert it to a streaming job that uses Streaming Engine

  Incorrect

  Streaming Engine is for streaming jobs; turning a nightly batch into an always-on streaming job would raise the cost.

• CUse larger worker machine types with fewer maximum workers

  Incorrect

  Changing the machine shape moves cost around but gives no discount, and can lengthen the run.

• DTurn off Dataflow Shuffle to avoid the shuffle service charges

  Incorrect

  Shuffle work then runs on the workers instead, usually more slowly; it is not a discount mechanism.

FlexRS is for batch work that is not time-critical. It mixes preemptible and standard VMs and charges a uniform discounted rate, in exchange for starting the job at some point within six hours of submission.

• AA maximum bytes billed limit on each analyst's queries

  Incorrect

  Maximum bytes billed caps one query at a time; many queries under the limit can still add up to a huge day.

• BA custom quota on query usage per user per day

  Correct

  The QueryUsagePerUserPerDay custom quota sets a daily limit on bytes processed for each user and returns quotaExceeded once it is reached.

• CA billing budget with alerts at 50, 90 and 100 percent

  Incorrect

  Budgets send notifications; they do not stop queries.

• DA reservation with a 100-slot maximum for the analysts

  Incorrect

  A reservation changes the pricing model to capacity; it limits throughput, not bytes per analyst per day.

Custom query quotas apply to on-demand pricing. A project-level quota caps all users together and a user-level quota caps each user and service account separately; when a quota is used up, BigQuery returns a quotaExceeded error until the next day.

• ADataflow Shuffle for the job's grouping steps

  Incorrect

  Dataflow Shuffle is the service-side shuffle for batch jobs; it is not the option for streaming state.

• BFlexRS for the job's worker pool

  Incorrect

  FlexRS cannot be enabled for a streaming job, and it does nothing about where the pipeline's state is kept.

• CVertical Autoscaling with a higher memory limit

  Incorrect

  Vertical Autoscaling adjusts worker memory, but the work still runs on the workers, so they stay large.

• DStreaming Engine for the job, with smaller worker types

  Correct

  Streaming Engine moves pipeline execution out of the worker VMs, which cuts their CPU, memory and disk use, gives smoother autoscaling and applies service updates without redeploying.

Streaming Engine runs much of a streaming pipeline's execution in the Dataflow service backend instead of on the workers. Jobs then need fewer and smaller workers, autoscale more granularly and pick up service updates without a redeploy; Google recommends worker types with fewer vCPUs with it.

• AOne budget for each team with alert thresholds on the project

  Incorrect

  Budgets send alerts against an amount; they produce no per-team cost report, and without labels nothing tells one team's jobs from another's.

• BA team label on each job, plus Cloud Billing export to BigQuery

  Correct

  Labels on jobs are carried into the billing data, and the billing export to BigQuery lets finance group costs by the team label.

• CA custom query quota for each team's service account

  Incorrect

  Quotas produce no report of how much each team spent.

• DA separate reservation for each team in the same project

  Incorrect

  Reservations change the pricing model to capacity, and by themselves they produce no per-team cost report.

Labels are key-value pairs on BigQuery resources and jobs that flow into Cloud Billing data. With the billing export to BigQuery, costs can be grouped and filtered by label, which gives per-team chargeback inside a shared project.

• AMove the bucket, or the cluster, so that both are in one region

  Correct

  Reading data within the same region avoids inter-region data transfer charges, which Google advises by placing compute and storage together.

• BTurn on Autoclass so that the bucket uses cheaper classes

  Incorrect

  Autoclass lowers storage price but changes nothing about cross-region transfer.

• CUse Spot VMs for the cluster's secondary workers

  Incorrect

  The VM pricing model of the workers does not change the network charges for reading across regions.

• DEnable Requester Pays on the bucket for the cluster's project

  Incorrect

  Requester Pays moves the charges to the requesting project; the company still pays them.

Where data sits relative to its processing is a cost decision. Reading a bucket from another region incurs network charges for every byte, so analytics buckets should be in the same location as the compute that reads them unless a residency or resilience requirement says otherwise.

• ABuy the Enterprise reservation with the 100-slot baseline as suggested

  Incorrect

  A baseline is paid for every hour whether or not queries run, which for a mostly idle workload costs far more than its scans.

• BBuy a one-year capacity commitment for 100 slots in Standard edition

  Incorrect

  Standard edition offers no capacity commitments, and a commitment would still pay for idle hours.

• CStay on on-demand pricing, which charges for the bytes queried

  Correct

  On-demand pricing bills per TiB processed, with a free monthly tier, so a small, sporadic workload pays only for what it scans.

• DSwitch to Enterprise Plus edition with autoscaling and no baseline

  Incorrect

  Enterprise Plus has the highest slot price and adds features the team does not need.

On-demand and capacity pricing suit different shapes of workload. Steady, heavy use favours reserved slots; a small, bursty workload with long idle time is usually cheapest on on-demand pricing, where nothing is paid while idle and the first TiB each month is free.