CCNA Describe considerations for working with non-relational data on Azure Questions

Correct. Azure Synapse Serverless SQL pool is a query engine that reads data directly from Azure Blob Storage or Azure Data Lake Storage using the OPENROWSET function. You can issue standard T-SQL with OPENROWSET to read the JSON files and parse them with OPENJSON, all without provisioning any dedicated infrastructure. Billing is per amount of data scanned, making it ideal for occasional or interactive analysis over IoT sensor data in Blob.

This lifecycle strategy aligns storage cost with data access patterns: the Hot tier supports frequent reads during the first 30 days when imaging files are actively used, the Cool tier lowers cost during the subsequent infrequent-access period, and the Archive tier provides the least expensive long-term retention after 5 years during which the data is rarely needed. Applying lifecycle management automates the transitions, avoiding both the high storage cost of keeping files in Hot for years and the retrieval latency of Archive for files that are still being accessed.

UserID is the correct choice because it is unique and high-cardinality, producing many small, evenly distributed logical partitions that scale horizontally without hot spots. When UserID is both the partition key and the item ID, a profile lookup is a point read: Cosmos DB computes the partition from the value and reads a single document directly, consuming the fewest request units (RUs) and lowest latency. Any other partition key would force queries for a known UserID to fan out across multiple physical partitions, so UserID satisfies both even distribution and the application's dominant access pattern.

Table Storage's underlying engine physically orders entities by partition key and row key, and it automatically creates a clustered index on this composite key. This design makes equi-joins or range scans on these keys extremely fast because the server can navigate directly to the matching rows without scanning unrelated data. In contrast, Blob Storage has no key-based query capability; blobs are located by container and name, not by user-defined key pairs.

Customer-managed keys stored in Azure Key Vault let the customer create, rotate, and revoke the encryption keys used by Azure Storage, giving them the ability to cryptographically erase data and meet key-control compliance demands. Azure Defender for Storage continuously analyzes storage account telemetry to detect suspicious activities such as anomalous access patterns, privilege attempts, and known malware, then raises alerts or triggers automated mitigation. Together these two services address both requirements: customer-controlled encryption plus active threat detection.

Correct. The Core (SQL) API provides a SQL-like query language, supports point reads and range queries, and enables multi-region writes for global distribution.

ST_WITHIN is the correct geospatial operator here because it accepts a GeoJSON Polygon representing the bounding box and uses Cosmos DB's spatial index to efficiently find all location points contained inside it. Adding a separate WHERE clause on the speed field is a non-spatial predicate that is applied after the spatial index seek narrows the result set, which minimizes request units (RUs) and latency.

User ID is the optimal partition key because it is a high-cardinality attribute that appears in nearly every query for a social media application, such as 'retrieve all posts by a user' or 'find posts by a user within a date range'. It distributes documents evenly across logical partitions to avoid hot partitions, and because each physical partition can store up to 20GB, even high-volume users' posts are typically collocated for efficient range reads with minimal routing cost. A well-chosen partition key like User ID ensures that point reads and queries scoped to a single partition consume fewer RUs and avoid cross-partition fan-out.

Cosmos DB exposes five well-defined consistency levels—Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual—that can be selected per request. This tunable consistency model lets developers trade between strict linearizability and lower latency or higher availability, which is a distinct advantage over Table Storage's fixed consistency semantics. The availability of multiple consistency levels is a core architectural consideration when designing globally distributed data solutions.

Azure Cosmos DB is a globally distributed, multi-model NoSQL database service that stores data as schema-agnostic JSON documents, making it a natural fit for a product catalog. It provides turnkey global distribution across Azure regions, automatic indexing of all properties, and read and write latencies in the single-digit milliseconds at the 99th percentile. Cosmos DB also offers multiple consistency levels (strong, bounded staleness, session, consistent prefix, eventual) so you can tailor data freshness versus performance. For a retail catalog that must be always available and queried at scale, Cosmos DB's document API and dedicated throughput (RU/s) deliver both flexibility and predictable performance.

In Azure Cosmos DB, a query's RU cost and latency heavily depend on whether its filter includes the partition key. When the WHERE clause lacks the partition key, the request cannot be routed to a single physical partition, so the query is fanned out to every partition and scans each one for matching documents. This cross-partition scan multiplies the amount of data read and the RU consumption, and it also introduces network round-trips across partitions, which is why the query is slow and expensive. Including the partition key in the filter would constrain the query to one partition and avoid this overhead.

