Select Two (Multi-Select) Questions

Data lakes guarantee ACID transactions across all data.

Why it fails: ACID transactions require coordinated atomicity, consistency, isolation, and durability, which a generic data lake does not natively provide across all stored objects. Standard object-store commits are not transactional, so concurrent reads/writes can yield partial or inconsistent results unless a transactional layer such as Delta Lake, Apache Iceberg, or Apache Hudi is added. Even then, ACID guarantees apply only to tables that opt into those formats, not to every file in the lake.

Data lakes store only structured data.

Why it fails: This claim contradicts the core design of data lakes, which intentionally ingest structured, semi-structured, and unstructured data without discrimination. A system that stores only structured data is a relational database or classic data warehouse, not a data lake. Unstructured and semi-structured inputs (documents, sensor streams, clickstream logs, multimedia) are common lake payloads.

Need for database auditing

Why it fails: Both platforms offer auditing, so it does not differentiate them; Azure SQL Database has built-in auditing while SQL Server on Azure VMs requires configuring SQL Server Audit yourself. It tempts because compliance needs often drive platform choice, yet the deciding factor is whether you need OS-level control, not auditing presence.

Support for geo-replication

Why it fails: Geo-replication exists in both: Azure SQL Database provides active geo-replication and failover groups, while SQL Server on Azure VMs uses Always On availability groups. It tempts because disaster recovery is a common selection criterion, but the genuine differentiator is whether you need instance-level features such as SQL Agent or cross-database queries.

Need for Transparent Data Encryption

Why it fails: Transparent Data Encryption is available on both platforms, so it cannot decide the choice; Azure SQL Database enables TDE by default, and SQL Server on Azure VMs supports it identically. It tempts because encryption requirements feel platform-specific, yet the real axis is whether you need full instance and OS control.

Table Storage supports multi-region writes

Why it fails: Table Storage is a single-region write service; even with read-access geo-redundant storage, the secondary endpoint is read-only and cannot accept write operations. Therefore, claiming Table Storage supports multi-region writes is incorrect, as write traffic must always target the primary region. This limitation forces applications that need global write scalability to look at services like Cosmos DB.

Cosmos DB does not support JSON documents

Why it fails: Cosmos DB is a multi-model NoSQL database in which JSON is the native wire format for documents, and the core SQL API stores and queries JSON directly. It also supports BSON for MongoDB compatibility, but JSON is always available without translation or transformation. Hence, stating that Cosmos DB does not support JSON is factually incorrect and overlooks its fundamental document model.

Azure SQL Database

Why it fails: Azure SQL Database is a fully managed relational database service built on the SQL Server engine, enforcing a fixed schema with tables, rows, columns, and primary/foreign key constraints. It uses T-SQL for querying and maintains ACID guarantees, making it a true relational store. Since the question asks for non-relational services, this cannot be a correct answer.

Azure Synapse Analytics

Why it fails: Azure Synapse Analytics (formerly SQL Data Warehouse) uses a distributed Massively Parallel Processing architecture, but it still represents data as relational tables queried via T-SQL, with named schemas and structured columns. It is built for analytical workloads, yet its underlying data model is relational. Therefore it does not count as a non-relational service.

Azure Database for PostgreSQL

Why it fails: Azure Database for PostgreSQL is a managed PaaS offering for PostgreSQL, an open-source relational database engine that relies on tables, rows, relations, and foreign keys, and uses SQL for data manipulation and joins. It enforces schema and ACID properties, ensuring consistency and integrity. Being relational, it is not a non-relational service.

Provides automatic indexing of all attributes

Why it fails: Table Storage indexes exactly two attributes by default: the partition key and the row key, which together form the primary key. Any other property is not indexed, so filtering or sorting on non-key attributes requires retrieving all entities in a partition and evaluating the predicate in client code or using a scan. This lack of secondary indexes is a deliberate trade-off for predictable key-based performance, so claiming it indexes all attributes is incorrect.

Supports REST API access

