Practice Exams for Google's Data Practitioner Associate Certification

A business intelligence developer at Blue Harbor Retail needs to design a performance dashboard that tracks sales across five regions and seven product lines. Which layout approach will most effectively let executives grasp key results at a glance and then investigate specific regions or categories when needed?

• ❏ A. Arrange a grid of pie charts to compare regional sales and category mix

• ❏ B. Place every metric and dimension in one exhaustive table on a single page

• ❏ C. Begin with summary KPIs then offer drilldowns to progressively reveal detail

• ❏ D. Cloud Pub/Sub

Which Google Cloud services provide a reliable event driven pipeline to ingest clickstream events and stream them into BigQuery with near real time visibility within four seconds?

• ❏ A. Pub/Sub and Cloud Run

• ❏ B. Pub/Sub plus Dataflow

• ❏ C. BigQuery Data Transfer Service and Cloud Storage

• ❏ D. Eventarc and Cloud Run

A data analytics group at scrumtuous.com is choosing between Looker and Looker Studio for business reporting across eight departments. They plan to standardize 120 core metrics and want consistent definitions with controlled changes using reviewable code. Which consideration would most strongly point them to Looker?

• ❏ A. Need to build ad hoc one time dashboards quickly

• ❏ B. Access to a no cost tier for individual analysts

• ❏ C. A mandate to manage reusable data models and metrics in Git with governed development workflows

• ❏ D. Preference to connect directly to Google Analytics and Google Ads without upfront modeling

Which Google Cloud service lets you run Apache Spark batch jobs without managing clusters or scaling?

• ❏ A. Dataflow

• ❏ B. Google Kubernetes Engine

• ❏ C. Dataproc Serverless for Spark

Apex Freight Services needs to migrate about 30 TB covering seven years of shipment history from its on premises analytics warehouse into BigQuery to run trend analysis and demand forecasting. The team wants a fully managed approach that can run on a recurring schedule and adapt to changes in the volume of data over time. Which Google Cloud service should they choose?

• ❏ A. Cloud Storage Transfer Service

• ❏ B. BigQuery Data Transfer Service

• ❏ C. Manual CSV uploads to Cloud Storage

• ❏ D. Cloud Data Fusion

Which Cloud Storage feature automates moving objects to Archive after 270 days of no access and deletes them after 5 years of inactivity?

• ❏ A. Bucket retention policy of 5 years

• ❏ B. Lifecycle rule to Archive after 270 days and delete after 5 years

• ❏ C. Lifecycle rule to Coldline after 270 days and delete after 5 years

A retail analytics team at scrumtuous.com streams click and purchase events into a BigQuery table and wants to run an aggregate query on this incoming data on a fixed cadence and write the results into a separate reporting table. The job must execute automatically every 30 minutes and the reporting rows must be retained for 10 days and then automatically removed. What should the team implement to satisfy these requirements?

• ❏ A. Create a BigQuery materialized view on the streaming table and set a view expiration of 10 days

• ❏ B. Build a Cloud Composer DAG that runs every 30 minutes to execute the BigQuery query and a cleanup task that deletes rows older than 10 days

• ❏ C. Set up a BigQuery scheduled query to run every 30 minutes that writes into a date partitioned destination table and configure a partition expiration of 10 days

• ❏ D. Use Cloud Scheduler to trigger a BigQuery job every 30 minutes and set a table expiration of 10 days on the destination table

Which Cloud Storage file format best compresses, supports schema evolution, performs efficiently, and integrates well with BigQuery for archiving five years of time series data?

• ❏ A. JSON

• ❏ B. Apache Parquet

• ❏ C. Apache Avro

• ❏ D. CSV

A national insurer named Northwind Mutual is moving medical claims records into Google Cloud and must meet HIPAA requirements and internal privacy standards. The security team needs encryption at rest and strict control over who can read the records. Which actions should the organization take to protect the data and remain compliant? (Choose 2)

• ❏ A. Enable VPC Flow Logs and export them to BigQuery for monitoring

