Develop for Azure storage practice questions

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

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

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

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

Microsoft account (personal) OAuth token

Why wrong: Personal Microsoft accounts (e.g., @outlook.com, @hotmail.com) are primarily for consumer services and do not integrate directly with Azure Active Directory (Azure AD) for resource authentication. Azure Storage accounts rely on Azure AD identities for role-based access control (RBAC) and OAuth token-based authentication. Therefore, an OAuth token issued for a personal Microsoft account cannot be used to authenticate requests to Azure Blob Storage, which requires an Azure AD identity.

SQL Server authentication

Why wrong: SQL Server authentication is a mechanism specifically designed for authenticating users and applications to SQL Server instances, including Azure SQL Database and Azure SQL Managed Instance. It involves usernames and passwords managed within the database server itself. This authentication method is entirely distinct and incompatible with Azure Blob Storage, which uses different protocols and security models for access control, such as shared keys, SAS tokens, or Azure AD.

Azure Cosmos DB primary key

Why wrong: An Azure Cosmos DB primary key is a security credential used to grant full administrative access to a specific Azure Cosmos DB account. These keys are unique to Cosmos DB and are designed to authenticate requests against its various APIs (e.g., SQL API, MongoDB API). They are fundamentally different from storage account keys or SAS tokens and cannot be used to authenticate requests to Azure Blob Storage, which operates on a distinct authentication and authorization model.

Messages are processed in strict FIFO order.

Why wrong: Azure Storage Queues are primarily designed for high throughput and availability in a distributed environment, not for strict message ordering guarantees. While messages are generally dequeued in a first-in, first-out manner under ideal conditions, the distributed nature of the service, concurrent consumers, and potential internal partitioning mean that strict FIFO processing cannot be guaranteed. This makes them suitable for scenarios where message order is not absolutely critical for correctness.

Messages can be up to 1 MB in size.

Why wrong: The maximum size for a single message in an Azure Storage Queue is strictly limited to 64 KB, not 1 MB. This limit includes the message body, which is often Base64 encoded, adding to its overall size. Attempting to enqueue a message that exceeds this 64 KB threshold will result in a client-side error. For applications requiring larger payloads, the common pattern is to store the data in Azure Blob Storage and place a reference (e.g., a URL) to the blob within the 64 KB queue message.

Automatically apply legal hold to blobs.

Why wrong: While Azure Blob Storage supports legal hold functionality, it is implemented through immutability policies, specifically by setting a time-based retention policy or a legal hold policy directly on a container or blob version. This feature prevents deletion or modification of data for compliance purposes. Lifecycle management policies, however, are designed for automated tiering and deletion, not for applying legal holds.

Automatically replicate blobs to another region.

Why wrong: Azure Blob Storage provides data redundancy and disaster recovery through replication options like Geo-Redundant Storage (GRS) or Zone-Redundant Storage (ZRS), which are configured at the storage account level upon creation or modification. This ensures data is automatically replicated across different regions or availability zones. Lifecycle management policies operate within a single storage account to manage blob lifecycle stages, not to configure cross-regional replication.

Automatically encrypt blobs at rest.

Why wrong: Azure Storage automatically encrypts all data at rest using Azure Storage encryption, which employs 256-bit AES encryption. This encryption is transparently applied by default to all blobs, files, queues, and tables, requiring no explicit configuration or action from the user. Therefore, it is not a feature that needs to be "automatically applied" via lifecycle management or any other user-configurable automation.

Connection string with account key

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

It can be defined at the container level.

Why wrong: Azure Blob Storage lifecycle management policies are configured at the storage account level, not granularly per container. This design ensures consistent application of rules across all blobs within the account, simplifying administration for large-scale data management. While rules can specify blob prefixes to target specific subsets of data, the policy itself is a storage account resource and applies its rules across the entire account's blob containers.

It can change the replication type of the storage account.

Why wrong: Azure Blob Storage lifecycle management policies are focused on managing the lifecycle of blob data itself, including tiering, archiving, and deletion. However, they do not possess the functionality to alter fundamental storage account properties such as the replication type (e.g., LRS, GRS, RA-GRS). Changing the replication strategy is a separate, account-level operation that impacts data durability and availability, distinct from data lifecycle management.

Strong consistency provides the highest availability.

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

Azure Blob Storage soft delete

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

Use Azure Front Door to restrict access

Why wrong: Azure Front Door is a global, scalable entry-point that uses the Microsoft global edge network to create fast, secure, and widely scalable web applications. While it offers Web Application Firewall (WAF) capabilities for security against common web exploits and can route traffic, it does not inherently provide identity-based access control or authorization mechanisms for Azure Storage accounts or individual blobs. Its primary role is content delivery and network-level protection, not authentication or authorization to backend storage.

Embed storage account keys in client code

Why wrong: Embedding storage account keys directly into client-side code is a highly insecure practice that grants full administrative access to all data within the storage account across all services (blobs, files, queues, tables). If compromised, an attacker would have unrestricted access, leading to potential data breaches, modification, or deletion. This method bypasses all granular access controls and is extremely difficult to revoke or rotate securely once distributed, making it a significant security vulnerability.

