Microsoft Azure Data Fundamentals DP-900 (DP-900) — Questions 1–75

The first data type is a table with columns (CustomerID, Name, Email), which is structured, not unstructured. The second is JSON documents, which are semi-structured, not structured. The third is MP4 videos, which are unstructured, not semi-structured.

The order is incorrect because product reviews as JSON documents are semi-structured (not structured), and product demonstration videos are unstructured (not semi-structured). The correct order is structured (table), semi-structured (JSON), unstructured (video).

The order is incorrect: customer data in a table is structured, product reviews as JSON are semi-structured, and MP4 videos are unstructured. Option D reverses this order.

This option would be correct if the question presented data in a different order: first, product demonstration videos (unstructured), second, a table with columns (structured), and third, product reviews as JSON documents (semi-structured).

If the question listed data types as: (1) a JSON document with customer preferences, (2) a relational table of sales transactions, (3) a CSV file of inventory logs, then option B (semi-structured, structured, structured) would be correct because JSON is semi-structured, and both table and CSV are structured.

If the question listed data types in order as: (1) product demonstration videos (MP4), (2) product reviews (JSON), (3) customer table, then option D would be correct as Unstructured, semi-structured, structured.

Candidates may confuse the definitions of structured and semi-structured data, or misorder the data types due to a superficial understanding of data classification.

Candidates may confuse JSON as unstructured due to its flexible schema, or mistakenly think videos are semi-structured because they contain metadata, leading to a misordering of semi-structured and unstructured.

Candidates may confuse the classification of JSON documents as unstructured instead of semi-structured, or misorder the data types due to lack of clarity on the definitions.

This option is wrong because the question requires minimal downtime, and an offline migration over the weekend still involves downtime during the migration window. The table is actively written to during business hours, so even weekend migration may not be acceptable if the business operates beyond weekdays or requires near-zero downtime.

Exporting a 1 TB table as a .bacpac and importing it is an offline operation that requires the table to be idle, but the table is actively written to during business hours, causing data inconsistency and unacceptable downtime.

The 'Deploy Database to Azure SQL Database' wizard in SSMS performs an offline migration, which would cause significant downtime for the actively written Sales table. It does not support continuous sync to minimize downtime.

This option would be correct if the question specified that the migration can be performed during a scheduled maintenance window where downtime is acceptable, and the table is not actively used during that time. For example: 'A company needs to migrate a 1 TB Sales table to Azure SQL Database and can schedule a 48-hour maintenance window over the weekend with no business impact.'

A company needs to migrate a small, static database (e.g., < 20 GB) that is not being modified during migration, and they can afford several hours of downtime. The .bacpac export/import is simple and requires no additional services.

This option would be correct for a small, static database (e.g., < 50 GB) that can tolerate several hours of downtime, and when the goal is a simple one-time migration without ongoing replication.

Candidates may think that performing the migration over the weekend minimizes business impact and is simpler than setting up continuous sync. They might underestimate the requirement for minimal downtime or assume that weekend downtime is acceptable.

Candidates may think .bacpac is the standard Azure SQL migration tool and overlook the size and active-write constraints, assuming off-hours migration is sufficient.

Candidates may be familiar with SSMS and assume its built-in wizard is sufficient for any migration, overlooking the need for minimal downtime and continuous sync for large, active tables.

A clustered index on ShipmentID (the primary key) is already the default, but queries filter by CustomerID and ShipDate, not ShipmentID. This index does not support the filtering columns, so it won't improve performance for the specified queries.

Partitioning by ShipmentID does not help queries filtering by CustomerID and ShipDate because the partition key is not used in the WHERE clause, so all partitions must be scanned.

A full-text index on Destination is designed for text search (e.g., finding words or phrases in a string), not for filtering on exact values like CustomerID and ShipDate. It does not support range queries or equality filters efficiently, so it won't improve performance for the described queries.

If the question asked for the best indexing strategy when queries frequently filter by ShipmentID or need to retrieve a single shipment by its ID, then a clustered index on ShipmentID would be optimal, as it provides fast point lookups.

A question where the table is very large and queries frequently filter or aggregate by ShipmentID ranges, or where data needs to be managed (e.g., archiving old shipments) by ShipmentID ranges.

A full-text index on Destination would be correct if the question involved searching for shipments based on keywords or phrases in the destination column, such as 'Find all shipments to cities containing 'Springfield' or 'New York'.