Azure Cosmos DB is the correct choice because it is a natively schema-agnostic, multi-model NoSQL database. It stores JSON documents as first-class items in an indexable, physically contiguous format, and its SQL-like query engine can directly reference nested JSON properties without any pre-defined table structure. Documents with completely different fields can sit side-by-side in the same container, and the service also provides global distribution, multiple consistency levels, and tunable indexing to meet operational requirements.

Rotating an Azure Storage account access key immediately invalidates every SAS token whose signature was computed with that key, because the signature is a keyed hash that can no longer be verified. This provides a definitive way to revoke the user's images access without deleting any data, though it also revokes all other SAS tokens that used the same key, so new tokens must be issued to legitimate users. The account key is the root credential for all types of SAS tokens, making this the most forceful revocation mechanism available.

UserID is the natural partition key because it groups every preference row for a single user into the same partition, allowing their data to be retrieved with a fast, single-partition query. This design also enables entity group transactions, so multiple preference updates for a user can be applied atomically. Since each user forms a distinct, evenly distributed partition when user IDs are varied, it avoids hot partitions while matching the application's primary access pattern.

Blob index tags are user-defined key-value pairs that Azure stores as metadata on each blob and maintains in an internal searchable index. You can query blobs using the Find Blobs by Tags API, filtering on tags such as deviceID and sensorTimestamp, without needing to ingest the blob content or scan containers. This is exactly the capability needed to retrieve IoT sensor blobs by device and time criteria.

Azure Cosmos DB Core (SQL) API is a multi-model NoSQL database service that natively stores JSON documents with flexible schemas. It automatically indexes every property without requiring explicit schema definitions, so you can run SQL-like JOINs, projections, and filters on any attribute while retaining single-digit-millisecond point reads via a well-chosen partition key. This makes it the ideal choice for player profiles that vary in structure and are accessed frequently by player ID.

GameID directly matches the query predicate, so all score documents for a given game are stored contiguously on the same logical partition. A query filtering on GameID is a single-partition query, which is the most RU-efficient and lowest-latency pattern in Azure Cosmos DB. GameID also offers sufficient cardinality and activity distribution to avoid hot partitions.

Azure Cosmos DB NoSQL API stores documents natively as JSON, and its SQL-like query syntax (SELECT * FROM c WHERE c.userId = @id AND c.timestamp > @time) is directly optimized for these documents. The API auto-indexes every property, enabling efficient range scans on timestamp and equality filters on userId without manual index tuning. This makes it the most natural fit for a social media post store requiring flexible schemas and rich queries.

Eventual consistency provides the weakest guarantee but the lowest read latency. Reads are served from any replica without waiting for write propagation, making it ideal for read-heavy workloads where immediate consistency is not required.

Azure Cosmos DB is purpose-built for globally distributed, horizontally scalable key-value workloads. It offers turnkey multi-region replication with multiple consistency models, automatic indexing, and single-digit-millisecond reads/writes at any scale, so user session data can be read and written from any Azure region with low latency. Its partition-key-based design maps directly to session IDs, and its SLA-backed availability and tunable consistency make it the correct durable, globally distributed store for this scenario.

Azure Blob Storage lifecycle management policies are the correct choice because they automate the transition of blobs across Hot, Cool, Cold, and Archive tiers based on age conditions such as 'last modified more than 90 days ago'. Administrators define JSON rules that move backup files to cooler, cheaper storage and optionally purge them after a retention period. This reduces cost with zero ongoing manual effort and integrates directly with backup workloads.

Azure Blob Storage is a fully managed, massively scalable object store that is the correct choice for storing and serving large numbers of image files, such as those posted on a social media platform. It provides extremely high throughput, supports storage tiers for optimizing cost, and can serve blobs directly via HTTP/HTTPS, enabling straightforward use with CDNs for low-latency access worldwide. Blobs can be accessed using REST APIs and SDKs, making it ideal for unstructured binary data.

