Microsoft Azure Data Fundamentals DP-900 (DP-900) — Questions 601–675

The nightly job processes data in large batches once per day, not continuously or with low latency, so it is not real-time processing.

Streaming processing handles data continuously as it arrives, but this job runs nightly on already-collected data, making it batch, not streaming.

Transactional processing handles individual, real-time transactions (e.g., order placement), not nightly aggregation of millions of past transactions into summary tables.

A question describing a system that monitors credit card transactions for fraud and must flag suspicious activity within milliseconds would make real-time processing correct.

A question describing a system that continuously ingests and processes transactions as they occur (e.g., fraud detection on credit card swipes) would make streaming processing the correct answer.

A question describing a system that processes individual sales transactions as they occur, ensuring ACID properties for each purchase, would make transactional processing correct.

Candidates may confuse 'nightly' with 'real-time' because they think of the job running every night as a scheduled, recurring process, but real-time requires immediate processing.

Candidates may confuse 'streaming' with any large-scale data processing, or think that processing millions of transactions implies a stream, missing the scheduled batch trigger.

Candidates may confuse 'transactional' with any data processing involving transactions, not realizing it specifically refers to OLTP systems that handle individual, real-time operations.

JPEG files are binary data without inherent structure, making them unstructured, not semi-structured. JSON documents have a flexible schema (key-value pairs), classifying them as semi-structured, not unstructured.

Option C incorrectly classifies the relational table as semi-structured (it is structured with fixed columns) and JSON as structured (JSON is semi-structured as it allows flexible fields). JPEG images are correctly classified as unstructured.

JPEG files are binary data without inherent structure, making them unstructured, not structured. JSON documents have a flexible schema with optional fields, classifying them as semi-structured, not unstructured.

If the question defined JPEG files as having metadata tags (like EXIF) that are semi-structured, and JSON documents as lacking any schema (e.g., arbitrary text), then B would be correct.

Option C would be correct if the relational table had variable columns or allowed schema changes (making it semi-structured), and the JSON documents had a fixed schema enforced by the application (making them structured). For example, a table with optional columns and JSON with required fields.

If the question described a relational table storing unstructured data like BLOBs, JPEG files with EXIF metadata (structured), and JSON documents with a fixed schema enforced by a validation tool (structured), then D would be correct.

Candidates may confuse 'semi-structured' with 'unstructured' due to the flexibility of JSON, or mistakenly think image files have inherent structure because they can be parsed.

Candidates may confuse 'semi-structured' with 'structured' because JSON has a key-value format that appears organized, and they might think a relational table is 'semi-structured' if they consider data types as flexible, overlooking the fixed schema.

Candidates may confuse 'structured' with 'binary' or think JPEG files have a rigid format (structured), and mistakenly view JSON as unstructured due to its flexible schema.

Azure SQL Database does not support SQL Server Integration Services (SSIS) and provides limited instance-level configuration control, making it unsuitable for the company's need to run SSIS packages and retain full control over instance-level settings.

Azure Synapse Analytics is a cloud-scale analytics service that does not support SSIS packages natively, and it is not designed for transactional workloads or instance-level configuration control like patching and backup management.

Azure SQL Server on Azure Virtual Machines requires you to manage patching and backups manually, which contradicts the goal of minimizing administrative overhead. It also does not provide the same level of managed service as Azure SQL Managed Instance.

A company is migrating a simple OLTP workload that does not require SSIS or instance-level configurations, and they want a fully managed platform with built-in high availability and automated patching. Azure SQL Database would be the correct choice.

A company needs to run large-scale data warehousing and analytics workloads, such as petabyte-scale queries across relational and non-relational data, and requires integrated data integration pipelines (e.g., Synapse Pipelines) but does not need SSIS or instance-level control.

A company needs to run a legacy SQL Server application that requires full control over the OS, custom configurations, or third-party software alongside SQL Server, and is willing to handle patching and backup management themselves.

Candidates may assume that Azure SQL Database is the default managed option for SQL Server migrations, overlooking its lack of SSIS support and limited instance-level configurability.