• ❏ B. Use Cloud KMS with customer managed keys to encrypt data at rest

• ❏ C. Disable Cloud Logging to prevent sensitive fields from being captured

• ❏ D. Configure IAM with least privilege for datasets and Cloud Storage objects

• ❏ E. Make the Cloud Storage bucket public so any analyst can access it

Which service provides a shared Jupyter workspace with enterprise governance and native Google Cloud integration for collaborative analysis of large BigQuery datasets?

• ❏ A. Vertex AI Workbench

• ❏ B. Colab Enterprise

• ❏ C. Google Colab Free

All questions are from my GCP Data Practitioner Udemy course and certificationexams.pro

A data team at Riverstone Outfitters ingests about 30 TB of raw clickstream logs each day into Cloud Storage and BigQuery is the destination for analytics. The team must run extensive and compute heavy transformations on this data at scale. Which data integration pattern should they adopt to best leverage the target system for these transformations?

• ❏ A. ETLT

• ❏ B. Dataflow streaming pipelines

• ❏ C. ELT

• ❏ D. ETL

Which Cloud Storage encryption method gives customer controlled key rotation every 60 days and detailed key usage audit logs for compliance?

• ❏ A. Google managed encryption keys

• ❏ B. Cloud Storage CMEK via Cloud KMS

• ❏ C. Cloud External Key Manager

You are building a Looker dashboard for a national retail chain to monitor store visits and sales conversion at different branches. Business leaders want to slice the metrics by month and by store location and they also want an easy way to share links to specific filtered views that address targeted questions. What approach will best satisfy these needs?

• ❏ A. Publish embedded dashboards with a separate preset view for each store to streamline access for branch managers

• ❏ B. Build one dashboard with dashboard level filters for month and location and save and share filter presets or links for each branch

• ❏ C. Use Connected Sheets with BigQuery and share filtered spreadsheets per store

• ❏ D. Design a LookML dashboard with custom month and location filters and instruct users to adjust the filters manually whenever they share a view

How should you ingest JSON logs from Cloud Storage into BigQuery so you can keep the raw JSON and query selected nested fields without building separate pipelines?

• ❏ A. Dataflow template to parse and load to BigQuery

• ❏ B. Cloud Functions to parse and write to BigQuery

• ❏ C. Store raw JSON in BigQuery and query fields with BigQuery JSON functions

• ❏ D. Dataproc Serverless Spark to flatten and load tables

Aurora Capital must retain security event logs in Cloud Storage for regulatory purposes for 8 years, and the records are only read once each year during a scheduled compliance review. Which storage class will minimize ongoing storage cost for this access pattern?

• ❏ A. Coldline Storage

• ❏ B. Archive Storage

• ❏ C. Autoclass

• ❏ D. Nearline Storage

Which Google Cloud service provides managed scheduling and end to end orchestration for a workflow that runs every 30 minutes and sends failure notifications?

• ❏ A. Workflows

• ❏ B. Cloud Composer

• ❏ C. Cloud Run Jobs

• ❏ D. Cloud Scheduler

You are building a data solution for a nationwide restaurant chain that captures order events from point of sale POS terminals in 125 dining locations. The operations team needs near real time revenue visibility in BigQuery and analysts also need a nightly backfill of 12 years of historical orders from an on premises PostgreSQL system. You plan to stream events into the BigQuery table bq_sales_events_live within the dataset fin_analytics and you will schedule daily batch loads for history. Which Google Cloud service can efficiently support both the streaming ingestion and the batch processing with a single pipeline?

• ❏ A. Pub/Sub

• ❏ B. Cloud Dataflow

• ❏ C. Storage Transfer Service

• ❏ D. BigQuery Data Transfer Service

Which BigQuery function calculates a nine month rolling average per subscriber using an analytic window over calendar months?

• ❏ A. COUNTIF

• ❏ B. LAST_VALUE

• ❏ C. AVG

• ❏ D. SUM

MeridianPay is creating a Cloud Storage bucket to hold confidential payroll exports for 90 days and wants only a small set of payroll administrators to read and write while blocking access for everyone else in the organization. Which access configuration should be applied to the bucket to meet this need?