Why it fails: The REST API is a generic storage interface exposed by Table Storage, Blob Storage, Queue Storage, and File Storage alike, so it is not a differentiator that makes Table Storage advantageous. While Table Storage does support REST, almost every Azure Storage service does; the question asks for benefits specific to Table Storage, and REST access is a common baseline rather than a unique capability. Its value lies in protocol compatibility, not in setting Table Storage apart.

Offers higher throughput for large files

Why it fails: Table Storage imposes strict size limits—each entity can be at most 1 MB and each property up to 64 KB—making it unsuitable for large files. Blob Storage, by contrast, supports blobs up to 8 TiB in a single block and is optimized for streaming and high-throughput access to bulk binary data. Thus, if you need high throughput for large files, Blob Storage is the correct service, not Table Storage.

Azure SQL Database

Why it fails: Azure SQL Database is a relational database engine that structures data into tables, rows, and columns with enforced schemas and constraints. While T-SQL includes functions like OPENJSON and the JSON data type can hold text, JSON is not a first-class table storage format here. Highly variable or nested semi-structured data is difficult to model efficiently, so Azure SQL Database is not the recommended choice.

Azure Synapse Analytics

Why it fails: Azure Synapse Analytics is a distributed analytics and data warehousing service built around relational tables and columnar storage for structured data. Dedicated SQL pools require a defined schema before loading, and while serverless SQL can use OPENROWSET to query Parquet or JSON files in Azure Storage, those files are stored in Blob or Data Lake, not inside Synapse itself. Therefore it is a query and analytics engine for semi-structured files, not a storage service for them.

Power BI

Why it fails: Power BI is a business intelligence and visualization platform that creates dashboards and reports from data stored elsewhere. It can import data into an in-memory cache or issue DirectQuery live queries, but it is not a data store such as a database or object storage. You would create reports in Power BI, not persist semi-structured records with it, so it does not qualify as an Azure storage service.

Azure Analysis Services

Why it fails: Azure Analysis Services is an enterprise-grade semantic modeling engine that performs online analytical processing (OLAP) and provides tabular models for business intelligence. It does not contain any data ingestion, copying, or transfer mechanisms; it simply consumes data that has already been stored in sources like Azure SQL Database or Power BI datasets. Therefore, using it to move data from on-premises to Azure is impossible because it has no connectivity or pipeline components for data movement.

Azure Synapse Serverless SQL pool

Why it fails: Azure Synapse Serverless SQL pool is a query engine that lets you run T-SQL queries directly over files in Azure Data Lake Storage or other external sources on a pay-per-query basis. It is stateless and does not persist data after query execution, nor does it have any copy or ingestion commands. Since it only reads data in place and never writes or moves data to another location, it cannot be used for data transfer from on-premises.

Azure SQL Database

Why it fails: Azure SQL Database is an as-a-service relational database engine optimized for online transaction processing (OLTP), not for interactive analytical queries over large-scale data warehouses or data lakes. Its provisioned compute and storage limits make it expensive and inefficient for scanning billions of rows, and it lacks native integration with file formats like Parquet for ad-hoc serverless analysis. Therefore, while you can run some queries, it is not designed as an interactive analytics service.

Azure Data Factory

Why it fails: Azure Data Factory is a cloud-based data integration and orchestration service used to create pipelines that ingest, transform, and move data between more than 100 supported sources and destinations. It does not host a query engine or interactive workspace; instead, it triggers activities that can invoke analytics services like Synapse or Databricks. Since it does not execute analytical queries itself, it cannot itself be used to perform interactive analytics.

Azure Data Lake Storage Gen2

Why it fails: Azure Data Lake Storage Gen2 is a highly scalable storage service that combines a hierarchical namespace with low-cost capacity for structured and unstructured big data. Although it is commonly used as the data repository for analytics solutions, it does not provide a compute or query engine, nor does it expose an interactive notebook or SQL endpoint. It is an inert data store, so it cannot perform interactive analytics without an external processing service.