Candidates may assume that indexing the primary key is always beneficial, or they may not realize that a clustered index on the primary key already exists by default, making this option redundant for the given query pattern.

Candidates may think partitioning always improves query performance for any filter, not realizing that the partition key must align with the query filter to be effective.

Candidates might think any index on a frequently queried column helps, or they may confuse full-text indexing with regular indexing, assuming it can speed up all types of queries on that column.

Customer information in a fixed-column SQL database is structured data, not unstructured. The files (PDFs, images) are unstructured, but the option incorrectly classifies both as structured.

Customer information in a fixed-column SQL database is structured data, not semi-structured. Semi-structured data has tags or markers (e.g., JSON, XML) without a rigid schema, which does not apply here.

This option would be correct if the question described customer information stored in a NoSQL database with flexible schema (like JSON documents) and the files as structured data (e.g., CSV files).

This option would be correct if the customer information were stored in a format like JSON or XML with variable fields (e.g., custom attributes per customer), making it semi-structured, while the PDFs and images remain unstructured.

Candidates may confuse 'structured' with 'organized' and think that because the files are stored in a system, they are structured, or they may not distinguish between structured and unstructured data types clearly.

Candidates may confuse 'semi-structured' with 'structured' because they think any database implies structure, but they overlook that semi-structured data lacks a fixed schema, unlike a SQL table with predefined columns.

OLTP (Online Transaction Processing) and OLAP (Online Analytical Processing) describe system architectures for transaction handling vs. analytics, not the data processing methods (batch vs. streaming) used in the scenario.

The question asks about data processing approaches (batch vs. streaming), not data types. 'Structured data and unstructured data' describe data formats, not how data is processed.

The question contrasts batch processing (nightly job) with streaming processing (real-time), not database types. Relational and NoSQL refer to data storage models, not processing approaches.

A question asks: 'A company uses a database for processing customer orders and a separate system for analyzing sales trends. Which pair of terms describes these two systems?' Then OLTP (for orders) and OLAP (for analytics) would be correct.

A question that asks: 'A company stores customer records in a SQL database and also collects social media posts. Which pair of terms describes these two data types?' would make 'Structured data and unstructured data' correct.

A question asks: 'A company uses a SQL database for transactional data and a document database for product catalogs. Which pair of terms describes these two data storage technologies?'

Candidates confuse the batch/streaming distinction with the OLTP/OLAP dichotomy, as both involve different processing types, but OLTP/OLAP focus on system purpose rather than processing timing.

Candidates may confuse data processing methods with data types, especially when the scenario involves both historical (structured) and real-time (potentially unstructured) data.

Candidates may confuse data processing approaches with data storage technologies, especially when terms like 'data warehouse' (often relational) appear in the question.

Azure Stream Analytics is optimized for real-time stream processing but cannot natively join streaming data with static historical data stored in Azure Data Lake Storage Gen2 for complex T-SQL queries. It lacks the ability to run ad-hoc T-SQL queries on combined datasets.

Azure Data Factory is an orchestration and ETL service, not an analytics platform. It cannot perform real-time stream processing or run T-SQL queries directly on combined streaming and batch data.

Azure Stream Analytics would be correct if the question required only real-time anomaly detection on the streaming sensor data without needing to join with historical records or run ad-hoc T-SQL queries. For example, a scenario where you need to filter or aggregate streaming data in real-time and output to a dashboard.

A question asks: 'Which service should be used to orchestrate the movement and transformation of data from multiple sources into a data warehouse for later analysis?' In that scenario, Azure Data Factory is the correct answer.

Candidates may think Stream Analytics is sufficient because it can process streaming data and has some reference data capabilities, but they overlook the need for complex T-SQL queries and integration with historical data in Data Lake Storage.

Candidates may think Data Factory can handle both streaming and batch data integration and assume it can also perform analytics, confusing its ETL capabilities with actual query processing.

This index does not include ProductID as the leading key, so queries filtering on both ProductID and SaleDate cannot seek on ProductID first; they may scan or seek on SaleDate only, missing the optimal key order for the query's filter.

A clustered index on (ProductID, SaleDate) would physically order the table by those columns, but the query selects only Quantity and UnitPrice, which are not included in the index key. This forces key lookups to retrieve those columns, reducing performance compared to a covering nonclustered index.

