Develop for Azure storage practice questions

Block blobs with Hot tier and a lifecycle rule to move to Cool after 7 days.

Why it fails: Block blobs require creating new blocks for each append, which is inefficient for frequent small appends; Cool after 7 days is not the cheapest long-term option.

Page blobs with Premium tier.

Why it fails: Page blobs are for VHDs and random read/write patterns, not append; Premium tier is expensive and not needed for this scenario.

Append blobs with Cool tier and no lifecycle rule.

Why it fails: Cool tier has lower storage but higher write costs; without lifecycle, data remains in Cool tier, which is more expensive than Archive for long-term retention.

Cool tier with a lifecycle rule to move to Archive after 30 days

Why it fails: Starting in Cool incurs early deletion penalties if data is deleted within 30 days, and moving to Archive after 30 days would incur higher retrieval costs for the occasional reads.

Hot tier with a lifecycle rule to move to Archive after 30 days

Why it fails: Moving to Archive after 30 days makes data retrieval expensive and slow, which is not ideal for 'rarely accessed' but still needed on occasion.

Archive tier with a lifecycle rule to move to Cool after 30 days

Why it fails: Archive tier is not writable and is meant for data that is rarely accessed; you cannot write directly to Archive tier. Also, moving to Cool would be unnecessary.

Azure Cosmos DB SQL API with a collection partitioned by timestamp.

Why it fails: Cosmos DB provides low-latency access and flexible queries, but it is significantly more expensive than Azure Table Storage for high-volume log ingestion. The cost per GB is much higher, and write throughput is billed per RU.

Azure Blob Storage with append blobs and a custom index for timestamp queries.

Why it fails: Append blobs cap each block at 4 MiB and suit sequential writes, but timestamp range scans require reading every blob, since no native index exists. A custom index adds write amplification and maintenance overhead. Table Storage is built for indexed range queries on timestamp keys and scales to billions of small entities cheaply.

Azure SQL Database with a clustered columnstore index.

Why it fails: SQL Database is not designed for such high-volume unstructured log data at low cost. It would be expensive and the schema would need to be rigid, while Table Storage provides schema-less tables.

PartitionKey = City, RowKey = DeviceId_Timestamp (e.g., "device123_2023-10-01T12:00:00")

Why it fails: This design allows querying by city but the row key is not sortable by timestamp, so you cannot do a range query on timestamp efficiently. You would have to scan all devices in the city and filter in the client.

PartitionKey = DeviceId, RowKey = Timestamp

Why it fails: Partitioning by DeviceId means each device's data is stored in a separate partition. While this allows for efficient queries for a single device's history using the Timestamp RowKey, it severely hinders queries that need to aggregate or filter devices based on a property like City. To find all devices in a specific city, the system would be forced to perform a full table scan across all partitions, which is highly inefficient and costly in Azure Table Storage, as it bypasses the optimized partition-level indexing.

PartitionKey = City, RowKey = DeviceId

Why it fails: This allows efficient partition query by city, but the row key is device ID. To filter by timestamp, you would need to scan all rows in the partition and apply a filter, which is not efficient if the partition has many devices.

Cool

Why it fails: Incorrect. Cool tier has lower storage cost but higher access cost and is intended for infrequently accessed data.

Cold

Why it fails: Incorrect. Cold tier has even lower storage cost but significant access costs and latency, not suitable for frequent access.

Archive

Why it fails: Incorrect. Archive tier is for rarely accessed data with high retrieval costs and latency, not for frequent access.

Hot: Optimized for data that is infrequently accessed and stored for at least 30 days.

Why it fails: This description incorrectly attributes characteristics of the Cool tier to the Hot tier. The Hot tier is designed for *frequent* access, not infrequent, and does not impose a minimum storage duration like 30 days. Data in the Hot tier is expected to be accessed regularly, justifying its higher storage cost with significantly lower data retrieval and transaction fees.

Cool: Optimized for rarely accessed data stored for at least 180 days.