Relational OLTP with complex joins

Why it fails: Cosmos DB is a NoSQL database that uses a schema-agnostic data model (documents, graphs, key-value, wide-column) and does not perform relational-style joins across collections efficiently. An OLTP system with complex join-heavy transactions requires enforcing referential integrity and ACID guarantees across normalized tables, which is the purpose of Azure SQL Database rather than Cosmos DB. While the SQL API lets you query JSON documents with some joins within a single document, multi-document set operations must be manually implemented via denormalized embedded data or client-side logic, so it is not a valid substitute for a relational OLTP engine.

Storing large files like images and videos

Why it fails: Cosmos DB document items have a maximum size of 2 MB, so large binary assets such as images and videos exceed its payload limits and cannot be stored as documents. Azure Blob Storage is the correct service for unstructured large files because it supports up to ~4.77 TB per blob and is optimized for high-throughput streaming. A common pattern is to store the file in Blob Storage and keep only a URL or metadata reference inside Cosmos DB, using Cosmos for querying metadata rather than for binary content itself.

Azure Synapse Analytics

Why it fails: Azure Synapse Analytics is an enterprise analytics service that unifies data warehousing and big data processing, but it is not a storage service itself. It can query semi-structured files stored in external locations via external tables or PolyBase, but the actual enduring data remains in underlying storage like Blob Storage or Data Lake Storage Gen2. Consequently, Synapse acts as a processing and analysis engine, not as one of the primary storage services for semi-structured data.

Azure SQL Database

Why it fails: Azure SQL Database is a managed relational database service that stores data in tables with a defined schema, requiring entities to conform to precise column types and constraints. Although it supports JSON functions for parsing and querying JSON fragments, the JSON is still placed inside relational columns, and the service is not designed for storing raw semi-structured files or documents. Thus, it is not a general-purpose storage service for semi-structured data.

Azure Cosmos DB

Why it fails: Azure Cosmos DB is a globally distributed, multi-model NoSQL database service that natively stores JSON documents, key-value records, graphs, and column-family data with a flexible schema. While it absolutely handles semi-structured data, it is designed as a transactional, queryable database with indexing, consistency levels, and SLAs, not as a raw file or object storage service. In the context of this question, Cosmos DB belongs to the database category, not the core storage solutions like Blob Storage and Data Lake Storage Gen2.

Azure Machine Learning

Why it fails: Azure Machine Learning is a standalone Azure service for building, training, and deploying machine learning models, not a component inside Microsoft Fabric. While Fabric does offer AI capabilities, such as built-in AI functions and integration with Azure AI, Azure Machine Learning itself is a separate product. Therefore, it should not be listed as one of the three components of Fabric.

Azure DevOps

Why it fails: Azure DevOps is a separate suite of services for CI/CD, version control, and project management, and it is not part of Microsoft Fabric's core architecture. Fabric does offer deployment pipelines for governance, but these are built-in features, not Azure DevOps itself. Thus, Azure DevOps is an external tool that may integrate with Fabric but is not one of its three components.

Azure SQL Managed Instance

Why it fails: Azure SQL Managed Instance is another relational offering that provides nearly full SQL Server engine compatibility along with managed instance-level capabilities, including T-SQL, linked servers, and agent jobs. The presence of a rigorous relational schema and SQL query surface places it firmly in the relational category, not NoSQL.

Azure Database for PostgreSQL

Why it fails: Azure Database for PostgreSQL is a fully managed relational database service based on the PostgreSQL open-source engine, supporting SQL queries, joins, ACID transactions, and a fixed relational schema. Because it relies on SQL and enforces relationships and constraints, it is not a NoSQL service and therefore is not one of the correct choices.

Azure SQL Database

Why it fails: Azure SQL Database is Microsoft's Platform-as-a-Service relational database offering, built on the SQL Server engine, where data is organized into tables with predefined schemas and relational integrity. This SQL-based design fundamentally conflicts with NoSQL principles, so it cannot be selected for the two NoSQL services.

