CCNA Core Data Concepts Questions

Immutable storage with a time-based retention policy enforces a WORM (write-once, read-many) state at the container level. Once the policy is configured with a retention interval, blobs cannot be overwritten or deleted until that interval expires, and the retention period cannot be shortened. For patient records, this guarantees non-erasable, non-modifiable storage that directly satisfies regulatory and compliance mandates.

Batch processing collects and processes retail sales data over a defined time window (e.g., nightly, weekly), making it ideal for business intelligence reports that summarize historical trends. It offers high throughput, predictable costs, and easy recomputation/retry, which suits periodic reporting rather than immediate action. This matches the scenario's need to produce reports from accumulated transactional data.

Azure Data Lake Storage (ADLS) Gen2 is the optimal landing zone for raw clickstream data because it combines a hierarchical namespace with POSIX access control and is natively integrated with Azure analytics services, allowing schema-on-read processing where the JSON structure is interpreted at query time. After ingestion, the raw data can be transformed and loaded into Azure SQL Database as aggregated, relational tables with defined primary keys and indexes, enabling fast T-SQL queries for BI dashboards and reporting. This separates the cheap, flexible storage of unprocessed data from the tuned, structured environment relied on by operational reporting.

AzCopy is a dedicated command-line utility engineered specifically for high-performance, resumable copying between on-premises storage and Azure Blob Storage or Azure Files. It automatically partitions files, spawns multiple concurrent connections to maximize throughput, validates data integrity with checksums, and can resume from a checkpoint if a transfer is interrupted. For moving 500 GB of CSVs, AzCopy provides the simplest and most efficient online solution with one command such as azcopy copy.

Materialized views (preview) in Azure Cosmos DB are the correct feature because they let you define a view as a query over a source container, and the service automatically maintains a separate, denormalized container with the query results. This view is updated incrementally when source data changes and is optimized for read-heavy or common-query scenarios, reducing latency and cost. By pre-computing and storing the results, materialized views directly fulfill the requirement for a built-in, automatically refreshed mechanism.

Structured data conforms to a predefined schema of rows and columns, which is exactly what the transit authority describes: route number, month, and total passenger count. This format supports reliable aggregate queries such as summing riders per route. Relational tables in Azure SQL Database or a dedicated SQL pool in Azure Synapse Analytics are designed for this workload.

Correct. A relational table is fully structured because it enforces a fixed schema: predefined columns, data types, and constraints that make every row uniformly queryable. JSON is semi-structured because it uses flexible key-value pairs and nesting that organize data but do not require the same rigid schema. JPEG images are unstructured because their binary pixel encoding has no inherent schema or fields that a database can query directly, so the correct order is structured, semi-structured, unstructured.

CustomerKey has high cardinality and is frequently used in joins, making it a good distribution column. Each customer has many sales transactions, so hashing on CustomerKey spreads rows evenly across distributions and reduces data skew. In Azure Synapse dedicated SQL pool, this also enables collocated joins with the customer dimension, minimizing data movement during queries.

Structured data is the correct classification because the CSV order file has a predefined tabular schema: a header row defines fixed column names and each subsequent row represents one order with values aligned to those columns. Because every record follows the same field order and logical data types, it can be loaded directly into a relational table and queried with SQL, which are the hallmarks of structured data.

Azure Cosmos DB is a fully managed NoSQL database explicitly built for JSON documents, offering native JSON support with automatic indexing of all properties. It provides guaranteed low latency (single-digit milliseconds) at any scale, coupled with turnkey global distribution across multiple Azure regions, enabling active-active configurations. Its SQL API allows rich querying over JSON documents using familiar syntax, and it supports multiple consistency models to balance performance and data correctness. This makes it the optimal choice for storing and querying JSON documents with global reach.

This is correct because the first workload requires continuous, low-latency computation over an unbounded sequence of stock trade events; calculating moving averages demands real-time windowing and stateful aggregation as each event arrives, which is the defining characteristic of stream processing (e.g., Apache Kafka, Azure Stream Analytics). The second workload processes a finite, already-completed CSV file generated at end of day, a classic batch job executed on a schedule with high throughput and no requirement for sub-second latency; this distinguishes it as batch processing (e.g., Azure Data Factory, Azure Databricks).