Candidates may confuse Synapse Analytics' data integration capabilities with SSIS support, or think it is a suitable replacement for SQL Server due to its SQL-based querying and ETL features.

Candidates may think that running SQL Server on VMs offers the most control and compatibility for SSIS, but overlook the higher administrative overhead and that Azure SQL Managed Instance also supports SSIS with less management.

GPS ingestion processes data in real-time as it arrives, which is stream processing, not batch. Nightly aggregation processes a fixed set of data at scheduled intervals, which is batch processing, not stream.

The nightly aggregation job processes a full day's data at once, which is batch processing, not stream processing. Stream processing handles data in real-time as it arrives, which applies only to the GPS ingestion.

GPS ingestion is real-time (stream processing), and the nightly aggregation is batch processing. Option D incorrectly classifies both as batch processing, ignoring the real-time nature of GPS data ingestion.

If the question described a scenario where GPS data is collected in files throughout the day and processed nightly, and the nightly aggregation updates a live dashboard in real-time, then B would be correct.

If the question described both workloads as continuously processing data as it arrives (e.g., GPS coordinates streamed and aggregated in real-time for immediate reporting), then both would be stream processing.

If the question described a scenario where GPS data is collected in files throughout the day and processed in a nightly batch job, and the aggregation is also batch, then both would be batch processing. For example: 'A company collects GPS logs in daily CSV files and runs a nightly job to process them into a report.'

Candidates may confuse the continuous nature of GPS data collection with batch processing, or mistakenly think that nightly jobs are stream processing because they run regularly.

Candidates may confuse 'real-time' with any data processing that happens frequently, or mistakenly think that the nightly job is also stream processing because it runs regularly.

Candidates may confuse 'ingestion' with 'batch' if they think of data being collected over time and processed later, not realizing that real-time ingestion is stream processing.

The Serverless compute tier is designed for a single database with intermittent usage, but the question involves 20 databases with bursty peaks. An Elastic Pool shares resources across databases, which is more cost-effective for multiple databases with varying peak times than provisioning each database individually with Serverless.

Azure SQL Managed Instance is designed for lift-and-shift migrations requiring full SQL Server instance-level features (e.g., SQL Agent, cross-database queries) and does not offer the cost-sharing, per-database resource pooling that Elastic Pools provide. It would require over-provisioning for peak loads and does not minimize costs for 20 separate databases with bursty, unpredictable usage.

Hyperscale is designed for very large databases (up to 100 TB) and high transaction throughput, not for managing multiple smaller databases with bursty, unpredictable usage patterns. It does not provide the cost-sharing benefits of an elastic pool, leading to over-provisioning and higher costs.

A company has a single e-commerce application with a database that experiences long periods of idle time and short, unpredictable bursts of activity. They want to minimize costs by paying only for compute used during active periods and automatically pausing during idle times.

A company needs to migrate multiple on-premises SQL Server databases to Azure with minimal application changes, requiring instance-scoped features like SQL Agent jobs, cross-database queries, and linked servers. They have a predictable workload and are willing to pay for a fixed set of resources rather than pooling databases.

A company has a single, very large database (e.g., over 4 TB) with high transaction throughput and requires rapid scaling for unpredictable workloads. They need built-in high availability and automatic backups, and cost is less of a concern than performance and scalability.

Candidates may think Serverless is the best fit for unpredictable usage patterns because it automatically scales and pauses, but they overlook that the question involves multiple databases where resource pooling is more economical.

Candidates may confuse Managed Instance as a 'pooled' option because it supports multiple databases, but they overlook that it charges for the entire instance's resources (vCores and storage) rather than per-database usage, making it cost-inefficient for bursty, variable workloads across many databases.

Candidates may associate 'bursty peaks' with Hyperscale's rapid scaling capabilities, but overlook that Hyperscale is for individual large databases, not for pooling multiple smaller databases to share resources and minimize costs.

Azure SQL Database does not support SQL Server Agent jobs or cross-region automatic failover with minimal application changes; it requires database-level management and lacks instance-scoped features.

SQL Server on Azure VMs requires you to manage the OS and SQL Server, including SQL Server Agent jobs and high availability setup, which contradicts the requirement for a fully managed service with minimal application changes.

