Select Two (Multi-Select) Questions

Warmline

Why it fails: Warmline is not a GCS storage class; Google offers Standard, Nearline, Coldline and Archive. Nearline is the tempting near-miss, intended for data accessed less than monthly. Warmline would be the right answer only if GCS defined a warm tier between Standard and Nearline, which it does not.

Hotline

Why it fails: Hotline is not a GCS storage class; the valid set is Standard, Nearline, Coldline and Archive. Standard is the tempting equivalent, holding frequently accessed data with no retrieval fee. Hotline would be correct only if GCS named its hottest tier that way, which it does not.

Create a BigQuery dataset and use authorized views to restrict access to specific columns.

Why it fails: Authorized views can restrict access to specific columns, but they require the data to be in BigQuery tables, not external tables. For external data, you would need to create a view over the external table, but authorized views do not provide the same column-level policy tag enforcement. This approach does not leverage the native column-level security features for external tables.

Enable uniform bucket-level access on the Cloud Storage bucket.

Why it fails: Uniform bucket-level access simplifies permissions at the bucket level, but it does not provide column-level access control for BigQuery queries. It controls access to objects in Cloud Storage, not to columns in a query. This does not meet the requirement for fine-grained column-level security.

Set up a Dataplex lake and zone, and register the Cloud Storage bucket as an asset.

Why it fails: While Dataplex can manage and govern data in Cloud Storage, it does not by itself provide column-level access control for BigQuery queries. You would still need to use BigQuery external tables and policy tags. Registering the bucket in Dataplex adds governance but does not directly enable querying or column-level security.

Use an API key associated with the Workflows API and include it in the request header.

Why it fails: API keys are not supported for authenticating to the Workflows API. API keys are typically used for public APIs that do not require user or service account authentication. Workflows requires IAM-based authentication, so API keys would not grant the necessary permissions and are not a valid method.

Use an OAuth 2.0 client ID and secret stored in Cloud Scheduler's configuration.

Why it fails: While OAuth 2.0 can be used for authentication, storing client ID and secret directly in Cloud Scheduler is not a recommended best practice for service-to-service authentication. It requires managing secrets and does not leverage Google Cloud's IAM. Instead, using a service account with OIDC tokens is more secure and integrated.

Use a static username and password stored in Secret Manager and referenced by Cloud Scheduler.

Why it fails: Workflows API does not support basic authentication with username and password. While Secret Manager can store credentials, this method is not applicable because the API expects OAuth or OIDC tokens. Using static credentials would be insecure and is not a supported authentication mechanism for Workflows.

Kubernetes Pod

Why it fails: Kubernetes Pod is not an Airflow connection type; Cloud Composer supports connections such as Kubernetes Cluster or Kubernetes Config Map for cluster access. It is tempting because Airflow's KubernetesPodOperator runs pods, but that operator consumes an existing connection rather than defining a new connection type.

Python

Why it fails: Python is a language for writing operators and hooks, not a registered Airflow connection type; connections are defined by external-system hooks such as HTTP, Postgres or S3. It tempts candidates because Python scripts appear throughout DAGs, but a Python connection would be the right answer only if Airflow exposed a Python-native hook, which it does not.

The user has a slow internet connection

Why it fails: Data quality tasks execute server-side against cloud storage; a slow client connection affects only the administrator's console responsiveness, not task execution. It tempts because latency is a familiar cause of failures elsewhere, but Dataplex and BigQuery quality jobs run within Google Cloud, so bandwidth at the user's location is irrelevant.

The data files were moved to another lake

Why it fails: Moving files to another lake changes the storage location, but quality tasks reference configured datasets and tables, so relocation alone does not break them unless the referenced path or permissions change. It tempts because missing source data does cause failures, yet the actual cause would be a broken reference or revoked access, not the move itself.

Binary

Why it fails: Binary is not a Dataflow windowing type; the supported types are fixed, sliding, session, and global windows. It is tempting because binary appears in other streaming contexts such as binary watermarks or binary encoding, but windowing is defined by time or session boundaries, not numeric bases.

