PDE - Designing Data Processing Systems (22% of the exam) - 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.

Exam traps in Designing Data Processing Systems

Answers that look right on this material and are not. Each one is a distractor from a different question in the PDE bank for this domain.

Run nightly Storage Transfer Service jobs to bring the S3 and Azure Parquet into a Cloud Storage bucket, then create BigQuery external tables over the copied files.
Why it is wrong: Copying the Parquet into Cloud Storage is tempting because it simplifies querying, but it directly breaks the contractual residency commitment that the data must not leave its origin cloud, so it cannot be part of the answer.
BigLake, because it presents Cloud Storage, Amazon S3, and Azure Data Lake Storage Gen2 objects as governed tables and therefore acts as the unified discovery and search layer across clouds.
Why it is wrong: BigLake is tempting because it does reach across Cloud Storage, Amazon S3, and Azure Data Lake Storage Gen2, but its role is to expose external object data as queryable tables with fine-grained access control, not to provide cross-source search, tagging, lineage, or a marketplace experience.
Stand up three independent Dataplex lakes, one per cloud, and link them by exporting and re-importing entry groups nightly so each lake stays aware of the other catalogues.
Why it is wrong: Tempting because per-cloud lakes feel naturally aligned to storage, but nightly export and re-import gives a stale, fan-out view rather than a single catalogue and complicates glossary consistency.

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