Why it fails: This statement incorrectly describes the Cool tier by suggesting it's for 'rarely accessed data stored for at least 180 days.' This duration and access frequency are hallmarks of the Archive tier, not Cool. The Cool tier is intended for *infrequently* accessed data with a shorter minimum retention period of 30 days, balancing cost savings with reasonable access times.

Set the trigger's 'filter' property to '*.jpg,*.png'.

Why it fails: Incorrect. Azure Blob Storage triggers do not support a 'filter' property like '*.jpg,*.png'. This is not a valid configuration option.

Use the blob trigger with a path pattern like 'images/{name}.jpg' and 'images/{name}.png' and use the extension binding to filter.

Why it fails: Incorrect. The blob trigger's path pattern (e.g., 'images/{name}.jpg') is used to bind the blob name, but it does not filter the trigger. The function will fire for any blob created in the container, regardless of the extension.

Use a separate queue client SDK to write messages and handle errors manually.

Why it fails: Manual SDK calls are less reliable.

Write to the queue directly in the function code and rely on the function's retry policy.

Why it fails: The function may write to the queue but then fail, causing duplicate processing.

Use a durable function to orchestrate the writing and processing.

Why it fails: Durable functions add complexity and are not needed for simple queue writing.

Connection string with account key

Why it fails: A connection string is a convenient way to encapsulate connection information and credentials, such as a Shared Key or SAS token, for an Azure Storage account. While it contains the necessary authentication material, the connection string itself is not an authentication method. Instead, it provides the client library with the details required to use an underlying authentication mechanism, like Shared Key authentication, to access storage resources.

Client certificate authentication

Why it fails: Client certificate authentication, while a valid security mechanism in some contexts, is not directly supported as an authentication method for accessing Azure Blob Storage data plane operations. Azure Storage services primarily rely on Shared Key, Shared Access Signatures, or Microsoft Entra ID identities for authenticating requests. Therefore, attempting to authenticate to Blob Storage using a client-side X.509 certificate will fail as it's not an recognized credential type for this service.

Strong consistency provides the highest availability.

Why it fails: Strong consistency in Azure Cosmos DB mandates that all replicas of a data item must be updated and acknowledge the write operation before it is considered complete. This strict requirement significantly reduces availability, as the system cannot process new writes if even one replica is temporarily unreachable or experiences high latency. Consequently, it prioritizes data integrity and immediate read consistency over continuous operational availability, making this statement incorrect.

Bounded staleness consistency is the default consistency level.

Why it fails: Bounded staleness consistency, which offers a balance between strong and eventual consistency by guaranteeing that reads will not lag behind writes by more than a specified number of versions or time interval, is not the default consistency level for new Azure Cosmos DB accounts. Users must explicitly configure this consistency level and its associated parameters (MaxStalenessPrefix and MaxStalenessInterval) when creating or modifying their account. The system defaults to a more relaxed consistency level to optimize for availability and performance initially, rendering this statement incorrect.

Eventual consistency is the default consistency level for all new Cosmos DB accounts.

Why it fails: Eventual consistency is correctly identified as the default consistency level for all newly created Azure Cosmos DB accounts. This default setting prioritizes the highest availability and lowest latency, making it suitable for a wide range of applications where immediate consistency across all replicas is not a strict requirement. While data might take some time to propagate across all replicas, reads will eventually reflect the latest writes, offering a highly performant and scalable solution out-of-the-box.

PartitionKey = timestamp, RowKey = reverse deviceId

Why it fails: Using `timestamp` as the `PartitionKey` would lead to hot partitions, as all data for a given second or minute would reside on the same partition server, severely limiting scalability and write throughput. Furthermore, querying by `deviceId` across different timestamps would necessitate scanning multiple partitions, making such queries highly inefficient. A `reverse deviceId` as `RowKey` offers no practical benefit for standard `deviceId` lookups or range queries.

PartitionKey = timestamp, RowKey = deviceId