Azure Cosmos DB

Why it fails: Azure Cosmos DB is a globally distributed, multi-model NoSQL database service that supports document, key-value, graph, and wide-column data models via APIs like Core SQL, MongoDB, Cassandra, Gremlin, and Table. Its SQL API uses a JSON-based query language, not the T-SQL relational engine, and it does not implement SQL Server semantics such as stored procedures, joins, or transactional consistency in the same way. Therefore it cannot be a deployment option for Azure SQL; it is a separate service on the same Azure platform.

Azure Database for MariaDB

Why it fails: Azure Database for MariaDB is a managed community database service based on the MariaDB source code, a fork of MySQL, and it belongs to the open-source family of Azure services alongside MySQL and PostgreSQL. It supports the MySQL wire protocol and features, not Microsoft SQL Server's T-SQL dialect, SQL Server Agent, or Integration Services. Consequently, it is not an Azure SQL deployment option and cannot run SQL Server workloads without significant migration changes.

Azure Synapse Analytics Dedicated SQL Pool

Why it fails: Azure Synapse Analytics Dedicated SQL Pool, formerly SQL Data Warehouse, is a cloud data warehouse service built on a massively parallel processing (MPP) architecture that distributes data across 60 distributions. It uses T-SQL but is designed exclusively for large-scale analytical queries, not for transactional OLTP workloads, and it is managed under the Azure Synapse service, which blends SQL with Spark and Pipelines. Since it has its own deployment model, billing, and resource management, it is not one of the deployment options for Azure SQL.

Azure SQL Database

Why it fails: Azure SQL Database is a managed relational database service, not a pipeline orchestration tool. It stores and queries relational data but does not have built-in capabilities to define, schedule, or monitor data movement/transformation workflows. Even with SQL Agent jobs for scheduling, it lacks the comprehensive integration and activity orchestration of a dedicated ETL service.

Power BI

Why it fails: Power BI is a business analytics and visualization platform, not an orchestration service. It creates interactive reports and dashboards but does not natively execute or coordinate data movement between sources and destinations. While it can integrate with data sources and refresh datasets, it lacks the pipeline activities, control flow, and scheduling granularity of a dedicated orchestration tool.

Azure Databricks

Why it fails: Azure Databricks is an Apache Spark-based analytics platform for big data engineering and machine learning. It can run notebooks and jobs that process data, but it is not a data integration orchestration service. Orchestrating pipelines across multiple activities, dependencies, and data stores is not its core function; rather, it serves as a compute engine that other tools like Data Factory can invoke.

No predefined schema

Why it fails: Structured data by definition has a schema that is defined before data loading (schema-on-write), ensuring consistency. Without a predefined schema, data would lack fixed fields and types, making it unstructured (like text or media) and preventing relational querying. Therefore, absence of schema contradicts structured data.

Key-value pairs

Why it fails: Key-value pairs are a fundamental data model of NoSQL stores like Redis or DynamoDB, where each item is a unique key associated with a value that can be opaque. While key-value pairs can be used to represent semi-structured or unstructured data, structured data is organized into tables with rows and columns, not simple key-value mappings. Therefore, key-value pairs do not describe structured data.

Schema-on-read

Why it fails: Schema-on-read is a paradigm where the schema is applied when data is read, not when it is written, commonly seen in data lakes with formats like JSON, Parquet, or Avro. This flexibility suits semi-structured or unprocessed data, but structured data relies on schema-on-write: a fixed, pre-defined schema enforced during ingestion. Thus, schema-on-read does not characterize structured data.

Distributed processing

Why it fails: Distributed processing describes splitting work across multiple nodes (e.g., Apache Spark, Hadoop), but it is a parallelism technique rather than a data processing pattern. The retail solution must choose whether to handle data in bulk batches or as a real-time stream; distribution alone does not specify scheduling, latency, or workload type, so it does not satisfy the requirement.

Data lake storage