Azure Synapse Analytics is a distributed analytics service for large-scale data warehousing and big data workloads, not designed for transactional SQL Server databases with SQL Server Agent jobs and automatic failover across regions.

For a new application with a single database under 4 TB, no dependency on instance-level features like SQL Agent, and requiring built-in high availability within a single region, Azure SQL Database would be the correct choice.

A company needs full control over the SQL Server environment, including custom configurations, third-party tools, or legacy dependencies that are not supported in PaaS offerings, and is willing to manage the underlying VM and high availability manually.

A company needs to migrate a 10-TB data warehouse from on-premises SQL Server to Azure, requiring massively parallel processing (MPP) for complex analytical queries and integration with big data pipelines, with minimal changes to existing SQL code.

Candidates may assume Azure SQL Database is the default fully managed option and overlook the specific requirements for SQL Agent jobs and cross-region failover, which are only available in Azure SQL Managed Instance.

Candidates may think that migrating to VMs is the simplest lift-and-shift approach, but they overlook the management overhead and the fact that Azure SQL Managed Instance provides near 100% compatibility with less administrative effort.

Candidates may confuse Synapse Analytics as a fully managed SQL service that supports large databases, overlooking its focus on analytics rather than OLTP and its lack of support for SQL Server Agent jobs and auto-failover groups.

JSON payloads have a flexible schema with tags and key-value pairs, which is characteristic of semi-structured data, not the rigid schema of structured data.

JSON payloads have a schema (keys like device ID, timestamp, temperature) but are not rigidly tabular, so they are semi-structured, not unstructured. Unstructured data lacks a predefined data model or schema (e.g., raw text, images).

Relational data implies a strict schema of tables with rows and columns, but the JSON payload has a flexible schema with nested fields, making it semi-structured, not relational.

If the data were in a fixed schema like a CSV file with predefined columns and consistent data types, it would be structured data. For example, a table of customer orders with columns OrderID, CustomerName, and OrderDate.

A question where the data consists of free-form text documents, images, or audio files without any metadata or schema. For example: 'A company stores customer support chat logs as plain text files. Which data type describes these files?'

If the question described data stored in normalized tables with foreign keys (e.g., customer orders in a SQL database), then 'relational data' would be correct.

Candidates may think JSON is structured because it has keys and values, but they overlook that JSON allows varying fields and nested structures, making it semi-structured.

Candidates may think JSON is just text and thus unstructured, overlooking that JSON has a defined key-value structure. They confuse 'unstructured' with 'non-relational' or 'not in a table'.

Candidates may confuse 'relational' with any structured format, or think JSON's key-value pairs resemble relational tables, ignoring the schema flexibility.

Azure Table Storage does not support SQL-like query syntax or JSON documents natively; it uses OData and requires a fixed schema for partition and row keys, making it unsuitable for schema-less JSON sessions and complex queries like 'find all sessions for a user in the last 24 hours'.

Azure SQL Database enforces a fixed schema, but the question states that session documents have no fixed schema and may include additional optional fields. It also requires SQL-like queries on JSON documents, which Azure SQL Database supports, but the lack of schema flexibility makes it unsuitable for this use case.

Azure Blob Storage is optimized for unstructured binary or text data, not for querying JSON documents with SQL-like syntax or indexing on fields like sessionId and userId. It lacks native support for complex queries and schema flexibility required for this use case.

A company needs to store large amounts of structured, non-relational data (e.g., device telemetry) with simple key-based lookups and no need for complex queries or indexing. The data has a fixed schema and queries are limited to partition key + row key patterns.

A company needs to store structured relational data with a fixed schema, such as customer orders with predefined columns, and requires complex joins, ACID transactions, and SQL queries. The data does not have varying fields, and schema changes are infrequent and managed through migrations.

A company needs to store and serve large media files (e.g., images, videos) for a social media application, with no need for querying individual fields within the files. The primary requirement is cost-effective, scalable storage with high throughput for blob data.

Candidates may confuse Azure Table Storage with a NoSQL option that can handle JSON, but they overlook its lack of native JSON support, SQL querying, and flexible schema capabilities.