Why it fails: Setting `PartitionKey` to `timestamp` creates hot partitions because all entities generated within the same time interval (e.g., second, minute) would be stored together, severely limiting write throughput and overall scalability. While `RowKey = deviceId` allows efficient retrieval of all data for a specific `deviceId` *within that precise timestamp*, querying for a `deviceId` across a time *range* would require scanning numerous partitions, leading to poor performance.

PartitionKey = deviceId, RowKey = reverse timestamp

Why it fails: While `deviceId` as `PartitionKey` is excellent for data distribution, using a `reverse timestamp` as `RowKey` would store data in descending chronological order. This design might slightly optimize queries for the *latest* entry for a specific device, but it complicates standard time range queries (e.g., "data from 9 AM to 10 AM") as the range would need to be specified in reverse, making them less intuitive and potentially less efficient than with a standard ascending `timestamp`.

Azure Blob Storage soft delete

Why it fails: Azure Blob Storage soft delete protects against accidental deletion of blobs or snapshots by retaining them for a specified period after deletion, allowing for recovery. However, soft delete does not prevent existing blobs from being overwritten or modified, nor does it enforce a strict, unalterable retention period. Therefore, it fails to meet requirements for immutability where log data must be guaranteed to remain unchanged for compliance or auditing purposes.

Azure Table Storage

Why it fails: Azure Table Storage is a NoSQL data store optimized for storing large amounts of structured, non-relational data, typically organized as key-value pairs. It is not designed or optimized for storing large, unstructured or semi-structured log files directly as binary blobs. While it could store metadata about log files, the actual content of large log files is unsuitable for its row-column structure, making it an inefficient and inappropriate solution for raw log storage.

The storage account was created with Azure Disk Encryption instead

Why it fails: Azure Disk Encryption (ADE) is a feature designed to encrypt the OS and data disks used by Azure Virtual Machines (VMs), leveraging industry-standard BitLocker or DM-Crypt. Storage accounts, however, utilize Azure Storage Service Encryption (SSE) for data at rest. SSE is a platform-managed encryption mechanism distinct from ADE and operates at a different layer, making ADE inapplicable as an encryption method for a storage account itself.

The command is querying the wrong property; use 'encryption.requireInfrastructureEncryption'

Why it fails: The property 'encryption.requireInfrastructureEncryption' enables a double encryption layer for data at rest, where data is encrypted once at the service level and again at the infrastructure level. This is an additional, optional security feature, not the fundamental or default encryption for a storage account. Azure Storage Service Encryption (SSE) is always enabled by default for all storage accounts, regardless of this setting, meaning this property does not reflect the base encryption status.

The storage account is in a region that does not support encryption

Why it fails: Azure Storage Service Encryption (SSE) is a fundamental security feature that is universally supported across all Azure regions, without exception. It is automatically enabled for all new and existing storage accounts, ensuring that data at rest is encrypted by default using Microsoft-managed keys. There are no Azure regions where storage accounts can be provisioned without SSE being active, making the premise that a region might not support encryption incorrect.

Assign RBAC roles to users.

Why it fails: Assigning Role-Based Access Control (RBAC) roles to users is a fundamental security practice that governs who can perform specific actions on Azure resources. While RBAC helps prevent unauthorized access and potential malicious deletion by enforcing the principle of least privilege, its primary function is access control, not data durability. RBAC does not inherently provide mechanisms for data recovery or persistence in the event of accidental deletion or corruption by an authorized user, which is the core concern of durability.

Change replication to GRS.

Why it fails: While changing Azure Storage replication to Geo-Redundant Storage (GRS) significantly enhances data durability by replicating data across two geographically distant Azure regions, the question implies a specific context or constraint where LRS is either the current state or a requirement. GRS protects against regional outages and major disasters, but if the problem statement specifies or implies operating within an LRS framework, then changing the fundamental replication strategy is not among the two actions to take within that specified context.

Configure network firewall rules.

