Select Two (Multi-Select) Questions

Data lakes guarantee ACID transactions across all data.

Why wrong: 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 wrong: 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.

Normalized data storage

Why wrong: Normalization is a relational database practice, not typical for NoSQL.

Strong ACID transaction support

Why wrong: Many NoSQL databases sacrifice ACID for performance and scalability.

Relational data model

Why wrong: NoSQL databases use non-relational models.

Consistency (C) and Partition Tolerance (P)

Why wrong: Choosing Consistency and Partition Tolerance would mean that during a network partition, the system cannot guarantee availability (e.g., it might refuse writes or reads from some regions to maintain consistency). This is not what the scenario describes—the system must keep accepting bids.

Consistency (C) and Availability (A)

Why wrong: According to the CAP theorem, it is impossible to guarantee both Consistency and Availability in the presence of a network partition. The system must tolerate partitions, so this combination is not achievable in practice.

Durability and Availability

Why wrong: Incorrect. Although Durability is important for recording bids, it is not part of the CAP theorem. The question asks for properties according to CAP, so this option is invalid.

Table Storage supports multi-region writes

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Frozen

Why wrong: Frozen is not a recognized access tier in Azure Blob Storage. The actual access tiers are Hot, Cool, and Archive; 'Frozen' is a fabricated name that might sound plausible for deeply archived data, but it does not exist in the Azure portal, SDKs, or Resource Manager API. Selecting Frozen would be invalid on the exam.

Standard

Why wrong: Standard is not a storage access tier; it refers to the performance tier of a general-purpose v2 storage account, with the other performance tier being Premium. The performance tier is chosen at account creation and applies to the entire account, not to individual blobs. Therefore, 'Standard' does not describe a blob's data temperature or access frequency in the way Hot and Cool do.

Cold

Why wrong: Cold is not recognized as a separate storage tier in the classic Azure Blob Storage access-tier model that this question is based on. In that model, the online tiers are Hot and Cool, while Archive is the offline tier for very rarely accessed data. Although 'Cold' sounds like a plausible lower-cost option, it is a distractor and is not the name of a distinct tier in that set.

Azure Machine Learning

Why wrong: 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 wrong: 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 Cosmos DB

Why wrong: 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 wrong: 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 wrong: 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.

Lower cost because you can choose any number of vCores

Why wrong: Choosing a specific number of vCores does not guarantee lower cost; your bill is driven by service tier, DTU/vCore model, storage size, and additional features like geo-replication or long-term backup retention. Moreover, the vCore options are discrete steps rather than any arbitrary value, and an IaaS SQL Server VM can also be scaled to a flexible vCore count. In many steady-state workloads, a SQL Server VM may even be cheaper, so vCore selection alone is not a cost benefit.

Ability to install custom software on the database server

Why wrong: Azure SQL Database is a fully managed PaaS offering, so there is no server OS or host environment to access—you cannot install software, agents, or middleware on the underlying server. Even features that seem extensible, such as custom CLR assemblies, are executed inside the database and cannot modify the server. If your application depends on running third-party software on the database server, you would need an IaaS VM instead.

Full control over the operating system

Why wrong: Because Azure SQL Database is a PaaS service, Microsoft abstracts the operating system and exposes only database-level management tools like T-SQL and the Azure Portal. You cannot RDP to the server, change Windows registry values, or configure OS-level security policies. Full OS control remains with Microsoft, so for workloads requiring complete administrative control, a SQL Server on an Azure VM is the appropriate choice.

It only supports the open-source community edition of PostgreSQL.

Why wrong: This statement is incorrect because Azure Database for PostgreSQL is not restricted to only the open-source community edition. While it is built on the community edition of PostgreSQL, it also supports the Citus extension, which transforms the service into a distributed database that can scale out horizontally across multiple nodes. Additionally, other extensions such as PostGIS are supported, so the service is not limited to just the base community edition functionality.

It is a NoSQL database service.

Why wrong: This is incorrect because Azure Database for PostgreSQL is a fully managed relational database service, not a NoSQL database. It uses the PostgreSQL relational engine, which organizes data into tables with predefined schemas, supports ACID transactions, and uses SQL for querying. NoSQL services like Azure Cosmos DB offer schema-less, non-relational data models, which are fundamentally different from PostgreSQL's relational model.

