5 exercises — choose the best-structured answer to common Data Platform Architect interview questions. Focus on lakehouse medallion architecture, Delta Lake vs Apache Iceberg trade-offs, data contracts and schema evolution, platform governance, and migrating legacy warehouses.
Structure for Data Platform Architect interview answers
Name the architectural pattern: medallion layers, lakehouse vs warehouse, open table format
Explain the trade-off mechanism: ACID on object storage, compaction strategy, time travel cost
Cover governance dimension: ownership model, schema registry, data contracts as interfaces
Communicate to consumers: explain platform choices in terms of data quality and query performance, not implementation
0 / 15 completed
1 / 15
The interviewer asks: "Explain the medallion architecture and walk me through when you would choose it over a traditional star-schema data warehouse." Which answer best covers the architectural trade-offs?
Option B correctly defines all three layers with their specific characteristics, explains the replayability and schema flexibility advantages, gives a concrete cost comparison, and provides decision criteria for choosing star schema vs medallion based on team skills, data volume, and governance requirements. Option A vaguely describes three databases without the key properties of each layer and makes an unsupported quality claim. Option C incorrectly claims medallion is Databricks-specific — it is an architecture pattern implementable on any lakehouse stack. Option D invents two additional layers (raw and platinum) that are not part of the standard medallion definition.
2 / 15
The interviewer asks: "Compare Delta Lake and Apache Iceberg as open table formats. In what scenarios would you choose one over the other?" Which answer demonstrates the deepest technical understanding?
Option B accurately describes the architectural differences (transaction log structure vs three-tier metadata), names specific features (Z-order, hidden partitioning, partition evolution), and gives concrete multi-engine and use-case decision criteria. Option A incorrectly attributes provider origins — Delta Lake is open-source from Databricks, Iceberg is an Apache project from Netflix/Apple — and the cloud provider advice is wrong (both run on all major clouds). Option C is wrong on the storage format — both formats support Parquet (and Iceberg also supports ORC and Avro, but so can Delta). Option D is wrong — both formats store data in columnar files (Parquet by default).
3 / 15
The interviewer asks: "What are data contracts and how do you implement them in a lakehouse architecture?" Which answer best covers the producer-consumer model?
Option B correctly defines data contracts as producer-consumer agreements, covers all four implementation layers (schema, semantic, quality, ownership), names concrete tooling (Great Expectations, Soda, dbt contracts, Glue Schema Registry), explains the breaking change versioning requirement, and connects the concept to data mesh data products. Option A confuses data contracts with legal/GDPR data processing agreements. Option C conflates data contracts with API schema validation — data contracts are broader and include quality SLOs and ownership, not just schema. Option D conflates data contracts with encryption key management.
4 / 15
The interviewer asks: "How do you design a data platform governance model that scales across dozens of domain teams without becoming a bottleneck?" Which answer best describes the federated approach?
Option B correctly articulates the federated governance with centralised standards model, names specific tooling (DataHub, OpenMetadata, Unity Catalog, Apache Ranger, OpenLineage), describes the platform team's role shift from gateway to enabler, and gives four concrete mechanisms (CI/CD contract enforcement, automated lineage, quality scoring, tiered classification). Option A describes exactly the centralised bottleneck the question asks how to avoid. Option C is an oversimplification — a single Hive Metastore addresses catalog consolidation but not governance policies, quality enforcement, or ownership models. Option D defers governance until damage is done; technical debt in data platforms (undocumented schemas, unclear ownership) compounds rapidly.
5 / 15
The interviewer asks: "Walk me through how you would migrate a legacy on-premises data warehouse to a lakehouse architecture with minimal disruption to existing consumers." Which answer best describes the migration strategy?
Option B correctly describes the strangler fig migration pattern with dual-write, shadow read validation, phased consumer migration, SQL compatibility layer, semantic reconciliation opportunity, and decommission criteria. It also identifies the three key risks (performance, access control, ELT logic) and gives a realistic timeline. Option A's big-bang weekend migration is high-risk and ignores data validation, consumer readiness, and semantic drift. Option C is not a technical architecture answer — it offloads responsibility and overstates automation tool capabilities for complex legacy warehouses. Option D uses a mandate-and-deadline approach that ignores consumer readiness and creates business disruption.
6 / 15
Sarah (Senior Data Engineer) posted this message to the #data-platform Slack channel: "Just ran some queries against the new Parquet tables. Performance is noticeably slower than when we were using CSVs. Anyone have any ideas?" Which of the following approaches would be MOST appropriate for Mark (Data Architect) to take next?
The key here is understanding that performance degradation with Parquet often stems from suboptimal table design or query optimization. Simply reverting to CSV isn't a solution; Mark needs diagnostic data to identify the root cause – likely issues like incorrect partitioning, inefficient column selection, or inadequate indexing. Option C is wrong because NoSQL isn't always appropriate for structured data and Option D ignores potential performance bottlenecks.
7 / 15
David, a Data Platform Engineer, is writing the description for a Pull Request to add a new data source – customer transaction logs – to the lakehouse. Which of the following statements BEST describes what should be included in his PR description?
PR descriptions for data platform changes should focus on *how* the new source integrates into the existing lakehouse. While schema details are important, the primary emphasis is on the ETL processes and how the transaction logs will be transformed and loaded into the target tables – this ensures clarity for reviewers and downstream consumers. Option A is too granular, Option B is overly vague, and Options C & D aren't directly relevant to describing a data integration change.
8 / 15
Emily (Data Governance Lead) is discussing the implementation of data quality rules for a new customer dimension table with the team. Which of the following approaches would be MOST effective in ensuring these rules are consistently enforced across all downstream consumers?
The most robust approach to data governance is centered around proactive validation. While monitoring (Option B) is crucial, it's reactive; centralized checks at ingestion prevent bad data from entering the system in the first place. Option C creates silos and inconsistencies, and Option D lacks accountability and control – a core tenet of effective data governance. Centralized validation ensures consistency across all downstream consumers.
9 / 15
John (Data Architect) is designing a data platform for a retail company with multiple product lines and geographic regions. He needs to ensure the platform can handle increasing data volumes and evolving business requirements. Which of the following architectural patterns would BEST support this scalability and flexibility?
For large, complex organizations with diverse data needs, a polyglot persistence approach is crucial for scalability and flexibility. Using different database technologies optimized for specific workloads – relational for transactional data, NoSQL for semi-structured data, object storage for raw files – allows the platform to adapt to changing requirements. A star schema (Option B) lacks the flexibility needed for evolving business needs and a monolithic design (Option A) is inherently less scalable.
10 / 15
Lisa (Data Engineer) is tasked with migrating an existing on-premises data warehouse to a lakehouse architecture. She needs to minimize disruption to existing reporting and analytics applications that rely on the data warehouse. Which of the following migration strategies would be MOST appropriate?
A phased migration minimizes risk and disruption. By migrating subsets of data and transitioning users incrementally, Lisa can validate the new architecture, train users on the new tools, and address any issues before fully adopting the lakehouse. A complete rewrite (Option A) is costly and time-consuming, Option B is too slow, Option C is reckless, and Option D is almost guaranteed to fail.
11 / 15
Sarah (Senior Data Engineer) posted this message to the #data-platform Slack channel: "Just ran some queries against the new Parquet tables. Performance is noticeably slower than when we were using CSVs. Anyone have any ideas?" Which of the following approaches would be MOST appropriate for Mark (Data Architect) to take next?
The key here is understanding that performance degradation with Parquet often stems from suboptimal table design or query optimization. Simply reverting to CSV isn't a solution; Mark needs diagnostic data to identify the root cause – likely issues like incorrect partitioning, inefficient column selection, or inadequate indexing. Option C is wrong because NoSQL isn't always appropriate for structured data and Option D ignores potential performance bottlenecks.
12 / 15
David, a Data Platform Engineer, is writing the description for a Pull Request to add a new data source – customer transaction logs – to the lakehouse. Which of the following statements BEST describes what should be included in his PR description?
PR descriptions for data platform changes should focus on *how* the new source integrates into the existing lakehouse. While schema details are important, the primary emphasis is on the ETL processes and how the transaction logs will be transformed and loaded into the target tables – this ensures clarity for reviewers and downstream consumers. Option A is too granular, Option B is overly vague, and Options C & D aren't directly relevant to describing a data integration change.
13 / 15
Emily (Data Governance Lead) is discussing the implementation of data quality rules for a new customer dimension table with the team. Which of the following approaches would be MOST effective in ensuring these rules are consistently enforced across all downstream consumers?
The most robust approach to data governance is centered around proactive validation. While monitoring (Option B) is crucial, it's reactive; centralized checks at ingestion prevent bad data from entering the system in the first place. Option C creates silos and inconsistencies, and Option D lacks accountability and control – a core tenet of effective data governance. Centralized validation ensures consistency across all downstream consumers.
14 / 15
John (Data Architect) is designing a data platform for a retail company with multiple product lines and geographic regions. He needs to ensure the platform can handle increasing data volumes and evolving business requirements. Which of the following architectural patterns would BEST support this scalability and flexibility?
For large, complex organizations with diverse data needs, a polyglot persistence approach is crucial for scalability and flexibility. Using different database technologies optimized for specific workloads – relational for transactional data, NoSQL for semi-structured data, object storage for raw files – allows the platform to adapt to changing requirements. A star schema (Option B) lacks the flexibility needed for evolving business needs and a monolithic design (Option A) is inherently less scalable.
15 / 15
Lisa (Data Engineer) is tasked with migrating an existing on-premises data warehouse to a lakehouse architecture. She needs to minimize disruption to existing reporting and analytics applications that rely on the data warehouse. Which of the following migration strategies would be MOST appropriate?
A phased migration minimizes risk and disruption. By migrating subsets of data and transitioning users incrementally, Lisa can validate the new architecture, train users on the new tools, and address any issues before fully adopting the lakehouse. A complete rewrite (Option A) is costly and time-consuming, Option B is too slow, Option C is reckless, and Option D is almost guaranteed to fail.
What does "Data Platform Architect — Interview Questions — Best-Answer Practice" cover?
Practice answering Data Platform Architect interview questions in professional English. 5 exercises on medallion architecture, Delta Lake vs Iceberg, data contracts, platform governance, and lakehouse migration.
How many questions are in this interview set?
This set has 15 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.