Notebooks in Microsoft Fabric are the recommended code-based interface for working with Apache Spark, and they natively support popular languages like Python, Scala, and SQL. They can read raw data from files, apply transformations, and write results to Delta Lake tables within a lakehouse, leveraging ACID transactions and efficient upserts. Because the scenario explicitly calls for Spark and building a data lake, notebooks are the correct tool for executing event-driven or ad-hoc transformation logic directly on the compute engine.

Batch processing refers to processing data in large batches, while real-time processing handles data as it arrives. The order processing is transactional, not necessarily real-time analytics, and the weekly reports are batch, but 'batch' and 'real-time' are not the precise terms for workload types.

Azure Cosmos DB is a globally distributed, multi-model NoSQL database that offers turnkey distribution across any number of Azure regions, multi-region write support, and single-digit millisecond read and write latencies at the 99th percentile. It also guarantees ACID transactions within a single logical partition using transactional batches or stored procedures, making it the right fit for a global e-commerce platform that needs both low-latency point lookups and data consistency.

Azure IoT Hub ingests device telemetry, Stream Analytics transforms it in real time, and Azure Data Explorer stores and queries time-series data at scale. This combination satisfies the streaming ingestion, real-time transformation and time-series storage requirements.

Structured data conforms to a predefined schema, typically organized into rows and columns within a relational database. The transaction dataset with named columns (e.g., TransactionID, CustomerID, ProductID, Quantity, TotalAmount) and consistent data types fits this model exactly. This structure enables efficient SQL querying, indexing, and transactional integrity, making it the correct classification for customer transaction data.

Creating external tables with a partition elimination strategy and partitioning the data by date lets the serverless SQL engine skip whole file ranges that do not satisfy the query's predicate, for example when a WHERE clause filters on a date column. You should store the data in a hive-style layout such as /orders/year=2024/month=03 and define the external table so the engine can map the folders to partition columns. This reduces the byte count scanned dramatically and is the biggest lever for performance and cost in a serverless SQL pool.

Row-level security is a native security capability that limits row access through an inline table-valued predicate function and a security policy. It can use SESSION_CONTEXT or user identity to return only authorized rows, protecting sensitive data without requiring application-layer WHERE clauses. Thus Security is the correct category for this feature.

Structured data is organized with a fixed schema; the integer, text, and date columns all have a fixed type and format. The Photo column contains binary image data with no inherent structure, making it unstructured data.

Structured data relies on a predefined schema, meaning the logical model—including column names, data types, and integrity constraints—is designed before any data is written. This schema-on-write approach enforces consistency and validity at ingest time, allowing databases to optimize indexes, partitions, and query plans. Because the schema is fixed, every record must conform, which makes structured data highly predictable and reliably queryable.

This is correct. Customer data lives in relational tables where each row is a record and each column has a fixed data type, giving it a strict schema and making it fully structured. Product images, such as JPEG files, contain encoded pixel data with no inherent row/column structure and cannot be directly queried with SQL; they are stored as binary blobs and are classified as unstructured data.

Azure Event Hubs is a fully managed real-time data ingestion platform that accepts millions of events per second via AMQP, HTTPS, and Kafka protocols. It provides partitioned, ordered event buffering with configurable retention, enabling publishers to send streaming data and consumers (e.g., Stream Analytics, Functions) to process it with sub-second latency. As the entry point for telemetry, it is the foundational service for real-time pipelines.

Azure Event Hubs is a fully managed event streaming platform built for high-throughput telemetry, capable of ingesting millions of events per second across partitioned consumer groups. It supports checkpointing to track processing progress, allowing at-least-once delivery that, when combined with idempotent consumers, enables effectively exactly-once processing. Its design as a distributed log with sequential writes and parallel reads makes it the right choice for massive ingestion workloads.

OPENROWSET is a T-SQL function available in the built-in serverless SQL endpoint that reads files directly from Azure Data Lake or Blob storage without loading them into a database. You can query CSV, Parquet, JSON, and Delta Lake files by specifying a path and optional WITH clause for schema; the engine processes only the requested data and you pay only for the data scanned. This is the optimal choice for an ad-hoc query because no compute pool, external table, or pipeline must be provisioned beforehand.

Patient records are structured because the relational model imposes a predetermined schema: each row is a record, each column is an attribute with a defined data type, and relationships are enforced via keys. Clinical notes are unstructured because they are free-form natural language—physicians type observations, diagnoses, and treatment plans with no fixed length, order, or columnar organization. This distinction is fundamental to choosing appropriate storage and analytics tools.