Candidates may think that because the question mentions SQL-like syntax and JSON support, Azure SQL Database is a good fit, overlooking the requirement for a flexible schema that can handle optional fields without schema changes.

Candidates may think Blob Storage can handle JSON documents because it supports storing text files, and they might overlook the need for querying capabilities and indexing that are not available in Blob Storage.

The MongoDB API is designed for MongoDB wire protocol compatibility, not for native SQL-like queries. While it supports JSON documents, it cannot run SQL queries directly, which the application requires.

The Gremlin (Graph) API is designed for graph data models with nodes and edges, not for JSON documents with optional fields. Querying by userId and running SQL-like queries on nested JSON is better suited to the SQL (Core) API.

The Table API is designed for key-value and tabular data with a fixed schema, not for JSON documents with optional fields. It does not support SQL-like queries on nested JSON properties like work history.

A question where the application already uses MongoDB drivers and needs to migrate to Azure Cosmos DB with minimal code changes, or where the query requirements are limited to MongoDB-style queries (e.g., find, aggregate) without needing SQL syntax.

If the application needed to model complex relationships between users, such as social connections, friend-of-friend queries, or recommendation engines based on graph traversal, the Gremlin API would be the correct choice.

A question where the application stores structured, non-relational data with a fixed schema (e.g., device telemetry) and requires key-based lookups with O(1) latency, and does not need complex queries or nested JSON.

Candidates see JSON documents and assume MongoDB is the natural choice, overlooking that the SQL API also stores JSON and provides SQL query capabilities.

Candidates may mistakenly think that because the data has optional fields and relationships (e.g., work history), a graph API is appropriate, overlooking that the query patterns are document-oriented and SQL-like.

Candidates may confuse the Table API's simple key-value model with document storage, or assume any NoSQL API in Cosmos DB can handle JSON documents equally well.

Azure Data Factory is an ETL and data orchestration service, not a real-time stream processing engine. It cannot perform near real-time aggregation over 5-minute windows from Event Hubs.

Azure Databricks is a big data analytics platform that can process streams, but it is not the simplest or most cost-effective choice for near real-time sentiment aggregation over 5-minute windows from Event Hubs to Blob Storage. Azure Stream Analytics provides a purpose-built, serverless SQL-based solution for such streaming ETL tasks.

Azure Synapse Analytics is a data warehousing and analytics service, not a real-time stream processing engine. It cannot directly process streaming data from Event Hubs over 5-minute windows and output to Blob Storage without additional tools.

A question where the requirement is to orchestrate and schedule batch data movement from Event Hubs to Blob Storage, or to transform data in a batch manner using mapping data flows, without needing real-time processing.

A question where the team needs to perform complex, custom machine learning transformations on streaming data (e.g., using a trained sentiment model in Python) and also requires collaborative notebook development. For example: 'A data science team wants to build and deploy a custom sentiment analysis model on streaming tweets, with the ability to iterate on the model interactively.'

A question asks: 'You need to run complex T-SQL queries on large datasets stored in Azure Blob Storage and create a reporting dashboard. Which service provides a serverless SQL pool for querying data lakes?' In that scenario, Azure Synapse Analytics is correct.

Candidates may confuse Data Factory's data movement and transformation capabilities with stream processing, or think it can handle streaming data because it can ingest from Event Hubs in batch mode.

Candidates may associate Databricks with stream processing due to its Structured Streaming capabilities and think it is always the best choice for real-time analytics, overlooking simpler services like Stream Analytics for straightforward aggregation tasks.

Candidates may confuse Synapse Analytics with a stream processing service because it supports real-time analytics through its Spark pools, but the question specifically requires near real-time stream processing with windowed aggregation, which is not Synapse's primary function.

Azure Databricks with notebooks requires coding in Python, Scala, or SQL, not a visual, configuration-based approach. The question explicitly prefers minimal coding effort and a visual approach, making Databricks unsuitable.

Azure Stream Analytics is designed for real-time stream processing, not batch ingestion and transformation of daily transaction files. It lacks the visual, configuration-based data flow capabilities for complex business logic with conditional branching required by the question.

