ExamworthyExamworthy
Open the appStart free

PDE - Designing Data Processing Systems - Section 1.3

Design for flexibility and portability, mapping business requirements to architecture, enabling multi-cloud data portability, and managing data cataloguing and profiling.

Map business requirements to a data architecture that uses Dataplex Catalog for unified metadata and BigLake for multi-cloud storage access, and choose portability patterns that allow data to move between clouds without vendor lock-in.

Dataplex CatalogBigLakeMulti-cloud portability

Practice question for this objective

Free sampleDesigning Data Processing Systemsmedium

A multinational insurer must consolidate analytics across AWS S3, Azure Data Lake Storage, and Google Cloud Storage, with BigQuery as the primary query engine for finance teams. Leadership requires that analysts use a single SQL surface, that storage stays on each cloud to avoid egress, and that fine-grained access is enforced uniformly. Which architecture choice best maps these business requirements to a portable, multi-cloud-friendly design?

  • ASchedule nightly Storage Transfer Service jobs to copy all AWS and Azure data into a single Cloud Storage bucket, then load it into a BigQuery dataset and grant IAM dataset roles to all analysts.
  • BDeploy a self-managed Trino cluster on Compute Engine with connectors to each cloud's object store, and rely on connector-level access control lists configured per region.
  • CMaterialise each cloud's data into per-region BigQuery datasets through Dataflow pipelines and let analysts query the regional dataset that matches their reporting need.
  • DUse BigQuery Omni with BigLake tables backed by data in S3 and Azure Data Lake Storage, query them through BigQuery, and govern access with policy tags managed in Dataplex. Correct
Map a multi-cloud analytics requirement to BigQuery Omni with BigLake and Dataplex governance so storage stays in place while SQL access is unified. BigQuery Omni provisions BigQuery compute inside AWS and Azure regions and queries BigLake tables that point at S3 and Azure Data Lake Storage, so the bytes never leave their origin cloud. Combined with Dataplex policy tags, this delivers one SQL surface and consistent column-level controls without forcing data movement or bespoke clusters.

Why A is wrong: Bulk copying every dataset into Google Cloud violates the explicit requirement to keep storage on each cloud to avoid egress, and dataset-level IAM cannot deliver the uniform fine-grained access the brief demands.

Why B is wrong: Self-managed Trino can federate across clouds and is tempting, but per-connector ACLs do not give a unified governance model, and operating the cluster increases toil rather than mapping cleanly to the single SQL surface the business asked for.

Why C is wrong: Building Dataflow pipelines per source duplicates data into Google Cloud and forces analysts to pick the right dataset, which contradicts both the keep-data-in-place requirement and the single SQL surface goal.

Why D is correct: BigQuery Omni runs BigQuery compute in AWS and Azure regions over BigLake external tables, so data stays in place across clouds while analysts use one BigQuery SQL surface, and policy tags propagated through Dataplex enforce column-level access uniformly.

See more PDE practice questions, answers explained.

More in this domain

Back to all Designing Data Processing Systems objectives, or the PDE cert hub.

Examworthy is not affiliated with or endorsed by Google Cloud. Original, blueprint-aligned practice material only.