• ❏ A. Use object ACLs and set permissions on each file in the bucket

• ❏ B. Turn on uniform bucket level access and grant only the required users IAM permissions on the bucket

• ❏ C. Create a VPC Service Controls perimeter for the project and leave the bucket with default access

• ❏ D. Grant allAuthenticatedUsers access to the bucket

In Colab Enterprise how can you interactively analyze a 150 GB BigQuery table without loading it all into memory?

• ❏ A. Use Dataproc to preaggregate and export a smaller file to Cloud Storage

• ❏ B. Use BigQuery queries to fetch filtered columns and rows into Pandas

• ❏ C. Enable High-RAM runtime in Colab Enterprise

• ❏ D. Use BigQuery Storage API to download the full table

The correct choice is Begin with summary KPIs then offer drilldowns to progressively reveal detail.

This approach supports executive needs by presenting an at a glance overview through top level KPIs for total sales and key trends. It then enables progressive disclosure so leaders can click or navigate to view details for specific regions or product lines only when they need them. This keeps the dashboard simple and scannable while still providing a clear path to deeper analysis of the five regions and seven categories.

Arrange a grid of pie charts to compare regional sales and category mix is not effective for quick comparison because pie charts make it hard to compare values across many slices and multiple pies. A grid of pies is visually busy and does not provide a concise overview or an obvious path to deeper exploration.

Place every metric and dimension in one exhaustive table on a single page overwhelms viewers and slows comprehension. Large dense tables are difficult to scan for key results and they work poorly for executive summaries where immediate insight is required.

Cloud Pub/Sub is a messaging and event ingestion service and is not a dashboard layout technique. It does not address how to present KPIs or enable drilldown for business users.

When choosing dashboard layouts, favor overview first with clear KPIs and then progressive disclosure through drilldowns or interactions. Ask yourself whether an executive can grasp the story in seconds and then easily explore details.

The correct option is Pub/Sub plus Dataflow.

This pairing is designed for reliable event driven ingestion at scale. Pub/Sub provides durable low latency message ingestion with at least once delivery and high throughput. Dataflow runs a managed streaming pipeline that can autoscale, checkpoint, and provide exactly once processing when writing to BigQuery using the Storage Write API. With streaming sinks and the Storage Write API, Dataflow can achieve seconds level visibility in BigQuery which satisfies a near real time target of about four seconds.

Pub/Sub and Cloud Run is not ideal for this requirement because Cloud Run handles request driven containers and lacks the built in streaming transformations, checkpointing, and windowing that Dataflow provides. While you could push rows into BigQuery from Cloud Run, sustaining very high throughput with consistent low latency and strong delivery guarantees is harder to achieve and operate.

BigQuery Data Transfer Service and Cloud Storage is incorrect because the Data Transfer Service is for scheduled or managed batch transfers rather than continuous event streams. Writing files to Cloud Storage and loading them into BigQuery introduces batch latency that does not meet near real time visibility in a few seconds.

Eventarc and Cloud Run is not the right fit because Eventarc routes Cloud events to services such as Cloud Run but it is not a streaming data processing service, and this combination lacks native streaming connectors and transforms into BigQuery with second level latency at scale.

When you see near real time and event driven for BigQuery, look for a streaming pattern with Pub/Sub for ingestion and a managed streaming engine like Dataflow writing through the BigQuery Storage Write API. Be cautious of batch services such as the Data Transfer Service because they usually cannot meet second level latency.

The correct option is A mandate to manage reusable data models and metrics in Git with governed development workflows.

This points to Looker because LookML provides a centralized semantic model where metrics are defined once and reused across dashboards and departments. Looker integrates natively with Git which enables version control, code review, and controlled promotion of changes so teams can standardize 120 metrics and evolve them with a clear development workflow. This governance reduces metric drift and ensures consistent definitions across eight departments.

Need to build ad hoc one time dashboards quickly aligns better with Looker Studio since it excels at rapid self service visualization. Looker typically expects modeled data and a review process which is not ideal for quick one offs.