Transaction rows fit a predefined relational schema with typed columns, making them structured data. PDF sales reports have no fixed schema and are stored as whole documents, making them unstructured. This distinction matches the stem's split between relational transaction records and PDF files.

Azure Cosmos DB is correct because it is a globally distributed, multi-model NoSQL database that provides a key-value API along with single-digit-millisecond read and write latency, which directly satisfies a mobile app's need for fast, scalable access. It also offers SDKs for iOS and Android, turnkey global distribution, and multiple consistency levels, enabling low-latency access from any region and supporting offline or sync-based scenarios.

Atomicity guarantees that a transaction's operations are executed as an all-or-nothing unit. If the $100 debit from one account succeeds but the $100 credit to another account fails, atomicity requires the entire transaction to be rolled back, returning the database to its pre-transaction state. Without atomicity, a partial transfer would leave the bank with inconsistent balances and potential lost or duplicated funds.

Durability is the ACID property that guarantees once a transaction is committed, its changes are permanently recorded in non-volatile storage, even if a crash occurs immediately afterward. In a money transfer scenario, the updated balances in both the source and destination accounts must survive a power loss, disk failure, or system restart to prevent the transferred funds from disappearing. This is implemented via write-ahead logging or journaling (e.g., SQL Server transaction log), where commit records are forced to disk before the transaction is acknowledged as successful.

A relational database is the best fit because it stores customers and order history in separate, normalized tables linked by foreign keys, such as a customer ID. ANSI SQL supports JOIN operations to combine these tables on demand, so you can query a specific customer's details alongside all their past orders. Enforcing a defined schema and referential integrity ensures names, addresses, and order records remain consistent and accurate. This matches the structured, transactional nature of customer/order data.

Changing the SKU name to Standard_GRS switches the storage account to geo-redundant storage, which synchronously copies your data three times within the primary region and then asynchronously copies it to a paired secondary region. If the primary region becomes unavailable, Azure can fail over to the secondary copy, so data survives a regional outage. This directly meets the ARM template requirement for higher durability across regions.

In this healthcare scenario, Atomicity guarantees that a multi-step transaction—such as writing a patient diagnosis, associated medications, and lab results together—either commits all changes to the medical history or rolls back completely. If any statement in the transaction fails, the database discards all earlier writes, leaving the patient record untouched. This all-or-nothing behavior directly matches the requirement that incomplete updates never appear, which is why Atomicity is correct. Azure SQL Database uses a transaction log and rollback segments to enforce this property even when the service fails mid-transaction.

Azure Files is a fully managed file share service that provides Server Message Block (SMB) and Network File System (NFS) protocols, enabling typical network-mounted drive access from multiple VMs or on-premises clients. It is a valid Azure data storage option because it stores files in a shared, persistent manner, similar to a traditional file server but without the maintenance overhead. This differentiates it from block or object storage, making it the correct answer for scenarios requiring file-level access and standard file-sharing protocols.

This pairing is correct because the product table resides in a relational database where each row maps to a fixed set of typed columns, making it structured data. Customer reviews stored as JSON documents contain key-value pairs and nested objects that can vary between records, which is the defining characteristic of semi-structured data. JPEG images are stored as compressed binary files that have no inherent row, column, or field structure, so they are unstructured. Together, these three categories accurately reflect the data-types question being tested.

The hierarchical namespace is a creation-time flag that organizes blobs into directories and nested folder structures, enabling Azure Data Lake Storage Gen2 features like POSIX-like ACLs, atomic directory renames, and higher-throughput analytics workloads. This property cannot be changed after the storage account is provisioned, so it must be set during deployment. Unlike versioning or soft delete, which are optional post-creation protections, this namespace fundamentally changes the account's data model, making it the correct capability referenced in the exhibit.

Atomicity, consistency, isolation, and durability, collectively ACID, guarantee that a trade either commits fully or not at all and survives node failure. Foreign key constraints enforce the referential integrity between trade and account tables. This combination is the defining strength of relational engines such as Azure SQL Database, which is why it matches the firm's requirements.

NoSQL databases store documents, key-value pairs, or graphs without a fixed relational schema, so each record may carry different fields. This satisfies the stem's requirement for a common characteristic: schema flexibility lets developers evolve data structures without migrations, unlike rigid tabular models in relational systems.