Why it fails: Data lake storage is a repository for raw, schema-on-read data (e.g., Azure Data Lake Storage Gen2), not a processing method. While a retail analytics solution may use a lake as a data source or landing zone, it does not determine whether ETL jobs run in batches or streams. Choosing storage without defining a processing pattern leaves the core requirement unanswered.

Transactional database

Why it fails: A transactional database (OLTP) is optimized for low-latency inserts, updates, and point lookups, often enforcing ACID guarantees for day-to-day retail operations. It is not designed for large-scale analytical scans and aggregations, which would degrade performance and are handled better by a data warehouse or analytical processing service. The scenario's reporting need calls for a processing model, not a transactional store.

Simpler high-availability configuration

Why it fails: Both Azure SQL Database and Azure SQL Managed Instance are fully managed PaaS services, so the platform automatically handles high availability for you; you never configure Always On Availability Groups or failover clusters in either. Managed Instance actually mirrors the SQL Server engine's own HA model and provides comparable health and availability options, which means choosing it for a simpler HA configuration is not a valid differentiator.

Desire for automated backups

Why it fails: Automated backup management is a built-in capability of both Azure SQL Database and Azure SQL Managed Instance, with point-in-time restore and configurable retention periods available on either platform. Because this functionality is not exclusive to Managed Instance, a desire for automated backups does not justify the choice and should not be used as a differentiator between these two services.

Unlimited storage per database

Why it fails: Contrary to a benefit, an elastic pool imposes a maximum size limit per database, which in the DTU purchasing model is typically 1 TB for Standard and Premium tiers. You cannot store unlimited data; the per-database limit is capped even though the pool aggregates storage across all databases.

Isolated performance for each database

Why it fails: Because elastic pools are explicitly designed for shared resource usage, they do not provide per-database performance isolation. A burst of activity in one database can consume common CPU or I/O capacity and degrade performance for other databases in the same pool, so isolated performance is not achievable.

Support for databases over 1 TB each

Why it fails: Elastic pools are not marketed as a way to support databases larger than 1 TB; in fact, the standard per-database maximum size for DTU-based elastic pools is 1 TB. The tooling for larger single databases is the Single Database or Managed Instance service, not a typical benefit you'd associate with pooling.

Consists of audio and video files

Why it fails: Audio and video files are stored as compressed binary or waveform data with no inherent row-and-column organization or fixed attribute structure. Their content—such as spoken words or scene elements—is not represented directly in the file format, so meaning must be extracted through signal processing or machine learning. This makes them emblematic of unstructured data, where the structure is implicit rather than predefined.

Uses JSON or XML format

Why it fails: JSON and XML encode data as nested self-describing documents with named tags or keys, so they allow fields to vary between records without a central schema. Although these formats have syntactic structure, their semantic schema is not strictly enforced at storage time, letting records evolve independently. This flexibility places them in the semi-structured category, not the fully structured category, because they do not require a consistent row-column mapping.

Azure Synapse Analytics

Why it fails: Azure Synapse Analytics is an integrated analytics platform that combines big data and data warehousing capabilities. While it can ingest and transform data using pipelines, its primary purpose is to provide analytical querying over large datasets, not to serve as a general-purpose data integration service. Its focus on analytics is what makes it an incorrect choice for a data integration question.

Azure Stream Analytics

Why it fails: Azure Stream Analytics is a real-time stream processing engine that analyzes high-volume data in motion from sources like IoT devices, event hubs, and Kafka. It performs computations and transformations on streaming data, but it is specialized for time-series analytics rather than broadly integrating data across different storage and application boundaries. Therefore, it is not considered a primary data integration service.

Azure Analysis Services

Why it fails: Azure Analysis Services is a semantic modeling service that provides enterprise-grade tabular data models for business intelligence and reporting. It is used to define measures, relationships, and KPIs, and it consumes data from various sources rather than integrating or transforming it. Its role is analytical and modeling-focused, which is why it is not a data integration service.