Access to a no cost tier for individual analysts points to Looker Studio which has a free offering. Looker is an enterprise product and this consideration does not indicate a Looker fit.

Preference to connect directly to Google Analytics and Google Ads without upfront modeling is characteristic of Looker Studio with its native connectors. Looker emphasizes modeling and governed semantics rather than direct connector driven exploration.

Look for words like governed, Git, and reusable metrics to choose Looker. Look for quick dashboards, no cost, and direct connectors to choose Looker Studio.

The correct option is Dataproc Serverless for Spark.

It lets you run Apache Spark batch jobs without provisioning or managing clusters. You submit jobs and the platform handles autoscaling, infrastructure, and resource management. This provides a true serverless experience and you pay only for the resources consumed during execution.

Dataflow is designed for Apache Beam pipelines rather than native Spark. It does not run Spark jobs directly and would require building workloads with the Beam SDK.

Google Kubernetes Engine can run Spark with additional setup, but you must manage the cluster lifecycle and scaling and often add operators to orchestrate jobs. This is not a serverless experience for Spark batch processing.

Match the phrase run Spark without managing clusters to the serverless Spark service. Differentiate Apache Spark on Dataproc from Apache Beam on Dataflow to avoid traps.

The correct choice is BigQuery Data Transfer Service because it provides a fully managed way to schedule recurring data loads into BigQuery and it automatically adjusts to changing data volumes over time.

This service lets you set up scheduled batch loads into BigQuery with minimal operations overhead. It can orchestrate transfers from landing zones such as Cloud Storage or supported external sources and then load the data into BigQuery on a reliable cadence. It is serverless and designed to scale for large historical loads like 30 TB as well as for ongoing incremental refreshes, which fits the migration and trend analysis needs in the scenario.

Cloud Storage Transfer Service focuses on moving objects between storage systems and into Cloud Storage. It does not load data into BigQuery by itself, so you would need additional jobs and orchestration to complete the pipeline, which is not the fully managed end to end BigQuery ingestion the team is asking for.

Manual CSV uploads to Cloud Storage are not a managed solution and do not provide dependable scheduling or scalability. This approach would be brittle and impractical at 30 TB and it would still require separate load steps into BigQuery.

Cloud Data Fusion is useful when you need to build and operate pipelines with complex transformations, yet it adds design and maintenance overhead. The requirement here is a simple, fully managed, scheduled ingestion into BigQuery, which is better met by the native transfer service.

When a question emphasizes a recurring schedule into BigQuery with fully managed operation, favor BigQuery Data Transfer Service. If the target is Cloud Storage, think Storage Transfer Service, and reserve Data Fusion for complex transformation pipelines.

The correct option is Lifecycle rule to Archive after 270 days and delete after 5 years.

Cloud Storage Object Lifecycle Management can automatically change storage classes and delete objects based on conditions such as the number of days since last access. You can configure one rule to set the storage class to Archive when an object has not been accessed for 270 days. You can add another rule to delete objects after approximately five years of no access. This fully automates the required transition and cleanup.

Bucket retention policy of 5 years is not correct because this setting only prevents object deletion before the configured period and it does not move objects to a colder class and it does not use last access as a condition. It would block deletions for five years regardless of activity and it would not automate the transition to Archive after 270 days.

Lifecycle rule to Coldline after 270 days and delete after 5 years does not satisfy the requirement because it moves objects to a different storage class than Archive. The requirement explicitly calls for Archive which is the coldest class designed for long term storage and is the correct target for the specified policy.

Map the requirement to the right feature. Use lifecycle rules for automated class transitions and deletions based on age or last access, and use retention policies only to enforce a minimum hold period that blocks deletion.

The correct option is Set up a BigQuery scheduled query to run every 30 minutes that writes into a date partitioned destination table and configure a partition expiration of 10 days.

This satisfies the need for automation because it can run every 30 minutes using a cron style schedule. Writing to a date partitioned table allows you to control retention by partition and setting a partition expiration of 10 days ensures rows older than ten days are automatically deleted by BigQuery. This uses native features and keeps the design simple and cost efficient.