This index does not include SaleDate, so it cannot efficiently support the date range filter. The query would still need to scan all rows for the given ProductID to find those within the date range.

If the query filtered only on SaleDate (e.g., total Quantity and UnitPrice for all products over a date range), this index would be correct because it supports seeking on SaleDate and includes the needed columns.

If the query required all columns from the Sales table (e.g., SELECT *), a clustered index on (ProductID, SaleDate) would be optimal because it includes all columns without additional lookups. This is common in queries that retrieve full rows for reporting or analysis.

If the query only filters on ProductID (no date range) and selects Quantity and UnitPrice, this covering index would be optimal. For example: 'SELECT Quantity, UnitPrice FROM Sales WHERE ProductID = ?'

Candidates may think that since SaleDate is used in the filter, it should be the index key, overlooking that the query also filters on ProductID and that leading with ProductID is more selective.

Candidates may think a clustered index is always faster for range queries, or they may confuse the covering index concept, assuming that clustering on the filter columns automatically includes all data.

Candidates may think that filtering on ProductID alone is sufficient, overlooking the date range filter. They might also assume that including the selected columns makes the index covering, ignoring the missing filter column.

The question specifically asks about 'different formats of data,' which is the definition of variety. Volume refers to the amount of data, not its format.

The question specifically asks about the different formats of data (structured, semi-structured, unstructured), which is the definition of variety, not velocity. Velocity refers to the speed at which data is generated and processed.

Veracity refers to the trustworthiness or quality of data, not the different formats. The question specifically asks about the characteristic describing different data formats, which is Variety.

A question that asks: 'Which characteristic of big data describes the challenge of storing and processing terabytes of data from thousands of sensors?' would have Volume as the correct answer.

A question like 'A stock trading platform ingests real-time market data and must process trades within milliseconds. Which big data characteristic is most relevant?' would make velocity the correct answer.

Veracity would be correct in a question about data quality challenges, e.g., 'A data platform ingests data from multiple sources with inconsistent accuracy and missing values. Which big data characteristic is most relevant?'

Candidates may confuse the large amount of data from multiple sources with the concept of volume, not realizing the question focuses on format differences.

Candidates may confuse the high speed of data ingestion from multiple sources (like medical devices) with the concept of velocity, not realizing that the question focuses on data format differences.

Candidates may confuse Veracity with Variety because both start with 'V' and relate to data complexity, or they may think different formats imply data quality issues.

Azure Blob Storage does not support SMB protocol; it uses REST APIs for access, so the legacy application requiring SMB file shares cannot use it without modification.

Azure Queue Storage is a messaging service for asynchronous communication between application components, not a file share protocol. It does not support SMB protocol or provide a file system interface, so it cannot replace SMB file shares for the legacy application.

Azure Disk Storage provides block-level storage volumes for Azure VMs, not SMB file shares. It does not natively support the SMB protocol for file sharing, so the legacy application requiring SMB shares cannot use it without modification.

When a question asks for storing large amounts of unstructured data (e.g., images, videos, backups) accessible via HTTP/HTTPS, and the application can use REST APIs or SDKs, Azure Blob Storage is the correct choice.

Azure Queue Storage would be correct for a question about decoupling application components, such as when a web app needs to offload long-running tasks to a backend worker. The scenario would involve asynchronous message passing, not file sharing.

Azure Disk Storage is correct when the question specifies a need for persistent, high-performance block storage for a virtual machine, such as for a database or custom application that requires direct disk access via iSCSI or as a VM disk.

Candidates may confuse Blob Storage with file storage because both can store data, but they overlook the specific protocol requirement (SMB) in the question.

Candidates may confuse Azure Queue Storage with a storage option for data, or mistakenly think it can serve files because it is a type of Azure storage. The word 'queue' might be overlooked, focusing only on 'storage'.

Candidates may confuse Azure Disk Storage with file storage because both are used for storing data, or they might think that any Azure storage can support SMB if configured, but Disk Storage does not offer file-level sharing.

A clustered index on OrderID is already the primary key, so it exists by default. The query filters on CustomerID and OrderDate, not OrderID, so this index does not help with those filters.

The index on (OrderDate, TotalAmount) does not include CustomerID, which is a primary filter in the queries. Without CustomerID as a leading key, the index cannot efficiently narrow down rows for a specific customer, leading to scans rather than seeks.