Azure Logic Apps is designed for lightweight workflow automation and integration, not for complex data transformations with conditional branching on large datasets. It lacks native data flow capabilities and is not optimized for orchestrating ETL pipelines into Azure Synapse Analytics.

A data science team needs to build a machine learning pipeline that ingests streaming data, performs advanced analytics (e.g., anomaly detection using custom algorithms), and requires collaborative development with version control. Azure Databricks with notebooks would be the correct choice for its support for ML frameworks and collaborative coding.

A company needs to process real-time sensor data from IoT devices, apply windowed aggregations, and output alerts to Azure Event Hubs. They prefer a serverless, SQL-based approach without managing infrastructure. Azure Stream Analytics would be the correct choice.

A company needs to automate a business process that triggers when a new file is uploaded to Blob Storage, then sends an email notification and updates a CRM record. The question emphasizes low-code integration between SaaS services and minimal data transformation.

Candidates may associate Databricks with data transformation and orchestration, overlooking the requirement for a visual, low-code solution. They might also overestimate the ease of use of notebooks for non-coders.

Candidates might confuse Stream Analytics' ability to handle transformations with the batch-oriented, visual data flows of Data Factory, especially if they overlook the 'daily files' batch requirement and focus on the 'transformation' aspect.

Candidates may confuse Logic Apps' visual designer and low-code approach with Data Factory's visual ETL capabilities, overlooking that Logic Apps is for integration workflows, not heavy data transformation and orchestration.

Workload B requires complex aggregations on terabytes of historical data, which is best suited for Azure Synapse Analytics (a distributed data warehouse), not Azure Cosmos DB (a NoSQL transactional database).

Azure Synapse Analytics is designed for large-scale data warehousing and analytics, not for high-volume, low-latency transactional workloads. Azure SQL Database is optimized for OLTP but lacks the massive parallel processing needed for complex aggregations on terabytes of data.

Azure Cosmos DB is a NoSQL database optimized for low-latency transactions, but it is not designed for complex aggregations on terabytes of historical data. Workload B requires a dedicated analytics service like Azure Synapse Analytics, not Cosmos DB.

If Workload B involved real-time analytics on high-velocity, globally distributed data with low-latency requirements, Azure Cosmos DB could be correct. For example, a scenario where both workloads need low-latency, globally distributed access and Workload B is a real-time dashboard on streaming data.

This option would be correct if Workload A required complex analytics on large datasets (e.g., real-time dashboards) and Workload B involved standard OLTP with moderate data volumes (e.g., a customer database).

This option would be correct if both workloads required globally distributed, low-latency access to data with flexible schemas, and the analytical queries could be handled by Cosmos DB's built-in analytical store or Synapse Link. For example, a real-time analytics application needing both transactional and analytical capabilities on the same data.

Candidates may think Azure SQL Database is only for transactions and Cosmos DB is only for NoSQL, but they might incorrectly assume Cosmos DB can handle complex aggregations on large historical data due to its scalability, overlooking its lack of native data warehouse features.

Candidates may confuse the roles of Azure Synapse Analytics and Azure SQL Database, mistakenly thinking Synapse can handle OLTP due to its SQL-based interface, or that SQL Database can handle large-scale analytics due to its familiarity.

Candidates may mistakenly believe that Azure Cosmos DB can handle both transactional and analytical workloads due to its multi-model capabilities and Synapse Link integration, overlooking that complex aggregations on large historical datasets are better suited for a dedicated analytics service.

Azure Synapse Analytics is optimized for large-scale data warehousing and T-SQL queries, not for real-time streaming ingestion and Kusto query language (KQL) used in Azure Data Explorer.

Azure Stream Analytics is a real-time stream processing engine, but it does not natively support Kusto query language (KQL) or provide interactive ad-hoc queries over historical data. The question requires both real-time ingestion and KQL-based analytics over 90 days, which Stream Analytics cannot fulfill as a primary data store.

Azure Analysis Services is an OLAP engine for pre-aggregated, modeled data, not designed for real-time streaming ingestion or interactive ad-hoc queries over raw CDR data using Kusto query language.

A company needs to run complex T-SQL queries across petabytes of structured and unstructured data in a data warehouse, with integrated data pipelines and BI integration.