A Blob Storage lifecycle management policy is the correct tool because it lets you define rule-based actions that automatically transition blobs to cooler tiers (hot to cool, cool to archive) and expire them after a specified number of days since last modification. For sensor data that becomes less frequently accessed over time, this is the native, cost-optimized mechanism to enforce retention and deletion without manual intervention or additional services.

Correct. This combination provides cost-effective storage and serverless SQL querying without infrastructure management.

The SQL API provides native support for JSON documents, low-latency point reads by partition key (playerId), and the ability to run SQL-like queries on document fields such as achievements.

Azure Cosmos DB is correct because it is a multi-model NoSQL database with native JSON document support, schema-agnostic ingestion, and horizontally scaled partitions. It provides single-digit-millisecond reads and high write throughput at any scale, which is ideal for high-frequency device telemetry. Time-series data can be partitioned by device ID or timestamp, and SQL-like queries are supported. This directly matches the requirement for low-latency reads of JSON telemetry.

Azure Synapse Serverless SQL enables direct querying of JSON blobs stored in Azure Blob Storage using T-SQL. This service allows users to create external tables or utilise `OPENROWSET` to query the data *in situ*, eliminating the need to move or ingest it into a separate database. This capability directly satisfies the constraint of querying the data using SQL statements without moving it from its current storage location, providing a flexible and cost-effective solution for ad-hoc analysis.

A composite index on (deviceId ASC, timestamp DESC) exactly matches the query pattern: it lets the query engine seek on the deviceId equality predicate, then perform a contiguous descending scan on timestamp for the range condition. Because the index is already sorted in the requested timestamp order, the results can be streamed without a separate SORT operator, reducing CPU and request-unit cost. The ASC on deviceId supports equality and the DESC on timestamp matches the ORDER BY direction, which is a required nuance in Cosmos DB composite index design.

deviceID is an ideal partition key because it exhibits high cardinality, meaning thousands of distinct values that map to separate physical partitions, ensuring even data distribution. Since the sensor queries always filter by a specific deviceID, Azure Cosmos DB can route each request directly to the partition containing that device's readings, eliminating cross-partition fan-out. This design keeps individual partitions small and balances the workload across the container, satisfying both the efficient filtering and even distribution requirements.

This approach decouples comments from the post document. When retrieving a post for the feed, the application reads only the post document, avoiding the large comments array. This reduces RU consumption and improves latency. Comments can be loaded on demand when needed.

ADLS Gen2 is engineered for high-throughput big data analytics: its ABFS driver and parallel I/O allow large files to be read at massive scale by engines like Spark and Hive. Because it is built on Blob Storage but adds a hierarchical file system, it can sustain sequential read throughput that flat Blob can struggle to match for analytic workloads.

PlayerID is the ideal partition key because it is the most commonly used query filter in a mobile game's achievement data access patterns. Each player has many achievements, but a single PlayerID value corresponds to a manageable logical partition, and the high cardinality of player IDs means requests spread evenly across physical partitions. Queries such as 'get all achievements for a player' become efficient single-partition operations, avoiding cross-partition fan-out and hot spots.

Azure Cosmos DB is a globally distributed, multi-model NoSQL database that natively stores JSON documents as first-class citizens. Its flexible schema allows user profiles with varying fields and nested structures to be inserted without migrations, while the SQL API provides rich, index-backed querying over nested JSON properties. With turnkey global distribution, tunable consistency, and guaranteed low-latency reads/writes, it is explicitly designed for social media workloads that demand both variable data shapes and high throughput at scale.

Setting the container's public access level to 'Blob' grants anonymous users read permission for individual blobs, but only if they know the exact blob URL. Because the anonymous caller cannot list containers or blobs, discovery must happen out-of-band through a shared link or a known path. This is exactly the behavior enabled by the 'Blob' access level, making the answer correct.

Supports large blobs, HTTPS access, and concurrent reads.

A partition key in Azure Table Storage determines the physical partition where an entity is stored; using a high-cardinality, evenly distributed key like UserID ensures requests are spread across many physical partitions, avoiding hot partitions that cause throttling and high latency. Session IDs often have natural randomness, but if you use a key like UserID, you guarantee that no single partition becomes a bottleneck, even when many users are active simultaneously. Even distribution is critical because Azure scales by splitting partitions, and a well-chosen partition key allows the service to handle increased load without performance degradation. This practice aligns with Azure Table Storage's design principles for scalable, low-latency key-value access.