Create a BigQuery materialized view on the streaming table and set a view expiration of 10 days is not appropriate because a view expiration deletes the view object rather than the underlying data and it does not provide per row retention. Materialized views also do not write results to a separate reporting table and their refresh behavior is driven by source changes rather than a precise every 30 minutes cadence. They may also not include the most recent streaming buffer data consistently.

Build a Cloud Composer DAG that runs every 30 minutes to execute the BigQuery query and a cleanup task that deletes rows older than 10 days adds unnecessary operational overhead compared to native scheduling and retention. Manual delete tasks are less reliable and can be more expensive than using partition expiration and you do not need a full workflow orchestrator for a single BigQuery query.

Use Cloud Scheduler to trigger a BigQuery job every 30 minutes and set a table expiration of 10 days on the destination table is incorrect because a table expiration removes the entire table based on its creation time instead of retaining a rolling ten day window. This would also require an intermediate service to call the BigQuery API which complicates the design without any benefit.

When you need periodic aggregation and time based retention in BigQuery prefer native features. Use scheduled queries for automation and partition expiration on partitioned tables for a rolling window, and avoid external orchestration when a single query suffices.

The correct option is Apache Avro.

It combines efficient binary compression with robust schema evolution that allows new fields with defaults while maintaining compatibility across years of appended records. It also integrates tightly with BigQuery for both loading from Cloud Storage and external tables and it preserves nested and repeated fields and precise timestamp types. BigQuery even uses this format for exports which makes long term archiving and later reingestion straightforward.

JSON is human readable text and lacks an enforced schema and it typically compresses poorly compared to binary formats and is slower for BigQuery to parse at scale, which makes it a poor choice for large archival datasets.

Apache Parquet offers excellent columnar compression and analytics performance and it is well supported by BigQuery, however it is optimized for columnar analytics rather than append oriented time series archives and its schema evolution model is more constrained, so it is not the best match when simple and flexible evolution over many years is the priority.

CSV provides no schema and suffers from quoting and type fidelity issues and it tends to produce larger files and slower ingestion, which makes it unsuitable for efficient long term storage and query.

Map the requirements to the format strengths. When you see schema evolution and native BigQuery support together, lean toward Avro. Prefer columnar formats when the focus is wide analytic scans.

The correct options are Use Cloud KMS with customer managed keys to encrypt data at rest and Configure IAM with least privilege for datasets and Cloud Storage objects.

Using customer managed keys gives the insurer control over key lifecycle which includes rotation and revocation and satisfies encryption at rest requirements that are common in HIPAA programs. This approach also enables separation of duties and detailed audit logs on key use which supports compliance and incident investigations.

Applying least privilege with Identity and Access Management ensures that only authorized personnel and service identities can read sensitive records. Scoping access at the dataset and object level and granting only the roles that are required enforces internal privacy standards and reduces the risk of unauthorized disclosure.

Enable VPC Flow Logs and export them to BigQuery for monitoring focuses on network telemetry and monitoring rather than protecting data at rest or enforcing read access to records. It does not meet the core requirements of encryption at rest or strict access control.

Disable Cloud Logging to prevent sensitive fields from being captured removes valuable audit trails that are important for compliance and security operations. You can control what is logged with field redaction and exclusions, so turning logging off is not an appropriate control for HIPAA workloads.

Make the Cloud Storage bucket public so any analyst can access it directly violates the principle of least privilege and would expose protected health information. Public access should never be used for sensitive medical data.

When you see compliance requirements such as HIPAA think in pairs which are encryption at rest and least privilege access. Prefer CMEK when customers require control of encryption keys and combine it with precise IAM scoping.

The correct option is Colab Enterprise.

It provides a shared Jupyter workspace that supports real time collaboration under organization level controls. It offers native Google Cloud integration through IAM based access, audit logging, VPC Service Controls, and centralized billing so teams can securely analyze large BigQuery datasets. It also includes streamlined access to BigQuery and features such as BigQuery DataFrames that make large scale analysis efficient while preserving enterprise governance.