Transparent Data Encryption (TDE) automatically encrypts Azure SQL Database data and log files at rest using AES-256, requiring no changes to existing applications or schemas. Enforcing TLS 1.2 as the minimum connection protocol ensures all data is encrypted in transit between the client and the database server. Together, these features provide comprehensive encryption with minimal administrative overhead, making this the correct answer for this requirement.

A primary key is the column or set of columns declared to hold a unique, non-null value for every row, and it serves as the table's authoritative identifier for each entity record. For an employee table, an EmployeeID column or a composite of first name, last name, and birth date would be a primary key because it guarantees that each employee row can be individually referenced, updated, or joined to related tables. This is the fundamental relational mechanism for row identity and is what other tables use when they need to reference a specific employee.

Enabling read scale-out by adding the 'readScale' property to your ARM template routes read-only connections to an automatically provisioned read-only replica. This offloads read-heavy query load from the primary replica, freeing up its CPU, memory, and I/O for write operations and transactional workloads. This is the only option that directly improves query performance by scaling out the read path, especially for workloads that separate reporting or analytical queries from OLTP traffic.

Azure Cosmos DB is a globally distributed, multi-model NoSQL database that supports document, graph, column-family, and key-value data models through APIs like SQL (the Cosmos DB core API), MongoDB, Cassandra, Gremlin, and Table. Its schema-agnostic, horizontally scalable architecture is explicitly designed for NoSQL workloads, making it one of the two correct NoSQL services.

Structured data is defined by a rigid, predefined schema, which means each record conforms to a specified set of columns with fixed data types. This tabular format—rows and columns—enables relational database features such as ACID transactions (atomicity, consistency, isolation, durability), primary/foreign key constraints, and efficient SQL querying. The schema is enforced at write time, so every inserted row matches the expected structure, making it the foundational model for transactional systems like online order processing.

Azure SQL Database with active geo-replication maintains asynchronous, readable secondary replicas in paired or other Azure regions, preserving a mature relational database engine with full ACID transactions on the primary. This design provides a geographically distributed read scale and enables a controlled failover to a secondary region if an outage occurs, delivering a strong high-availability and disaster-recovery posture for a business-critical e-commerce application. The secondaries can also serve read-only traffic, offloading workload from the primary, while writes remain on the primary to maintain consistency.

Azure Cosmos DB with multi-master configuration and partition on user ID is correct because it provides active-active multi-region writes, 99.999% availability, and tunable consistency with single-digit millisecond latencies at the 99th percentile. Using user ID as the partition key co-locates all posts from one user on the same logical partition, enabling efficient queries and scalable writes. Multi-master lets users write to the nearest region while Cosmos DB reconciles conflicts, which is exactly what a high-throughput, globally distributed short-text app needs.

A data lake is a centralized repository that stores raw data in its native format, from IoT sensor streams to structured files, without requiring a predefined schema. It employs schema-on-read, so data scientists can explore and run ad-hoc analytics before defining structure. This makes it ideal for diverse, high-volume streaming data where format and meaning may evolve over time.

User profiles are semi-structured because JSON documents allow variable attribute sets—some users may have 'verified' while others have 'pronouns'—so there is no fixed schema, but the data still carries self-describing key-value pairs. Posts, in contrast, are stored in a fixed relational schema with consistent columns such as post_id, user_id, content, and created_timestamp, making them classic structured data. This combination makes the statement correct.

Fixed-schema tables with defined columns and typed values are structured data, typically stored in relational databases. The explicit ProductID, ProductName, QuantityInStock and ReorderLevel columns fit the relational model, so structured classification applies rather than semi-structured or unstructured.

Atomicity maps to all-or-nothing rollback (3), consistency to valid-state transitions obeying rules (4), isolation to serialised concurrent execution (1), and durability to committed changes surviving failures (2). Each pairing matches the standard ACID definition precisely.

Azure SQL Database is a fully managed relational database engine that provides built-in features such as automatic backups, high availability, and strict ACID transaction guarantees, making it ideal for capturing e-commerce orders, inventory, and payments. Azure Synapse Analytics is a limitless analytics service that separates storage from compute and uses a massively parallel processing (MPP) architecture to run complex queries over trillions of rows, with built-in integration for data lakes, pipelines, and Power BI. This combination cleanly separates the operational and analytical layers, letting each service optimize for its own workload.