Random

Why it fails: Random is not a Dataflow windowing type; windows are fixed, sliding, session, or global, all defined by time or data-driven boundaries. It is tempting because random partitioning exists in sharding and load-balancing, but that governs key distribution, not how elements are grouped into finite windows.

Automated email alerts

Why it fails: Email alerts are an operational monitoring concern, not a development step for building a pipeline. It is tempting because alerting is genuinely part of running pipelines in production, and it would be correct when configuring observability after the pipeline is deployed.

Manual data entry

Why it fails: Manual data entry is not a Dataflow development step; pipelines ingest programmatically from sources such as Pub/Sub or GCS. It is tempting because entering data feels like part of preparing a pipeline, and it would apply when seeding a small reference dataset by hand outside Dataflow.

Keep all historical logs forever

Why it fails: Retaining every historical log indefinitely accrues Cloud Logging storage charges, raising rather than lowering spend. It is tempting because long retention aids audit and debugging, and is the right choice when compliance mandates it, but cost reduction requires log exclusion filters or a shorter retention period.

Use the largest environment size

Why it fails: Larger environment sizes provision more workers and database capacity, directly increasing hourly Composer charges. It is tempting because extra workers speed up heavy parallel DAG execution, which is correct when throughput is the constraint, but cost reduction comes from right-sizing to the smallest environment that meets workload demand.

Increase scheduler frequency

Why it fails: Raising scheduler frequency triggers more parsing and scheduling cycles, consuming extra CPU and Airflow database operations that raise cost. It is tempting because frequent scheduling shortens task latency, which is correct for time-sensitive pipelines, but cost reduction favours a longer scheduler interval and fewer DAG parses.

Direct keyboard input

Why it fails: Dataflow jobs are triggered via the API, gcloud, the console, a schedule, or a template launched by an event such as a Pub/Sub message or Cloud Function. Keyboard input is not a supported trigger mechanism. It tempts as a generic user action, but no Dataflow trigger consumes direct keystrokes.

GCS bucket browsing

Why it fails: Browsing a GCS bucket is a read operation, not a trigger mechanism; Dataflow jobs launch via the Dataflow API, gcloud commands, templates, or Cloud Scheduler. It tempts because Dataflow pipelines commonly read from GCS, but reading source data differs from initiating execution.

Cloud DNS lookup

Why it fails: Cloud DNS resolves domain names to IP addresses; it cannot invoke a Dataflow job. It tempts because Dataflow workers use DNS internally for networking, but name resolution is unrelated to job orchestration. Valid triggers are the Dataflow API, gcloud, templates, or Cloud Scheduler.

Assets can be created without a storage resource

Why it fails: Assets always represent an existing storage resource, such as a BigQuery dataset, Cloud Storage bucket, or Dataproc metastore; they cannot exist without one. It is tempting because assets are logical entries in a lake, and a resource-less asset would be correct if Dataplex stored data itself, which it does not.

Assets can only be BigQuery tables

Why it fails: Assets can point to Cloud Storage buckets, Dataproc metastore tables, and BigQuery datasets, so restricting them to BigQuery tables is false. It is tempting because BigQuery is the most common Dataplex source, and this would hold if Dataplex governed only BigQuery, which it does not.

Assets duplicate the physical data

Why it fails: Assets reference the underlying data in place; they do not copy or duplicate physical data, so storage is not doubled. It is tempting because registering data in a lake feels like ingesting it, and duplication would be correct for tools that physically copy source data into a managed warehouse.

Use IP-based firewalls for all datasets

Why it fails: Dataplex access control operates through IAM roles on lakes, zones and assets, plus BigQuery and Cloud Storage policies; IP firewalls sit at the network layer and never govern dataset-level access. Firewalls are tempting because they genuinely restrict access to Google Cloud resources, but not to individual Dataplex datasets.