If the query frequently searched for a specific order by OrderID (e.g., SELECT * FROM Orders WHERE OrderID = ?), then a clustered index on OrderID would be optimal for that point lookup.

If the query filters only on OrderDate and TotalAmount (e.g., finding orders with a total amount above a threshold within a date range), this index would be optimal as it directly supports both filter and potential covering.

Candidates may think a clustered index is always the best for performance, or they confuse the primary key index with being useful for all queries, not realizing it only helps when filtering on the key column.

Candidates may think any index on columns used in WHERE clause helps, but they overlook the importance of leading column order for multi-column filters, especially when one column (CustomerID) is highly selective.

Single database with provisioned throughput does not allow databases to share resources or minimize costs for unpredictable, spiky workloads across multiple databases. Each database is isolated with dedicated resources, leading to over-provisioning and higher costs.

Azure SQL Managed Instance is designed for lift-and-shift migrations requiring near 100% compatibility with on-premises SQL Server, but it does not support resource sharing across multiple databases via elastic pools, so it would not minimize costs for unpredictable, shared workloads.

SQL Server on Azure VM requires manual management of the OS and SQL Server, including patching and backups, which does not reduce management overhead. It also cannot share resources across databases to minimize costs like an elastic pool.

A single database with provisioned throughput is correct when a company has one large database (e.g., >500 GB) with predictable, steady-state usage and requires guaranteed performance isolation without sharing resources with other databases.

A company needs to migrate multiple on-premises SQL Server databases to Azure with minimal application changes, requiring features like SQL Agent, cross-database queries, and VNet integration, and is willing to pay for dedicated resources rather than sharing.

A company needs full control over the SQL Server environment, requires custom configurations or third-party software, or must lift-and-shift existing applications with minimal changes, and is willing to manage the VM.

Candidates may think 'single database' is simpler and cheaper, but they overlook the requirement for multiple databases to share resources and handle unpredictable spikes cost-effectively.

Candidates may confuse Managed Instance as a 'managed' option that reduces overhead, but overlook that it lacks elastic pool support and is more expensive for databases with variable usage that could share resources.

Candidates may think that migrating to a VM is the simplest lift-and-shift approach, overlooking the management overhead and the lack of resource sharing for cost optimization.

Order processing involves individual insert, update, and delete operations on customer orders, which are typical of transactional processing (OLTP), not batch processing. Batch processing handles large volumes of data in scheduled, offline batches, not real-time transactions.

Order processing involves frequent insert, update, and delete operations on individual records, which is characteristic of OLTP, not OLAP. OLAP is used for complex queries and aggregations on historical data, not for day-to-day transaction handling.

Order processing involves individual insert, update, and delete operations on customer orders, which are typical of transactional processing (OLTP), not stream processing. Stream processing handles continuous, real-time data flows (e.g., sensor data, clickstreams) and is not designed for discrete record-level transactions.

A question describing a scenario where a company processes end-of-month payroll for all employees by running a scheduled job that calculates salaries and generates pay slips in one go would make batch processing (option A) the correct answer.

A question describing a workload that runs complex queries on large volumes of historical sales data to identify trends, such as 'Which processing type is used for quarterly sales trend analysis?' would make OLAP correct.

Stream processing would be correct if the question described a scenario where the company needs to analyze real-time clickstream data from the e-commerce website to detect fraud or personalize offers as users browse, without storing each event as a persistent record.

Candidates may confuse batch processing with any data processing that occurs in groups, but the key distinction is that batch processing is scheduled and not real-time, whereas order processing here is continuous and interactive.

Candidates may confuse 'reports on sales trends' (which is OLAP) with the order processing itself, mistakenly thinking that because the company runs reports, the entire workload is analytical.

Candidates may confuse 'real-time' order processing with stream processing, not realizing that OLTP handles real-time transactions on persistent data, while stream processing deals with transient event streams without persistent storage.

Azure Data Factory is an ETL and data orchestration service, not a query engine. It cannot run SQL queries directly against data in the data lake; it moves or transforms data, which contradicts the requirement to avoid data movement and latency.

Azure Databricks is optimized for big data analytics and machine learning using Spark, but it is not the best choice for directly running complex SQL queries on Parquet files in Azure Data Lake Storage Gen2 without moving data, as it requires a Spark cluster and is more complex than a serverless SQL pool for ad-hoc SQL queries.