A company needs to process a continuous stream of IoT sensor data, apply real-time transformations (e.g., aggregations, filtering), and output results to a dashboard or storage without needing to query historical data interactively. The primary requirement is low-latency stream processing, not ad-hoc analytics with KQL.

A company needs to create a semantic data model for business intelligence reporting over historical sales data from a data warehouse, with fast query performance for Excel and Power BI users.

Candidates may confuse Synapse's analytics capabilities with Data Explorer's, or think Synapse can handle streaming data and KQL, but it lacks native support for Kusto queries and real-time analytics on streaming data.

Candidates may focus on the 'continuous stream' and 'within seconds' keywords, assuming Stream Analytics is the best fit for real-time fraud detection, while overlooking the need for KQL-based interactive queries over historical data.

Candidates may confuse Analysis Services with a general analytics service due to its name, or think it supports real-time analytics because it can connect to live data sources.

A clustered index on CustomerID sorts the table by CustomerID, but the query filters on LastLoginDate. Without an index on LastLoginDate, the query must scan all 10 million rows, which is inefficient.

The query filters on LastLoginDate, not FullName. A non-clustered index on FullName would not help the query because it does not include the filter column, so the query would still require a full table scan.

A columnstore index is optimized for large-scale analytical queries (e.g., aggregations over many rows), not for point lookups or range scans on a single column like LastLoginDate. The query filters on a single date column, which is better served by a non-clustered index.

If the query frequently searched for a specific CustomerID (e.g., WHERE CustomerID = 123) or joined on CustomerID, a clustered index on CustomerID would be optimal for fast point lookups and range scans on the primary key.

If the query frequently filters or searches by FullName (e.g., WHERE FullName = 'John Doe') or sorts by FullName, a non-clustered index on FullName would be correct to speed up those operations.

A columnstore index on SignUpDate and LastLoginDate would be correct if the query involved aggregations (e.g., COUNT, SUM) over many rows, such as 'Find the average number of days between SignUpDate and LastLoginDate for all customers'.

Candidates often assume the primary key should always be the clustered index, but they overlook that the query's filter column (LastLoginDate) is more critical for this workload.

Candidates may think any non-clustered index on any column will improve query performance, overlooking that the index must match the filter column used in the WHERE clause.

Candidates may think columnstore indexes are always faster for large tables (10 million rows) and that including multiple columns in the index is beneficial, not realizing that columnstore indexes are designed for data warehousing workloads, not transactional point queries.

Product descriptions as plain text files and product images as JPEG files are both unstructured data, not semi-structured. Semi-structured data has some organizational properties (e.g., JSON, XML), which plain text and JPEG lack.

Product descriptions as plain text files are unstructured, not semi-structured. Semi-structured data has tags or markers (e.g., JSON, XML), which plain text lacks.

Product descriptions as plain text files are unstructured, not semi-structured. Semi-structured data has tags or markers (e.g., JSON, XML), which plain text lacks.

If the product descriptions were stored as XML or JSON files (semi-structured), and product images remained unstructured, then the order would be structured, semi-structured, unstructured.

If the product descriptions were stored as JSON or XML files (with tags/attributes), and product images remained unstructured, then the order would be structured, semi-structured, unstructured.

If the question described product descriptions stored as XML or JSON files (with tags/keys), and product images as unstructured, then the order would be: structured (relational), semi-structured (XML/JSON), unstructured (JPEG).

Candidates may mistakenly think plain text files are semi-structured because they have some formatting (e.g., paragraphs), but semi-structured data requires tags or markers (like XML/JSON).

Candidates may confuse plain text files as semi-structured because text can have some internal structure (e.g., paragraphs), but in data classification, plain text without metadata or tags is unstructured.

Candidates may mistakenly think that plain text files are semi-structured because they contain human-readable text, or they confuse 'unstructured' with 'no format' rather than 'no schema'.

JSON documents are semi-structured (varying fields), not more structured than a relational table (fixed schema). JPEG files are unstructured binary data, so they are the least structured.