Assign roles to individual files

Why it fails: IAM roles are granted at lake, zone or asset level, never per file; file-level control comes from Cloud Storage IAM or BigQuery row and column policies. Per-file roles are tempting because object storage does support fine-grained ACLs, but Dataplex itself exposes no file-level permission model.

Desktop-based processing

Why it fails: Dataflow runs on Google-managed workers in the cloud; desktop-based processing contradicts its distributed, autoscaling execution model. Production readiness requires the pipeline to run serverlessly on Dataflow workers. Desktop processing suits local DirectRunner testing only, not production deployment.

Manual refreshes

Why it fails: Manual refreshes introduce human-triggered, non-deterministic pipeline runs, whereas production pipelines require scheduled or event-driven execution with monitoring and retries. Manual triggering is tempting because it suits one-off backfills or exploratory jobs, not the repeatable, automated processing the scenario demands.

A parameter control to adjust the date granularity.

Why it fails: A parameter control allows users to change a parameter value, which can be used in calculated fields or queries, but it does not directly filter data by date range. While parameters can enable dynamic behavior, they are not a substitute for a date range control that filters the data. This does not provide the required date range filtering.

A chart-level filter on each chart for product category.

Why it fails: Chart-level filters are static and cannot be changed by viewers. They do not provide interactive filtering, so users would not be able to select different product categories. This approach fails to meet the requirement for interactive exploration and would require manual editing for each change.

A data control to switch between different data sources.

Why it fails: A data control changes the underlying data source for charts, which is not the same as filtering by product category or date range. It does not provide a way to interactively filter the existing data; instead, it swaps datasets. This does not meet the requirement for filtering by category and date.

Use ML.TRAINING_INFO to inspect the iteration history of the model's training run.

Why it fails: ML.TRAINING_INFO shows metrics per training iteration, such as loss over time, which helps diagnose convergence and overfitting during training. It does not provide final evaluation metrics on held-out data or feature-level explanations for predictions. The team needs post-training assessment and interpretability, which this function alone does not deliver.

Use ML.GENERATE_EMBEDDING to convert customer records into vector embeddings for similarity search.

Why it fails: ML.GENERATE_EMBEDDING creates vector embeddings using a remote model such as a text embedding model, which is useful for semantic search and clustering. It does not evaluate a supervised churn model's accuracy or explain its predictions. Applying it here would add an unrelated transformation rather than answering the quality and interpretability questions.

Use ML.FEATURE_INFO to list the summary statistics of each feature column used during training.

Why it fails: ML.FEATURE_INFO returns descriptive statistics about the columns used to train a model, such as min, max, and mean values. It describes the input data rather than the model's predictive quality or the influence of features on individual predictions. The team would learn about data distributions but not how well the model performs or why it made a given prediction.

A local database client like DBeaver

Why it fails: DBeaver speaks JDBC to relational databases, whereas Dataplex is accessed through the Google Cloud console, gcloud CLI, REST API and client libraries. DBeaver is tempting because Dataplex does surface BigQuery tables, but those are queried through BigQuery tooling, not a generic database client.

Text editor for configuration files

Why it fails: Dataplex has no configuration-file format for a text editor to edit; lakes, zones and assets are defined through the console, gcloud CLI, REST API or Terraform. A text editor is tempting because Terraform and YAML-based infrastructure-as-code genuinely configure Dataplex, but the editor alone is not an interface.

A standard SSH client

Why it fails: Dataplex exposes no SSH endpoint; administration runs through the console, gcloud CLI, REST API and client libraries. An SSH client is tempting because it is the standard route into Compute Engine VMs, but Dataplex is a fully managed service with no shell to connect to.

Users must provide a password for each asset

Why it fails: Dataplex inherits Cloud IAM identities and permissions; it never prompts for per-asset passwords, so this claim is false. It is tempting because some standalone catalogues do store per-source credentials, and that model would apply only to a tool managing its own external connections rather than Google Cloud resources.

