Google ACE Practice Question: Ensuring Successful Operation of a Cloud Solution

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  bq show --format=prettyjson mydataset.mytable

  Why it's wrong here

  bq show --format=prettyjson mydataset.mytable retrieves the table's metadata object, including its schema, partitioning, clustering, labels, and creation time. It has no concept of a SQL query or an estimate of how many bytes a specific query would process. Therefore, running bq show tells you what the table looks like, but absolutely nothing about the cost or performance of your slow query.

• ✗

  bq ls --format=prettyjson mydataset

  Why it's wrong here

  bq ls --format=prettyjson mydataset lists the datasets or tables in the given dataset, returning raw metadata such as table IDs, creation times, and optionally sizes and row counts. It takes no query text as input, so it cannot parse or validate your SELECT statement, and it cannot compute the bytes that a future query would read. It merely gives a directory view, not an execution plan or cost estimate.

• ✓

  bq query --use_legacy_sql=false --dry_run 'SELECT ...'

  Why this is correct

  bq query --use_legacy_sql=false --dry_run 'SELECT ...' sends the query to BigQuery's planner, which validates the SQL and returns the estimated number of bytes that would be read from storage, without actually executing the query or consuming slots. The --use_legacy_sql=false flag ensures your statement is parsed as standard SQL, not the older legacy dialect, which matters for syntax compatibility. This is exactly the right tool when a query is slow and you want to quickly see how much data it touches before investing time in optimization or running it.

• ✗

  bq query --use_legacy_sql=false --batch 'SELECT ...'

  Why it's wrong here

  bq query --use_legacy_sql=false --batch 'SELECT ...' submits the query as a batch job, meaning BigQuery will start it whenever idle compute resources are available, rather than running in interactive priority. However, --batch does not veil the execution: it still consumes slots, reads data, and bills you for the bytes processed, so it cannot estimate a query's cost before it runs. To get an estimate without side effects, --dry_run is the only correct flag.

Go deeper

Related to this question