JPEG files are unstructured binary data, JSON documents are semi-structured (schema-on-read), and relational tables are structured (fixed schema). Ordering from most to least structured should be relational table, JSON documents, JPEG files, not JPEG first.

If the question asked to order data types from least to most structured, then JSON documents (semi-structured) would come before relational tables (structured), making A correct.

If the question asked to order from least structured to most structured, then C (JPEG files, JSON documents, relational table) would be correct.

Candidates may think JSON is more structured than a relational table because it has key-value pairs, overlooking that relational tables enforce a fixed schema while JSON allows flexible fields.

Candidates might mistakenly think JSON is more structured than relational tables because JSON has nested keys, or they may confuse 'structured' with 'complexity' or 'flexibility'.

The nightly process reads historical data and writes aggregated results, which is a batch operation, not real-time transaction processing. OLTP is designed for high-volume, low-latency transactions like order entry, not for periodic aggregation of historical data.

The nightly process reads all sales transactions from the previous day, not in real-time, and processes them as a single batch, which is batch processing, not stream processing.

Data warehousing is a storage and querying system for analytics, not a processing workload. The nightly process is a batch processing job that loads data into the warehouse, but the process itself is batch, not data warehousing.

A question describing a system that records individual sales transactions as they occur, with high concurrency and immediate data consistency, such as a point-of-sale system or an e-commerce checkout process, would have OLTP as the correct answer.

Stream processing would be correct for a question describing a system that continuously ingests and processes sales transactions as they occur (e.g., real-time fraud detection or live dashboard updates).

A question asks: 'Which Azure service is used to store historical data for reporting and analysis from multiple sources?' Here, data warehousing (e.g., Azure Synapse Analytics) would be correct as the storage solution.

Candidates may confuse the data source (sales transactions) with the processing type, assuming that any system handling transactions is OLTP, without recognizing that the processing pattern (nightly batch aggregation) defines the workload.

Candidates may confuse 'nightly process' with continuous data flow, or think that any data processing involving transactions is streaming, overlooking the batch nature of the scheduled run.

Candidates confuse the destination (data warehouse) with the processing type, thinking that any work involving a data warehouse is 'data warehousing' rather than recognizing the batch nature of the nightly aggregation.

The DTU-based model bundles compute and storage into fixed tiers, so scaling storage requires scaling compute as well, which does not meet the requirement for independent scaling.

The serverless compute tier is designed for databases with intermittent, unpredictable usage patterns, not for scenarios where compute requirements remain stable. It does not allow independent scaling of storage and compute; compute scales automatically based on workload, but storage scaling is limited and not independent.

The Hyperscale service tier is designed for databases that require high scalability in storage and compute, but it does not allow independent scaling of storage and compute; instead, it provides a flexible architecture where compute nodes can be scaled independently, but storage is automatically managed and scales with compute. The question specifically asks for a model that allows independent scaling of storage and compute, which is a feature of the vCore-based model, not Hyperscale.

A company with predictable, stable workloads wants a simple, pre-configured purchasing model that bundles compute and storage at a fixed price, without the need to manage separate resources.

A correct scenario would be: 'A company has a database with sporadic, unpredictable usage patterns (e.g., occasional bursts of activity) and wants to pay only for compute used, with automatic pause during inactivity. Which purchasing model should they choose?'

A company needs a database that can automatically scale storage up to 100 TB and handle very high transaction rates with fast backup and restore. They expect unpredictable growth in both storage and compute, and they want to offload storage management. In this scenario, Hyperscale would be the correct choice because it provides near-instant scaling of compute and storage without manual intervention.

Candidates may confuse DTU with vCore, thinking DTU also allows separate scaling, or they may recall that DTU is commonly used for Azure SQL Database without understanding its limitations.

Candidates may confuse 'serverless' with the ability to scale components independently, or they may think that serverless automatically handles scaling of both compute and storage separately, not realizing that storage scaling is limited and compute scaling is automatic based on demand, not independent.

Candidates may confuse Hyperscale's ability to scale compute nodes independently with the vCore model's separate scaling of storage and compute. The term 'Hyperscale' implies extreme scalability, leading them to think it allows independent scaling of storage and compute, but in reality, storage is automatically managed and not independently scalable.