Enable public blob access

Why wrong: Enabling public blob access, either at the container level (anonymous read access to blobs and container metadata) or blob level (anonymous read access to blobs), makes the data accessible to anyone on the internet without any authentication or authorization. This completely negates any security measures and is only appropriate for publicly distributable, non-sensitive content. For securing confidential or restricted data, public access must be disabled to prevent unauthorized data exposure.

Azure Content Delivery Network (CDN)

Why wrong: Azure Content Delivery Network (CDN) is a distributed network of servers designed to cache web content closer to users, thereby improving performance and reducing latency. While CDN involves data distribution, its primary function is content delivery and caching for faster access, not providing the underlying data redundancy or high availability features for the *source* Azure Storage account itself. It does not serve as a core data replication strategy for durability like LRS, ZRS, or GRS.

Assign RBAC roles to users.

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

Azure Cosmos DB trigger

Why wrong: The Azure Cosmos DB trigger is specifically designed to process changes from a Cosmos DB container's change feed. It monitors for document insertions, updates, and deletions within the NoSQL database itself, enabling real-time data processing. This trigger type is not integrated with Azure Blob Storage and therefore cannot detect or respond to the creation of new blobs.

Azure Queue Storage trigger

Why wrong: An Azure Queue Storage trigger activates an Azure Function when a new message is added to a specified storage queue. Its primary purpose is to enable message-driven processing workflows, where functions react to queued tasks or data. Since it operates solely on queue messages and has no inherent capability to monitor Blob Storage events, it cannot be used to trigger a function upon new blob creation.

Azure Service Bus trigger

Why wrong: The Azure Service Bus trigger is designed to process messages from Azure Service Bus Queues or Topics, facilitating enterprise messaging patterns. It activates an Azure Function when a new message arrives in the configured Service Bus entity, enabling robust, asynchronous communication. This trigger type is entirely distinct from Blob Storage events and lacks the functionality to monitor or respond to the creation of new blobs.

Upgrade to Premium Block Blob storage.

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

Hot tier

Why wrong: Hot tier optimizes for frequent access but has the highest storage cost, unsuitable for rare access.

Cool tier

Why wrong: Cool tier is for data accessed infrequently (about once a month) but still has higher cost than Archive.

Premium tier

Why wrong: Premium tier is for low-latency, high-frequency access, with the highest cost.

Blob trigger

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

Upload the blob as a single PUT operation.

Why wrong: Uploading a 100 GB file as a single PUT operation is not supported by Azure Blob Storage. The `Put Blob` REST API operation has a maximum size limit of 5 GB for a single blob upload (for API versions 2016-05-31 and later). Attempting to upload a file significantly larger than this limit will result in an error, and such an operation inherently lacks any built-in resumability or retry mechanisms, which are critical for large file transfers over potentially unstable networks.

Use append blob.

Why wrong: Append blobs are specifically optimized for append operations, such as logging or auditing, where data is continuously added to the end of an existing blob. While they can grow to large sizes, they are not designed for the efficient, resumable initial upload of a complete, pre-existing large file from arbitrary chunks. There is no mechanism to commit blocks out of order or to resume a partially uploaded initial file in the same way block blobs facilitate, making them unsuitable for this scenario.

Use AzCopy from the server.

Why wrong: AzCopy is a powerful command-line utility and programmatic library (e.g., Go SDK) designed for high-performance data transfer to and from Azure Storage. While excellent for server-side or client-side *application* transfers, it is not a component that can be directly invoked or embedded within a client-side *web browser* for uploads. The question specifies uploading "from a web," implying a web application running in a browser, where AzCopy cannot be utilized for direct client-side file transfers.

Azure SQL Database

Why wrong: Azure SQL Database is a relational database service best suited for structured, transactional data requiring strong consistency and complex querying capabilities. Storing millions of 1KB log entries as individual rows would incur significant overhead in terms of storage cost per record, indexing, and transaction processing. This approach would lead to prohibitive operational expenses and potential performance bottlenecks, as it's not optimized for high-volume, unstructured append-only data.

Azure Table Storage

Why wrong: Azure Table Storage is a NoSQL key-value store designed for semi-structured data, offering high scalability and cost-efficiency for specific data models. While cost-effective, it's optimized for structured entities with defined properties, not for storing raw, unstructured 1KB log files as the primary content. Storing each log entry as a separate table entity would introduce unnecessary schema overhead and limit efficient content-based querying, making it less suitable than object storage for this specific log format.

Azure Files

Why wrong: Azure Files provides managed cloud file shares accessible via SMB and NFS protocols, primarily intended for traditional file system workloads and lift-and-shift scenarios. It is not optimized for storing millions of small, independent objects like individual log entries, which would result in inefficient resource utilization and higher costs compared to object storage. Its design is geared towards shared access to larger files or a moderate number of files within a hierarchical structure, not high-volume, independent object ingestion.