Why it fails: Configuring network firewall rules for an Azure Storage account is a security measure designed to restrict network access to the storage account, allowing traffic only from specified IP addresses or virtual networks. These rules are essential for preventing unauthorized access and potential data breaches. However, network firewall rules do not contribute to data durability, which concerns the persistence and recoverability of data itself, irrespective of network access controls.

Upgrade to Premium Block Blob storage.

Why it fails: Premium Block Blob storage offers significantly lower and more consistent latency and higher transaction rates compared to standard tiers, making it suitable for performance-sensitive workloads within a single Azure region. However, its primary benefit is improving the performance of the storage account itself, not distributing content globally. It does not inherently provide global edge caching or content delivery network (CDN) capabilities, which are crucial for reducing latency for geographically dispersed users accessing static content like diagnostic images. Therefore, while it improves regional storage performance, it doesn't address global content delivery latency.

Enable read-access geo-redundant storage (RA-GRS).

Why it fails: Read-access geo-redundant storage (RA-GRS) provides durability and high availability by asynchronously replicating data to a secondary Azure region, offering a read-only endpoint in that secondary region. While it protects against regional outages and allows reads from two distinct regions for disaster recovery, it is fundamentally a data redundancy solution, not a content delivery network. RA-GRS does not provide a global network of edge caches to serve content from the closest point of presence to every user, which is essential for minimizing latency for a worldwide audience.

Use Blob Storage lifecycle management to delete blobs after reading.

Why it fails: Blob Storage lifecycle management policies are designed to automate the tiering or deletion of blobs based on rules like age, access time, or version. Its primary purpose is cost optimization by moving less frequently accessed data to cooler tiers or deleting obsolete data. Deleting blobs after reading would actually make subsequent access impossible without re-uploading and does not contribute to reducing latency for *accessing* the images. This feature is entirely unrelated to improving content delivery speed for users and would be counterproductive for ongoing access.

Geo-replication

Why it fails: Geo-replication links two Azure Cache for Redis instances in different regions, providing disaster recovery. It does not ensure data persistence within a single cache instance. If the primary cache restarts, data might still be lost unless persistence is configured. Geo-replication is for cross-region redundancy, not for local data durability.

Clustering

Why it fails: Clustering in Azure Cache for Redis allows you to distribute data across multiple nodes for scalability and high availability. However, it does not provide data persistence; if a node restarts, data on that node may be lost unless persistence is also enabled. Clustering alone does not prevent session data loss.

Azure Private Endpoint

Why it fails: Azure Private Endpoint provides a private IP address within your virtual network to access the cache securely. It enhances network security but has no impact on data persistence. Enabling a private endpoint does not prevent data loss on restart; it only changes the network path.

var options = new BlobClientOptions(); options.Retry.MaxRetries = 5; options.Retry.NetworkTimeout = TimeSpan.FromSeconds(2); options.Retry.Mode = RetryMode.Exponential;

Why it fails: The NetworkTimeout property sets the timeout for network operations, not the base delay between retries. Setting NetworkTimeout to 2 seconds would configure the client to wait at most 2 seconds for a network response, which is unrelated to the retry delay. The scenario requires a base delay of 2 seconds for exponential backoff, which is controlled by the Delay property. Using NetworkTimeout here would not achieve the desired retry behavior and could cause premature timeouts. Therefore, this code segment is incorrect.

var options = new BlobClientOptions(); options.Retry.MaxRetries = 5; options.Retry.Delay = TimeSpan.FromSeconds(2); options.Retry.Mode = RetryMode.Fixed;

Why it fails: Setting the retry mode to Fixed configures a constant delay between retries, not exponential backoff. The scenario explicitly requires exponential backoff, which increases the delay after each attempt. Although MaxRetries and Delay are set correctly, the Fixed mode does not meet the requirement. Exponential backoff is more suitable for handling transient failures because it reduces the load on the service during congestion. Therefore, this code segment would not implement the desired retry policy.