DriverID aligns with the most common query pattern. All trips for a given driver are stored together, allowing single-partition queries. This minimizes RU consumption if the number of trips per driver is within the 20 GB logical partition limit.

Immutable storage with a time-based retention policy places a blob container into a write-once-read-many (WORM) state in which blobs cannot be modified or deleted by any user for the configured retention interval. Once the policy is enforced, even account administrators or privileged role holders cannot alter or remove the blobs; they can only extend the retention period, not shorten or remove it. This directly satisfies the requirement to prevent both deletion and overwriting of profile images, making it a compliant solution for legal or regulatory data protection.

CSV is the correct format because it matches the actual structure and encoding of the source file. FORMAT = 'CSV' tells the parser to read each line as a record and split it on commas (or a custom delimiter), handling quotes, headers, and line breaks appropriately. This is the only option that aligns with the file's real content.

The hierarchical namespace in Azure Data Lake Storage Gen2 supports POSIX-like directory semantics, enabling directory-level atomic operations such as rename and move. This means reorganizing partitions (e.g., moving a month's data between folders) is a single metadata operation, independent of the number of files, rather than a copy-and-delete per blob. It is the core feature that makes the data lake optimized for analytics and partition management.

UserID is the filter in the common query. With UserID as partition key, all bookings for a user reside in one partition, making queries efficient and reducing RU consumption.

Azure Table Storage is a serverless, NoSQL key-value store that stores semi-structured data as entities, each uniquely addressable by a PartitionKey and RowKey. By using ProductID as the partition key, a customer review can be inserted and point-read with single-digit millisecond latency and no need to provision or manage compute, storage, or indexes. Billing is pay-per-request plus low per-GB storage cost, which makes it exceptionally cost-effective for high-volume, simple lookup scenarios like this.

Given the lifecycle policy, the blob is moved to Archive tier once it is 90 days old, and no further tier changes are defined before the 365-day deletion. At 200 days after last modification, the blob has securely been sitting in Archive tier for 110 days. Archive offers the lowest storage cost but requires a rehydration step before reading, which is appropriate for this blob's age and access pattern.

The Table API is built for key-value workloads and stores data as items with a partition key and row key. It allows efficient point reads and range queries, making it ideal for IoT sensor data.

This policy correctly matches the access pattern: Hot tier for frequent initial access, Cool for infrequent intermediate access (still retained for 2 years but accessed rarely), and Archive for long-term compliance retention where data is rarely accessed and retrieval latency is acceptable.

Archive tier is the most cost-effective storage tier in Azure Blob Storage, designed specifically for long-term retention of data that is rarely accessed. For terabytes of historical log data, it offers the lowest storage price per GB, despite requiring manual rehydration (taking up to 15 hours) to retrieve. This aligns perfectly with the scenario's archival requirements, making it the correct choice.

Append blobs are an Azure Blob Storage variant purpose-built for high-frequency append operations: each append writes a new block at the end without modifying existing data, making them ideal for shipment tracking logs. They provide low-cost, immutable storage, and using Azure Data Lake Storage Gen2 or serverless SQL, you can run queries over the entire blob to reconstruct the full route history. Unlike the other options, append blobs give you native append semantics, no per-event write cost beyond storage, and direct integration with analytics tools.

Cool tier is the right fit because it is designed for data that is rarely accessed but must be immediately available when needed. Storage costs are significantly lower than Hot and Premium, while retrieval latency remains in the order of minutes, comfortably meeting the 5-hour availability requirement. Although per-GB retrieval and early-deletion charges apply, for long-lived backup files the overall cost is minimized.

Using userId as the partition key is correct because it has high cardinality — each user has a unique ID, so every document maps to a distinct logical partition. This evenly spreads data across the physical partitions, preventing hot spots. It also makes point reads by userId highly efficient: the container can route directly to the partition containing that document, typically consuming a minimal number of Request Units (RUs) and delivering low-latency lookups.

Partitioning by GameID collocates all scores for a game in one partition, so the query targeting a specific GameID is a single-partition query, consuming fewer RUs.

This pattern uses Blob Storage's Cool tier, which is priced for infrequently accessed data, to hold IoT records older than 30 days while keeping them readily retrievable. An Azure Data Factory pipeline can copy the requested entities from the Cool-tier blobs back into Azure Table Storage on demand, restoring them for queries without requiring the data to stay in the high-priced table tier. This optimizes cost while maintaining availability, typically within the Cool tier's 24-hour retrieval-time SLA.

Choosing deviceId as the partition key is optimal because it has high cardinality and aligns directly with the query's equality filter (WHERE deviceId = ?). Automatic indexing on all properties ensures the timestamp field is indexed, so the time-range filter within the selected partition uses a precise index seek rather than a scan, minimizing request-unit (RU) consumption. This combination targets a single physical partition and uses an index for the most selective predicates, making it the most efficient design for this IoT workload.

Cool access tier is specifically designed for data that is infrequently accessed and retained for at least 30 days, offering a lower storage price than Hot while keeping millisecond latency for reads. Hourly IoT sensor logs that remain unread for the majority of their 90-day lifecycle align perfectly with Cool's cost profile, and the 90-day retention safely exceeds the 30-day minimum without imposing any early-deletion fees. It also allows immediate access for on-demand analysis, making it the most balanced and technically appropriate choice for this scenario.

Azure Blob Storage is the correct choice because it is purpose-built for storing massive amounts of unstructured data, such as high-resolution video files. Blobs are accessible via HTTP/HTTPS URLs, enabling direct streaming and integration with Azure CDN for low-latency delivery. The service scales to petabytes and supports tiers like Hot, Cool, and Archive, making it both cost-effective and performant for media workloads.

PatientID is an ideal partition key because it is the natural filtering attribute for the most common query: retrieving all vital signs for a specific patient. It has high cardinality, since each patient has a unique identifier, so data is spread evenly across logical partitions. Queries that include PatientID are single-partition queries, which are the fastest and most cost-effective in Azure Cosmos DB, avoiding cross-partition fan-out.

Archive is an offline tier with the lowest storage cost in Azure Blob Storage, specifically built for long-term retention of data that is rarely accessed. To read archived log files, you first rehydrate them to an online tier, a process that typically takes minutes to hours, but that latency is completely acceptable given the access pattern described. This combination of minimal cost and the ability to eventually retrieve the data makes Archive the correct choice.

Azure Cosmos DB using the NoSQL API is the correct choice because it provides schema-agnostic document storage that adapts to varying product attributes without migrations. It also guarantees single-digit millisecond latency for point reads (under 10 ms) at any scale, supported by a 99.999% availability SLA. Its turnkey global distribution allows replicas across Azure regions, ensuring low-latency access for e-commerce customers worldwide, and the SQL-like query engine supports rich filtering and projection over flexible JSON documents.

Azure Cosmos DB with SQL API natively stores JSON documents as its core data model, making it schema-agnostic so user sessions with varying fields can be ingested without any upfront schema design. It automatically indexes every JSON property by default, and its SQL-like query language can directly filter, project, and traverse nested objects—for example, WHERE sessionId = @id. Combined with single-digit-millisecond latency for point reads and horizontal partitioning, it is specifically engineered to serve flexible, queryable session data at global scale.

UserID is the ideal partition key because all posts belonging to the same user are colocated in a single logical partition, allowing the query for a user's posts to be served from one partition with minimal request units and low latency. Since the application has many users, data is spread evenly across physical partitions, preventing hot spots. Additionally, using UserID aligns with the natural query pattern and enables efficient pagination of results.

Azure Synapse Serverless SQL is an on-demand query engine that uses T-SQL and OPENROWSET to query files directly from Blob Storage or Azure Data Lake Storage Gen2 without provisioning dedicated compute. It supports various file formats such as Parquet, CSV, and JSON, and charges per query based on bytes scanned. This enables interactive, schema-on-read analysis of log files, exactly matching the requirement to query stored log files.

Azure Cosmos DB SQL (Core) API is a document model that natively stores JSON documents and exposes a SQL-enabled query language specifically designed to query those documents. It automatically indexes every property within the JSON, allowing flexible queries on optional and nested fields, which is ideal for a social media app's user profiles that vary in structure. Because it supports SQL-like syntax that can filter on userId and any other key with minimal effort, it best matches the requirement for querying JSON profiles.

Azure Data Lake Storage Gen2 (ADLS Gen2) is the correct migration target because it is built on Azure Blob Storage but adds a hierarchical namespace that mirrors HDFS. It exposes a native HDFS-compatible ABFS driver plus a REST API, enabling Hadoop, Spark, and Databricks to read and write data with full file-system semantics like atomic rename and POSIX file permissions. ADLS Gen2 is specifically designed for big data analytics and is the Azure service that most closely and natively replaces an on-premises Hadoop HDFS cluster.

The Core (SQL) API is Cosmos DB's native API, storing documents as JSON and integrating directly with the underlying index and partitioning engine. It supports rich SQL-based querying, including nested attributes and server-side JavaScript, making it ideal for a device registry with variable schema. Point reads by device ID leverage the partition key and a physical index, providing the lowest and most predictable latency. Being the native API, it also enjoys first-class support for global distribution, consistency levels, and throughput management.

Changing the PartitionKey to a date-based value such as YYYY-MM-DD groups all telemetry from every truck for a single day into one partition. Because Azure Table Storage stores rows together by PartitionKey, a query that filters on a date range (e.g., the last 24 hours) will scan exactly one partition, drastically reducing read transactions and lowering cost. The RowKey is then a composite of TruckID and Timestamp, which preserves truck-level granularity and enables efficient sorting and filtering within that day's partition. This design directly aligns the queried time range with the partition structure, which is the optimal way to handle time-range queries in Table Storage.

Azure Blob Storage is a massively scalable object storage service designed specifically for unstructured data such as large binary files. It provides per-blob access tiers — hot, cool, cold, and archive — so you can place data in the tier that matches its access frequency and drastically reduce storage costs. Blob Storage offers REST-based access, high durability, and lifecycle policies that automatically move blobs between tiers, making it the correct choice for storing large binaries like videos, backups, or datasets.

Azure Cosmos DB is a globally distributed database service with turnkey multi-region replication and support for multi-region writes, ensuring low-latency writes and reads anywhere in the world. Azure Blob Storage is a single-region storage service that offers only asynchronous geo-redundant replication (GRS) and does not support active writes from multiple regions. This directly affects disaster recovery, availability, and user-perceived latency for globally distributed applications.

Azure Cosmos DB is a globally distributed NoSQL database that supports flexible schemas and document models via its SQL API. It offers low-latency reads and writes with guarantees of <10 ms for reads and can be replicated across Azure regions.

The Core (SQL) API stores each IoT sensor payload as a JSON document in a multi-item container and exposes a first-class SQL query engine over that JSON structure. It supports SELECT, WHERE, JOIN, and functions directly on embedded properties such as deviceId and timestamp without needing a separate translation layer. This makes it the optimal choice when the application requires SQL-like queries over JSON time-series data, with automatic indexing and configurable partition keys for scale.

The SQL API is the native document API for Azure Cosmos DB: it stores user profiles as full JSON documents in containers and queries them with a SQL-like syntax that understands JSON types, nested objects, and arrays. This API automatically indexes every property of the JSON document, enabling efficient filtering, projection, and joins without requiring a fixed schema. For a web application that needs to store and retrieve JSON user profiles as documents, the SQL API is the correct choice.

Azure Cosmos DB with the NoSQL API is the right fit because it stores JSON documents natively, allowing each sensor record to have a flexible set of attributes without schema migrations. Its multi-region writes and configurable consistency levels (e.g., session or eventual) provide sub-10-ms latencies at scale, which is essential for thousands of concurrent IoT devices writing variable telemetry. The global distribution also ensures data is available close to each factory or region, and the change feed can stream to downstream analytics, making it a purpose-built choice for high-velocity, schema-less sensor data.

Session consistency guarantees that within the same client session, reads will see the latest writes. This means the user will always see their own post immediately, while reads of other users' posts may be stale. This is the most cost-effective and correct choice.

The Core (SQL) API is the default Cosmos DB API, exposing a SQL query dialect that operates directly on JSON documents without any schema mapping. Because the team already knows SQL, they can immediately write SELECT, JOIN, and WHERE clauses with no additional learning curve. It also delivers single-digit-millisecond latency for key-value reads and writes, and its tunable consistency and built-in index management make it the most straightforward and cost-effective choice for the new feature.