Azure HDInsight is a managed big data analytics service that requires provisioning clusters and is designed for batch processing with technologies like Spark, Hive, or MapReduce. It does not provide a serverless, on-demand SQL query interface over data in Azure Data Lake Storage Gen2 without moving data, unlike Azure Synapse Serverless SQL pool.

A company needs to ingest data from multiple sources into Azure Data Lake Storage Gen2 on a scheduled basis, performing transformations like filtering and aggregation before loading. The question would emphasize orchestration and data movement, not direct querying.

A company needs to perform advanced analytics, including machine learning and real-time data processing, on large datasets stored in Azure Data Lake Storage Gen2. They require a collaborative environment for data scientists and engineers to run custom code in Python, Scala, or SQL, and they are willing to manage cluster resources. In this scenario, Azure Databricks would be the correct answer.

A company needs to run custom MapReduce or Spark jobs on large datasets stored in Azure Data Lake Storage Gen2, and they require full control over cluster configuration, including specific versions of Hadoop, Spark, or Hive. They are willing to manage cluster lifecycle and pay for compute resources.

Candidates may confuse Data Factory's data integration capabilities with querying, or think it can perform SQL-like transformations on the fly, overlooking that it primarily orchestrates data pipelines rather than serving ad-hoc queries.

Candidates may choose Azure Databricks because it is a powerful analytics platform that can query data in data lakes, but they overlook that the question specifically asks for simple SQL queries and Power BI integration, where Synapse Serverless SQL pool is more straightforward and cost-effective.

Candidates may associate HDInsight with big data querying using Hive or Spark SQL, and mistakenly think it can directly query Parquet files in a data lake without data movement, overlooking the need for cluster provisioning and the serverless alternative.

Partitioning on email would not efficiently support the primary query (retrieving a user by userId) because queries on userId would require a cross-partition scan. Additionally, the query for users with 'PremiumVideo' subscription would also be a cross-partition query, as email is unrelated to the subscription data.

Partitioning on serviceName extracted from subscriptions array would cause most queries to be cross-partition, as retrieving a single user by userId would require fanning out across all partitions, and the query for users with 'PremiumVideo' subscription would still be a cross-partition query unless filtered by a specific partition key value.

A composite key on userId and serviceName would cause queries for a single user by userId to be cross-partition, as userId alone is not the partition key. Additionally, queries for users with 'PremiumVideo' subscription would also be cross-partition unless the partition key exactly matches the filter.

This would be correct if the application's primary workload was to look up users by their email address (e.g., for login or email-based search) and the query for subscription data was secondary or could be handled by a separate index.

If the workload consisted solely of queries to find all users subscribed to a specific service (e.g., 'PremiumVideo'), and each service had a large number of users, then partition key on serviceName would make those queries single-partition and efficient.

This would be correct if the workload required efficient queries for both a specific user's subscriptions and all users with a specific subscription, and the partition key was designed to distribute data evenly while supporting both query patterns with in-partition queries.

Candidates may think email is a good partition key because it is unique and evenly distributed, but they overlook that the main access pattern is by userId, not email.

Candidates may think that since the query involves filtering on serviceName, using it as the partition key would make that query efficient, overlooking that the primary access pattern (retrieving by userId) would become inefficient.

Candidates may think a composite key covers both query patterns, but they overlook that Azure Cosmos DB partition key is used for data distribution and must be a single property path; composite keys are not supported as partition keys, and queries not specifying the full partition key become cross-partition.

Azure Stream Analytics is designed for real-time stream processing but lacks native batch processing and unified experience for complex historical queries joining streaming and batch data without moving data between systems.

Azure Data Factory is an orchestration and ETL service for data movement and transformation, but it does not natively support real-time stream processing or unified stream/batch analytics in a single service.

Azure HDInsight requires managing separate clusters for stream (Spark Streaming) and batch (Spark SQL) processing, and does not offer a unified experience without moving data between systems. It also lacks native real-time dashboard capabilities.

An exam question that requires only real-time analytics on streaming data (e.g., IoT telemetry) with simple aggregations and no need for historical batch joins or unified batch/stream processing.

A company needs to orchestrate and automate data movement from multiple on-premises and cloud sources to a central data lake, performing scheduled transformations without real-time requirements.