var options = new BlobClientOptions(); options.Retry.MaxRetries = 5; options.Retry.Delay = TimeSpan.FromSeconds(2); options.Retry.MaxDelay = TimeSpan.FromSeconds(10);

Why it fails: This code sets MaxRetries and Delay but does not specify the retry mode. In the Azure.Storage.Blobs SDK, the default retry mode is Exponential, so it would actually achieve exponential backoff. However, the scenario asks for a code segment that explicitly configures exponential backoff. While this code might work, it relies on the default mode and adds an unnecessary MaxDelay property. The most explicit and correct configuration is to set the Mode property to RetryMode.Exponential. Therefore, this option is less precise and not the best answer.

Hot tier

Why it fails: Hot tier is optimised for frequent access and carries the highest storage cost, so it fails the cost-minimisation requirement. It is tempting because it guarantees immediate retrieval, and would be correct for actively used data, but archival data accessed a few times yearly belongs in Archive.

Cool tier

Why it fails: Cool tier targets data accessed infrequently but stored at least 30 days, with millisecond retrieval; it costs more than Archive while offering no benefit here. It is tempting for infrequent access, yet the 15-hour retrieval tolerance and few-times-yearly pattern point to Archive.

Premium tier

Why it fails: Premium tier uses high-performance SSD storage for low-latency, transaction-heavy workloads, raising cost rather than minimising it. It is tempting for performance-sensitive scenarios, but archival data accessed a few times per year with 15-hour retrieval tolerance fits Archive tier.

Blob trigger

Why it fails: An Azure Blob trigger is specifically designed to activate an Azure Function when a new or updated blob is detected in an Azure Storage container. Its primary purpose is to process files stored in Azure Blob Storage, such as images, videos, or log files, upon their creation or modification. This trigger has no inherent capability to monitor or respond to data changes occurring within an Azure Cosmos DB database, making it unsuitable for this scenario.

Event Grid trigger

Why it fails: While Azure Event Grid can route events from Cosmos DB, it typically requires explicit configuration within Cosmos DB to publish specific events (e.g., document creation) to Event Grid. An Event Grid trigger then reacts to these discrete events. However, for continuous, real-time processing of *all* inserts and updates via the change feed, the native Cosmos DB trigger is the more direct, efficient, and simpler solution, as it directly integrates with the change feed processor for comprehensive data change monitoring.

Service Bus trigger

Why it fails: An Azure Service Bus trigger is specifically designed to activate an Azure Function in response to messages arriving in an Azure Service Bus queue or topic. It is primarily used for decoupled messaging scenarios, enabling reliable communication and workflow orchestration between different application components. This trigger is entirely focused on message processing and does not provide any mechanism to directly monitor or react to data modifications within a database like Azure Cosmos DB.

Block blobs with a high block size.

Why it fails: Block blobs with a high block size are optimized for uploading large files efficiently, where the entire file or large chunks are available before upload. For logging, which typically involves frequent, small append operations, a high block size would necessitate significant client-side buffering to accumulate enough data to form a full block. This buffering introduces latency, increases memory consumption, and ultimately reduces the effective throughput for continuous small writes, making them unsuitable for real-time logging scenarios.

Page blobs.

Why it fails: Page blobs are optimized for random read/write operations and are primarily used for virtual hard disk (VHD) files backing Azure Virtual Machines. Their underlying structure is a collection of 512-byte pages, allowing for byte-range updates. However, for logging, which involves sequential appends rather than arbitrary overwrites, using page blobs would introduce unnecessary overhead due to their random access optimization and the management of individual pages, making them inefficient and more costly compared to append blobs.

Block blobs with a low block size.

Why it fails: While a low block size for block blobs might seem to accommodate smaller writes, it significantly increases the number of individual blocks that need to be managed and committed for a growing log file. Each block operation incurs overhead, leading to a higher number of API calls and increased transaction costs for high-volume logging. This granular management overhead can negatively impact performance and cost-effectiveness compared to the streamlined append operations of append blobs.