Patient records in a relational database have a fixed schema of columns and data types, so they are structured. DICOM files contain header fields with standardized metadata tags plus pixel data, which fits the semi-structured category because they have an organized structure but not a rigid tabular schema. Clinical notes are free-form text written by clinicians, lacking any predefined format, so they are unstructured. This combination correctly maps each data type to its storage and query characteristics.

Hourly scheduled execution reading accumulated orders, aggregating, then writing results is batch processing: bounded input sets processed as discrete jobs on a schedule. Streaming would process continuously per event, which the stem's hourly trigger and previous-hour window exclude.

Azure Synapse Serverless SQL pool is the correct service because it provides a serverless, on-demand T-SQL query engine that runs directly against files in Azure Data Lake Storage. It allows you to query data in place using standard T-SQL without provisioning or managing dedicated infrastructure, and you are billed only for the amount of data processed per query. It supports a variety of file formats such as Parquet, JSON, and CSV, enabling complex analytics and join operations across the data lake. This exactly meets the company's need for running complex analytics queries across petabyte-scale data with a familiar SQL interface.

Every asset shares the same fields, and the company explicitly wants DurationSeconds constrained to numeric and AssetID to be unique. A relational database enforces column data types and unique or primary key constraints declaratively. This uniform, well-defined structure is exactly the situation where a relational schema provides value, rather than the flexible schemas used by non-relational stores.

Azure Data Factory is a fully managed, code-free ETL/ELT and orchestration service built specifically for ingesting data from many sources, including on-premises databases, and moving it to cloud destinations. It provides scheduled triggers, pipeline dependencies, and a self-hosted integration runtime for secure hybrid connectivity, enabling reliable incremental loads of sales transactions by using watermark columns or change tracking mechanisms. This makes it the correct choice for designing a production-grade data pipeline.

Stream processing handles data continuously as it arrives, applying transformations and analytics within seconds rather than waiting for batches. This matches the requirement to process sensor readings immediately for anomaly detection and alerting, unlike batch processing, which introduces latency unsuitable for real-time monitoring.

Atomicity treats the transfer as a single indivisible unit: both the debit from one account and the credit to another must succeed together. If any operation fails or the system crashes mid-transaction, the database rolls back to the pre-transaction state, so the partial debit is undone. This ensures no orphaned or incomplete financial entry persists.

Unstructured data has no predefined schema or data model, consisting primarily of free-form text, images, videos, and audio. Social media feeds are a classic example because posts combine casual text, photographs, hashtags, links, and other media with no enforced structure. This makes them ideal for schema-on-read analytics and storage in data lakes rather than in relational databases.

The enrollment records have a fixed set of fields, StudentID, CourseID, and Grade, applied uniformly to every record. That predefined, uniform schema is the defining trait of structured data. It enables efficient joins, constraints, and aggregate queries in a relational engine such as Azure SQL Database, which is why this classification is correct for the enrollment dataset.

Customer records from a relational database are textbook structured data: fixed columns, enforced data types, primary keys, and SQL-based querying all depend on that rigid schema. JSON posts are semi-structured because each record is self-describing, containing named keys, arrays, and nested objects even though fields can vary between posts. Images of handwritten notes are unstructured—they consist of raw pixels with no inherent fields, keys, or tabular order. This option correctly labels all three sources, which is why it is the correct answer.

This design is the industry-standard dimensional model for data warehousing, consisting of a central fact table that stores numeric measures and foreign keys, surrounded by denormalized dimension tables that describe business entities. It minimizes redundancy because each dimension attribute is stored once, while the fact table remains lean and scalable. Queries benefit from star join optimizations, efficient use of columnstore indexes, and the ability to pre-aggregate facts at different grain levels. In Azure Synapse Analytics, designers can hash-distribute fact tables on a key and replicate dimension tables to reduce data movement, directly improving analytical query performance.

Structured data is information that conforms to a fixed schema, typically represented in tables with defined columns and rows. This is the fundamental format used by relational database management systems, where each table has a predetermined set of attributes and data types. If the question describes information with an explicit, predefined structure, structured data is the correct classification.

Immutable blob storage applies time-based retention or legal hold policies, preventing modification or deletion for a specified period. This satisfies the healthcare scenario's seven-year regulatory requirement for records that cannot be altered or removed, enforced at the storage layer.