Vertex AI Workbench focuses on managed and user managed notebook instances for machine learning development and it is typically oriented around per user or per project environments rather than a centrally shared Jupyter workspace with collaborative editing and enterprise governance as the primary goal.

Google Colab Free is intended for individual use and lacks organization level controls and native Google Cloud enterprise integration, so it is not designed for governed collaboration or for working with very large BigQuery datasets in an enterprise context.

Look for clues such as shared Jupyter workspace, enterprise governance, and native Google Cloud integration. These usually indicate Colab Enterprise rather than other notebook offerings.

The correct option is ELT because the team needs to push compute heavy transformations into the target analytics system and that system is BigQuery.

With ELT the team loads raw clickstream logs from Cloud Storage into BigQuery and then performs transformations using BigQuery’s distributed SQL engine. This pattern takes advantage of BigQuery’s scalable compute and storage so it efficiently handles tens of terabytes per day, minimizes data movement, and lets you orchestrate transformations with native tools such as Dataform while benefiting from features like partitioning and clustering.

ETLT is not a standard pattern and it implies doing transformations both before and after loading which adds unnecessary complexity and does not clearly prioritize the target system for heavy transformation work.

Dataflow streaming pipelines are optimized for continuous real time ingestion and event time processing. In this scenario the logs land in Cloud Storage and are processed daily which fits a batch workflow, and using streaming would not best leverage BigQuery for the core analytic transformations.

ETL performs transformations before loading into BigQuery which moves compute away from the destination and therefore does not meet the requirement to leverage the target system for transformations.

When a question says to leverage the target system for transformations and the destination is BigQuery, choose ELT. Reserve streaming pipelines for requirements that emphasize real time processing.

The correct option is Cloud Storage CMEK via Cloud KMS. This choice satisfies customer controlled key rotation every 60 days and provides detailed key usage audit logs to meet compliance needs.

With CMEK you own the key in Cloud KMS and you can configure an automated key rotation schedule such as 60 days. Cloud KMS integrates with Cloud Audit Logs so encrypt and decrypt operations are recorded with principal, resource and time which delivers the detailed key usage history auditors expect. Cloud Storage uses your CMEK for object encryption so usage of the key is consistently logged and you can also disable or revoke access if needed.

Google managed encryption keys do not allow you to set your own rotation schedule and Google controls when rotation occurs. You also do not get per key usage audit logs because the keys are fully managed by Google and are not exposed in Cloud KMS.

Cloud External Key Manager keeps keys outside Google and rotation would be handled in the external system rather than through Cloud KMS schedules. While it can provide strong control and request logging it does not natively give you Cloud KMS rotation every 60 days for Cloud Storage and it adds operational complexity that is unnecessary for this requirement.

When requirements mention customer controlled rotation on a specific schedule and detailed key usage audit logs think CMEK with Cloud KMS.

The correct option is Build one dashboard with dashboard level filters for month and location and save and share filter presets or links for each branch.

This approach lets you maintain a single source of truth while giving users the flexibility to slice by month and by location using dashboard filters. Looker preserves the filter state in the URL when you use the Share button or copy the link, so teams can easily share exactly the filtered view that answers a targeted question. It also scales well because you avoid duplicating dashboards for each branch and you keep definitions and visualizations consistent.

Publish embedded dashboards with a separate preset view for each store to streamline access for branch managers is inefficient because it creates many near duplicate dashboards to manage and it does not take advantage of simple link sharing with applied filters. It increases maintenance overhead and risks inconsistencies between versions.

Use Connected Sheets with BigQuery and share filtered spreadsheets per store does not meet the requirement for a Looker dashboard experience and it lacks the streamlined URL based sharing of interactive dashboard views. It also shifts users into spreadsheets rather than the governed Looker model.

Design a LookML dashboard with custom month and location filters and instruct users to adjust the filters manually whenever they share a view relies on manual steps that are error prone and unnecessary because Looker can share links that already capture the current filter state. It does not provide the easy sharing workflow that the business leaders requested.