A question where the requirement is to process large-scale data using open-source frameworks like Hadoop, Spark, or Hive, with full control over cluster configuration and scaling, and where a unified stream/batch experience is not required.

Candidates see 'streaming clickstream data' and 'real-time dashboards' and immediately think of Stream Analytics, overlooking the requirement for unified batch processing and complex historical queries.

Candidates may think Data Factory can handle both streaming and batch because it can integrate with other services, but it lacks native stream processing capabilities and is not a unified analytics platform.

Candidates may think HDInsight's support for both Spark Streaming and batch processing via Spark SQL provides a unified experience, overlooking the operational overhead and lack of integrated real-time dashboards.

Azure Stream Analytics is a real-time stream processing engine, but it cannot directly serve ad-hoc T-SQL queries that combine live sensor data with historical CSV files in Data Lake Storage. It lacks a unified query interface for both streaming and batch data.

Azure Databricks is optimized for big data engineering and machine learning with Spark, but it does not natively support ad-hoc T-SQL queries or direct integration with live streaming data from Event Hubs for real-time dashboards without additional configuration, making it less suitable than Synapse Analytics for combining live sensor data with historical records via T-SQL.

Azure Analysis Services is a semantic modeling and OLAP engine, not designed for real-time streaming or direct T-SQL queries on raw data. It cannot ingest live Event Hubs data or run ad-hoc T-SQL queries combining streaming and historical data.

A question where the only requirement is real-time processing of streaming data (e.g., alerting on temperature thresholds) without any need for ad-hoc T-SQL queries or combining with historical batch data. For example: 'Which service should be used to filter and aggregate IoT sensor data in real-time before sending to a dashboard?'

A data science team needs to build a machine learning model on historical sensor data stored in Data Lake Storage, and then deploy the model for real-time predictions on streaming data from Event Hubs. Azure Databricks would be the correct choice because it provides collaborative notebooks, Spark-based processing, and MLflow for model management.

A question where the requirement is to create a semantic model for interactive reporting and analysis on pre-aggregated, historical data from a data warehouse, with no need for real-time streaming or direct T-SQL queries. For example: 'A company needs to build a tabular model for Power BI reports from an existing Azure SQL Data Warehouse.'

Candidates see 'real-time sensor data' and 'dashboard' and immediately think of Stream Analytics, overlooking the additional requirement for ad-hoc T-SQL queries that combine streaming and historical data, which Stream Analytics cannot do.

Candidates may think Databricks can handle both streaming and batch analytics, but they overlook that the question specifically requires ad-hoc T-SQL queries, which are not a native feature of Databricks, and that Synapse provides a unified experience for T-SQL and real-time dashboards.

Candidates may confuse Analysis Services with Synapse Analytics because both are analytics services, and Analysis Services is known for fast query performance on aggregated data, but it lacks streaming and direct T-SQL capabilities.

Progress notes are free-text, which is unstructured data, not semi-structured. Lab results as XML have a schema and tags, making them semi-structured, not unstructured.

Lab results (XML) are semi-structured, not unstructured; progress notes (free-text) are unstructured, not semi-structured. The order should be: structured (relational table), unstructured (progress notes), semi-structured (lab results).

The option D (Unstructured, Structured, Semi-structured) is wrong because it misorders the data types: patient admission data (relational table) is structured, progress notes (free-text) are unstructured, and lab results (XML) are semi-structured.

If the question had progress notes as structured fields (e.g., coded entries) and lab results as free-text reports, then the order would be Structured, Semi-structured, Unstructured.

If the question asked for 'relational table, lab results, progress notes' and lab results were described as free-text documents while progress notes were XML files, then the order would be: structured, unstructured, semi-structured.

This option would be correct if the question asked: 'A healthcare provider stores patient admission data as free-text documents, progress notes in a relational database, and lab results as JSON files. Which order correctly categorizes these data types?' Then the order would be Unstructured (admission data), Structured (progress notes), Semi-structured (lab results).

Candidates may confuse free-text documents as semi-structured because they contain some organization (e.g., headings), or mistakenly think XML is unstructured due to varying fields.

Candidates may confuse semi-structured data (like XML) with unstructured data, or misorder the types due to not carefully reading the sequence of data types in the question.

Candidates may confuse the data types, thinking that free-text progress notes are semi-structured or that XML lab results are unstructured, leading to a misordering that seems plausible but is incorrect.