Azure Stream Analytics is a fully managed, real-time data stream processing engine that can continuously ingest events from Azure Event Hubs, IoT Hub, and Blob Storage, then apply time-windowed SQL-like queries without infrastructure management. It supports sub-second to minute-level latencies, event ordering and late-arrival handling, and can produce alerting, dashboards, or aggregated results in real time. Because it is purpose-built for streaming data, it is the appropriate choice for the retail company’s requirement to run real-time analytics on a live stream rather than storing and batch-processing it later.

In a relational database, patient records are assigned to tables with predefined columns and data types, such as integer IDs, VARCHAR names, and DATE fields, making them structured data that can be queried with SQL. Radiology images, by contrast, are stored as DICOM binary files containing raw pixel data; they lack a schema and cannot be queried directly, so they are unstructured. This distinction drives storage choices, such as using SQL for records and BLOB/object storage for images.

Power Query is the data transformation and connectivity engine built into Power BI Desktop, Excel, and other products. It lets analysts connect to Azure SQL Database, preview and shape the data, and then combine it with other sources using merge (join) or append (union) operations. Its M language provides precise control over transforms before data is loaded into the model, making it the correct direct tool for combining sales data.

Parquet is a columnar storage format that groups values by column, enabling modern compression techniques like dictionary and run-length encoding to dramatically reduce storage footprint. Analytical engines can push predicate filters and column projections down to the file layer, reading only the needed columns and row groups, which minimizes I/O and query latency. This design makes Parquet the optimal choice for large analytical workloads in Azure, including Azure Synapse, Databricks, and Data Lake Storage.

Azure Stream Analytics is a fully managed stream processing engine that natively supports real-time ingestion from Azure Event Hubs and IoT Hub. It provides sub-second latency via continual SQL-like queries over temporal windows, and it has a built-in Power BI output adapter, making it ideal for live dashboards. Unlike batch tools, it executes queries continuously on unbounded streams, delivering results as events arrive.

A time-based retention policy, often implemented as immutable blob storage, locks data in a write-once, read-many (WORM) state for a specified interval, preventing modification or deletion until that interval elapses. In Azure, you set a retention period in days or years, and the service enforces the policy globally, blocking any attempts to overwrite or remove the data. This satisfies the healthcare requirement to preserve patient records for exactly seven years, after which deletion is allowed.

Atomicity is the ACID property that treats a transaction as a single, indivisible unit of work. If any statement within the transaction (such as updating inventory or recording the order) fails, the entire transaction is rolled back, leaving the database exactly as it was before the transaction began. This all-or-nothing behavior prevents partial updates, ensuring that a customer order is either fully recorded or not recorded at all.

This classification is correct because each data type is matched to its intrinsic format. Customer orders in a SQL table have a fixed schema with rows and columns, enforcing structured data. XML files use custom tags and a hierarchical tag-based format that does not require a rigid relational schema, making them semi-structured. Video files are binary streams with no predefined data model or queryable structure, so they are unstructured.

CSV is the most structured because it enforces a tabular schema—every row has the same ordered columns and each field is a scalar value. JSON is semi-structured: it uses named key-value pairs and can nest arrays/objects, but no fixed schema is required and structure can vary per record. JPEG is unstructured: its binary encoding represents compressed pixel data, not queryable fields or relationships. Ordering them most-to-least structured therefore must place CSV first, JSON second, and JPEG last.

Configuring a retry policy on the failing activity causes Azure Data Factory to automatically re-attempt the operation when it detects an error, and adding exponential backoff spaces out those attempts so the transient condition (such as throttling or a temporary service outage) has time to clear. With a retry count and interval set on the activity, you avoid hard failures caused by intermittent issues without manual intervention. This is the standard, directly-scoped solution for transient errors in ADF pipelines.

This correctly distinguishes the two workloads. Order processing captures discrete, high-frequency events such as placing an item in a cart and confirming payment, which are classic OLTP transactions requiring atomicity and low latency. Weekly reporting, by contrast, reads and aggregates large volumes of historical order data across the week to produce revenue summaries, a classic OLAP analytical workload.

Configuring a read replica in Azure SQL Database creates a separate, readable secondary instance that handles reporting and analytical queries without consuming the primary's CPU, I/O, or locks. Azure SQL Database's active geo-replication or built-in read scale-out allows the replica to maintain a transactionally consistent (though potentially slightly delayed) copy of the data, enabling reporting workloads to run alongside OLTP without interference. This is the correct approach because it physically isolates the reporting load from the transactional database engine.