When a question asks for flexible slicing and easy sharing, favor a single dashboard with dashboard level filters and leverage links that capture the current filter state rather than multiplying dashboards or asking users to adjust filters manually.

The correct option is Store raw JSON in BigQuery and query fields with BigQuery JSON functions. This lets you load the logs from Cloud Storage while preserving the original JSON and still query the nested attributes without creating and maintaining additional processing pipelines.

This approach uses BigQuery�s native JSON data type so you can ingest newline delimited JSON files and keep each record as a single JSON value. You can then use SQL functions such as JSON_VALUE, JSON_QUERY, JSON_EXTRACT, and JSON_EXTRACT_SCALAR to access only the fields you need. You can load with schema autodetect or define a table with a single JSON column and then build views for curated access while still retaining the raw payload.

Dataflow template to parse and load to BigQuery adds an unnecessary pipeline and transformation logic when the goal is to keep the raw JSON and only query selected fields. This increases complexity and can lead to loss of the original structure.

Cloud Functions to parse and write to BigQuery requires custom code and ongoing operations and it also violates the requirement to avoid separate pipelines. It is not ideal for high volume backfills from Cloud Storage.

Dataproc Serverless Spark to flatten and load tables focuses on flattening and producing transformed tables which does not preserve the raw JSON easily and introduces a pipeline that the scenario wants to avoid.

When a question stresses keeping raw data and avoiding extra pipelines, look for native features that let you query inside the raw format. In BigQuery this often means the JSON data type and its SQL functions.

The correct option is Archive Storage.

This class provides the lowest ongoing storage cost in Cloud Storage and is built for data that is rarely accessed. The minimum storage duration of one year aligns with an annual compliance review, and although retrieval has a cost, the infrequent access keeps total cost low over the eight year retention period.

Coldline Storage is intended for data accessed less than once per quarter and it has higher per‑GB storage cost than the archive class, so it would not minimize long‑term cost for data read only once a year.

Autoclass is a management feature and not a storage class. While it can transition objects among classes, it adds a management fee and is unnecessary when the access pattern is clearly long‑term archival.

Nearline Storage is designed for data accessed about once a month or less and it has higher storage cost than the archive class, so it is not optimal for annual reads over eight years.

Map the expected access frequency to the storage class. Choose Archive for yearly or rarer access, Coldline for quarterly, Nearline for monthly, and Standard for frequent access. If the question asks for a class, do not pick Autoclass since it is a management feature.

The correct option is Cloud Composer because it offers a fully managed way to both schedule and orchestrate workflows end to end and it can be configured to send failure notifications.

Cloud Composer is built on Apache Airflow, which lets you author pipelines and run them on a fixed cadence such as every 30 minutes with the built in scheduler. You can enable notifications on task failures through Airflow email alerts or integrate with Cloud Monitoring so the service covers both orchestration and alerting needs in one managed solution.

Workflows can orchestrate steps across Google Cloud services, yet it does not provide a native scheduler and typically depends on Cloud Scheduler to trigger executions at intervals. The question asks for one managed service that handles both scheduling and orchestration, which this option does not provide by itself.

Cloud Run Jobs is designed for running containerized batch tasks and it does not provide rich multi step orchestration or a built in scheduler, and failure notifications require additional tooling.

Cloud Scheduler provides reliable cron style scheduling, but it does not orchestrate multi step workflows and it does not send failure notifications on its own.

When a question asks for both managed scheduling and end to end orchestration in one place, think of services built on Airflow. If a service only orchestrates, pair it with a scheduler in your reasoning.

The correct option is Cloud Dataflow.

Cloud Dataflow uses the Apache Beam model which supports both streaming and batch in one pipeline or a shared codebase. You can stream order events into BigQuery with low latency using BigQuery I O or the BigQuery Storage Write API and you can run the same pipeline on a schedule to read historical data from PostgreSQL and load it into BigQuery. This lets operations see near real time revenue while analysts get a reliable nightly backfill without maintaining separate technologies.