It allows cross-database queries across multiple servers.

Why wrong: This is incorrect because cross-database queries in Azure Database for PostgreSQL are limited to databases residing on the same server. The service does not allow queries that span across multiple independent server instances. To query data from multiple servers, you would need to use external tools, data integration pipelines, or implement application-level logic to combine the results, rather than using a native cross-server query feature.

Geo-redundant storage (GRS)

Why wrong: Geo-redundant storage (GRS) is a data-replication setting available to any Azure Storage account, including standard Blob Storage and Data Lake Storage Gen2, so it is not a distinguishing feature. GRS copies data synchronously within a primary region and asynchronously to a secondary region to protect against regional outages, but this redundancy is independent of the hierarchical namespace. Marking it as a Data Lake feature confuses an infrastructure-replication option with the file-system-specific capabilities that make Data Lake Storage Gen2 unique.

Fixed-size block storage

Why wrong: Fixed-size block storage is not a feature of Azure Data Lake Storage Gen2; it describes a storage-account tier for virtual machine disks (Azure managed disks or page blobs) that is optimized for low-latency I/O. Data Lake Storage Gen2, in contrast, is built on Blob Storage and organizes data using a hierarchical namespace with ACLs and directory semantics, not fixed-size blocks. Additionally, Gen2 blob writes are append- or block-based depending on blob type, but they never rely on fixed-size block allocation as a file-system feature.

Azure Blob Storage

Why wrong: Azure Blob Storage is an object store designed for unstructured data such as files, images, and backups, not for querying time-series records. It lacks native indexing, time-based partitioning, or a query engine capable of slicing data by time ranges at interactive speed, so any time-series analysis would require exporting data to a separate platform like Azure Data Explorer or a data warehouse. Its append-only nature can store raw logs, but it is not a direct queryable time-series solution.

Azure Redis Cache

Why wrong: Azure Redis Cache is an in-memory key-value store primarily used for caching and session state, not for persistent time-series storage. Although Redis supports sorted sets and time-series modules, it holds data in RAM, which is costly and limited in capacity, and unless persistence is explicitly configured, data is lost on restart. It cannot handle the volume and durability requirements of a long-term time-series solution, and query capabilities are far less analytical than dedicated time-series engines.

Azure SQL Database

Why wrong: Azure SQL Database is a row-based relational database with transaction overhead and indexing requirements that make it inefficient for high-ingestion, append-only time-series workloads. While you can store timestamps and use clustered indexes, every insert incurs row and index maintenance, and analytical queries over large time ranges can suffer from high I/O and lock contention. It is better suited for operational data with relationships than for the high-volume, low-latency writes and time-window analytics typical of time-series data.

Use the same partition key for all items

Why wrong: Assigning a single partition key to every item collapses all data into one logical partition, which Cosmos DB caps at 20 GB and which cannot exceed the throughput allocated to that one partition. All read and write requests target the same physical replica, creating a hot partition and causing 429 throttling under load. This approach forfeits horizontal scale because the request rate and storage are bounded by a single partition rather than distributed across many.

Keep partition key values as small as possible

Why wrong: The physical length of a partition key value affects item metadata and storage overhead, but it does not determine how requests are spread across physical partitions. A small partition key such as a two-character code has pitiful cardinality, so all documents sharing that value still land in one partition and cause hot spots. Distribution depends on the number of distinct values and their request frequency, not on whether the key is short.

Azure SQL Database

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

OLTP and OLAP

Why wrong: Incorrect. OLTP and OLAP are database-focused terms; while they can relate, they are not the best descriptors for these processing workloads.

Online processing and offline processing

Why wrong: Incorrect. 'Online processing' and 'offline processing' are often used in networking contexts and do not accurately describe the data processing patterns in this scenario.

Transactional processing and analytical processing

Why wrong: Incorrect: Transactional processing describes OLTP business transactions, not real-time sensor streams. Analytical processing only covers the historical reporting half, so this pair does not correctly describe the first system.