Dataplex ignores existing storage permissions

Why it fails: Dataplex layers IAM and lake-level policies on top of Cloud Storage and BigQuery permissions, which remain enforced, so it cannot ignore them. The claim tempts because Dataplex centralises access control, and a governance product would legitimately override source permissions only when it fully proxies and owns the underlying data.

Dataplex provides its own authentication system

Why it fails: Dataplex delegates authentication entirely to Google Cloud Identity and IAM; it has no separate identity store or sign-in mechanism. The claim tempts because a data governance layer appears self-contained, and a dedicated authentication system would be the right design for a third-party catalogue hosting its own user accounts.

Network cable installation

Why it fails: Orchestration patterns coordinate task dependencies, scheduling, retries, and data movement between systems; physical cabling is infrastructure provisioning handled by network teams. It is tempting because pipelines depend on connectivity, but cabling is a prerequisite, not an orchestration step.

Hardware provisioning

Why it fails: Hardware provisioning is an infrastructure capacity task performed outside orchestration; pipelines orchestrate extraction, transformation, loading and dependency scheduling across services. It is tempting because pipelines ultimately run on compute, but provisioning is handled by capacity planning or infrastructure-as-code, not by the orchestration pattern itself.

Calculated field

Why it fails: A calculated field is a formula that creates a new metric or dimension based on existing data, but it does not provide interactivity for viewers. It is defined at design time and cannot be changed by viewers to filter or adjust the report dynamically. It does not meet the requirement for interactive controls.

Scorecard with conditional formatting

Why it fails: A scorecard displays a single metric and can use conditional formatting to highlight values, but it is not interactive. Viewers cannot use it to change date ranges or filter by region. It is a static visualization element and does not provide the required dynamic filtering capabilities.

Data blending

Why it fails: Data blending combines data from multiple sources in a single chart, which is useful for joining datasets, but it does not add interactivity for viewers. It is a backend data transformation step and does not allow viewers to change date ranges or filter by region dynamically. It is not a control.

Increase the data freshness setting to 24 hours to reduce the number of queries.

Why it fails: Increasing data freshness reduces how often the report refreshes, but it does not speed up individual queries or filter interactions. The slowness is due to query execution time, not refresh frequency. This change would make data staler without addressing performance.

Extract the data into a Looker Studio extract and schedule daily refreshes.

Why it fails: Extracts can improve performance for small datasets, but for billions of rows, the extract may be too large or exceed limits. Extracts also become stale and are not suitable for real-time or frequently updated data. This is not a scalable solution for a large BigQuery table.

Add more filters to the report to narrow down the data before charts load.

Why it fails: Adding more filters can actually increase complexity and may not improve load time if the filters themselves require scanning large amounts of data. It also burdens users with more interactions. The root cause is query performance, not lack of filters.

Switch the data source to the Google Sheets connector and import the BigQuery results into a spreadsheet first.

Why it fails: Routing millions of rows through Google Sheets hits the spreadsheet cell limit and adds a manual refresh step that undermines freshness. Sheets is also slower to query than BigQuery for large datasets, so rendering would not improve. The connector change introduces a fragile intermediate layer without removing the root cause, which is the volume of rows reaching the report.

Increase the number of rows returned by editing the BigQuery connector's maximum row setting in the data source configuration.

Why it fails: The row cap in the BigQuery connector is a fixed platform limit, not a tunable preference, so there is no supported setting that raises it. Attempting to work around it by splitting the data into many data sources complicates the report without solving the underlying volume problem. The correct strategy is to reduce rows through aggregation or to cache results with an extract.

Add more chart types to the report page so Looker Studio distributes the query load across multiple visualizations.

Why it fails: Each additional chart issues its own query and consumes its own share of the row budget, so adding visualizations increases load rather than distributing it. More charts also lengthen page render time and can trigger further row-limit errors. Reducing the data volume returned per query is what actually addresses both the error and the performance complaint.