Pub/Sub is a messaging service that publishes and subscribes to events and it does not perform end to end ETL or batch database backfills by itself. It cannot handle the nightly PostgreSQL history load or act as a single pipeline for both needs.

Storage Transfer Service automates file based transfers between storage systems such as moving data into Cloud Storage. It does not process event streams and it does not extract from PostgreSQL into BigQuery.

BigQuery Data Transfer Service runs scheduled batch loads from supported SaaS products and Cloud Storage into BigQuery. It does not provide streaming ingestion and it does not natively pull from on premises PostgreSQL.

When a question asks for a single pipeline that covers both streaming and batch into BigQuery, map that to Dataflow and Apache Beam. Match the service to the workload pattern before the source and sink details.

The correct option is AVG.

The average aggregate used as an analytic function is what computes a nine month rolling average per subscriber. You would define a window that partitions by subscriber and orders by calendar month, then frame it to include the current month and the prior eight months so the function returns the mean of the values within that window for each row.

COUNTIF counts rows that meet a condition and does not compute an average, so it cannot produce a rolling average by itself.

LAST_VALUE returns the final value in the window and does not calculate the mean across the window, so it would only return the most recent month’s value.

SUM adds values within the window and while you could divide a rolling sum by a rolling count to derive an average, this function alone does not calculate a rolling average as asked.

When you see a request for a rolling average with an analytic window, think of the average aggregate with an OVER clause, then partition by the key and order by time, and set a nine month window frame.

The correct option is Turn on uniform bucket level access and grant only the required users IAM permissions on the bucket.

This approach uses a single policy surface on the bucket so you control who can read and write through IAM and nothing else. It prevents object level permissions from bypassing your bucket policy which reduces misconfiguration risk and makes auditing simpler. You would grant only the payroll administrators the minimal roles they need on the bucket and ensure no broader permissions are inherited. The 90 day retention requirement is a separate concern that can be handled with lifecycle management or a retention policy and does not change the access choice.

Use object ACLs and set permissions on each file in the bucket is incorrect because per object ACLs are complex to manage and can lead to inconsistent access. With the recommended configuration, object ACLs are disabled, which is exactly what you want for strict control.

Create a VPC Service Controls perimeter for the project and leave the bucket with default access is incorrect because this product focuses on reducing data exfiltration risk across network boundaries and it does not replace IAM decisions on who can read or write. Leaving default access could still permit unintended access within the project or organization.

Grant allAuthenticatedUsers access to the bucket is incorrect because this identity includes any Google authenticated principal, which would expose the data far beyond the small set of payroll administrators.

When a question asks for strict control over who can access Cloud Storage data, look for uniform bucket level access paired with bucket scoped IAM and avoid ACLs or broad identities like allAuthenticatedUsers.

The correct answer is Use BigQuery queries to fetch filtered columns and rows into Pandas. This keeps the heavy work in BigQuery and moves only the needed subset into a Pandas DataFrame so the Colab Enterprise session stays within practical memory limits.

With this approach you use SQL in BigQuery to project only the required columns and to filter rows to the slice you want to explore. The result set is typically much smaller than the full 150 GB table. You then load that result into Pandas for interactive analysis, which preserves responsiveness while avoiding out of memory errors.

Use Dataproc to preaggregate and export a smaller file to Cloud Storage is not the best choice for interactive analysis because it adds batch preprocessing steps and file exports that slow iteration and increase complexity. You lose the simplicity of querying directly and only retrieving what you need on demand.

Enable High-RAM runtime in Colab Enterprise does not solve the core issue because trying to load a large table still risks exhausting memory. The right strategy is to reduce the data transferred by filtering and projecting in the warehouse rather than only increasing memory.

Use BigQuery Storage API to download the full table is incorrect because pulling the entire 150 GB table defeats the purpose of interactive analysis and will likely exceed memory. You should download only the filtered query results instead of the full dataset.

When a dataset is very large, favor options that push compute into BigQuery and return only a filtered and projected result set to your notebook. Be cautious of answers that pull the entire table or rely only on more RAM.