Develop for Azure storage practice questions

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: Blob trigger is for Azure Blob Storage, not Cosmos DB changes.

Event Grid trigger

Why wrong: Event Grid trigger can handle events from Cosmos DB but requires explicit event publishing; the Cosmos DB trigger is the native approach for change feed.

Service Bus trigger

Why wrong: Service Bus trigger processes messages from a queue or topic, not database changes.

Block blobs with a high block size.

Why wrong: Incorrect. High block size would require buffering and reduce throughput for small writes.

Page blobs.

Why wrong: Incorrect. Page blobs are optimized for random read/write and VHDs, not efficient for logging.

Block blobs with a low block size.

Why wrong: Incorrect. Low block size increases management overhead and may not be cost-effective for high volume.

Upload the blob as a single PUT operation.

Why wrong: Incorrect. Single PUT for 100 GB is not supported (max 5 GB) and not resumable.

Use append blob.

Why wrong: Incorrect. Append blobs are for append-only scenarios, not large uploads with resume.

Use AzCopy from the server.

Why wrong: Incorrect. AzCopy is a command-line tool, not suitable for in-browser web application uploads.

Azure SQL Database

Why wrong: Incorrect. Azure SQL Database is expensive for storing massive numbers of small records and incurs high transaction costs.

Azure Table Storage

Why wrong: Incorrect. Table Storage is cost-effective but designed for structured NoSQL data; logs are better stored as blobs for flexibility and cost.

Azure Files

Why wrong: Incorrect. Azure Files is a file share service, not optimized for storing millions of small independent objects.

Block blobs

Why wrong: Block blobs are optimized for uploading large objects and random access, not for frequent small appends. They incur higher overhead per write operation, making them less efficient for high-volume logging.

Page blobs

Why wrong: Page blobs are optimized for random read/write operations in 512-byte pages, typically used for virtual machine disks. They are not cost-effective for logging and do not support efficient append operations.

Azure Files shares

Why wrong: Azure Files provides SMB file shares, not a blob type. While it can store logs, it lacks the write-optimized append semantics and is better suited for shared file access scenarios.

Block blob

Why wrong: Block blobs are ideal for large files but are not optimized for frequent append operations; block blobs require listing and committing blocks for each append, which is less efficient.

Page blob

Why wrong: Page blobs are optimized for random read/write operations typical of virtual machine disks, not for sequential appends.

Archive blob

Why wrong: Archive blobs are for cold data with infrequent access and do not support frequent writes or appends.

Azure Table Storage

Why wrong: Table Storage is cost-effective but lacks a latency SLA and is not globally distributed by default.

Azure Redis Cache

Why wrong: Redis Cache provides low latency but is not serverless; you must provision and pay for a cache tier, and it lacks built-in global distribution without additional configuration.

Azure Blob Storage

Why wrong: Blob Storage is optimized for large objects and throughput, not for small, frequent reads with low latency.

Page Blob

Why wrong: Page Blobs are designed for random read/write patterns (e.g., VHDs) and are not cost-optimal for large file overwrites.

Append Blob

Why wrong: Append Blobs are optimized for append operations only; they do not support overwriting existing content efficiently.

Archive Blob

Why wrong: Archive Blob has the lowest storage cost but high retrieval latency (hours), making it unsuitable for frequent overwrites.

Block Blob

Why wrong: Block Blobs can be used but they are not optimized for many small append operations; each block incurs overhead.

Page Blob

Why wrong: Page Blobs are designed for random read/write patterns (e.g., VHDs) and are not cost-effective for log entries.

Archive Blob

Why wrong: Archive Blob provides lowest storage cost but requires hours to retrieve data, making it unsuitable for frequent writes.

Block Blob

Why wrong: Incorrect. Block Blobs are optimized for random access and are not as efficient for many small, sequential appends.

Page Blob

Why wrong: Incorrect. Page Blobs are designed for random read/write of pages and are intended for use as VHDs, not logging.

Archive Blob

Why wrong: Incorrect. 'Archive Blob' is not a blob type; Archive is an access tier that can be applied to blobs, but it is not optimal for frequent writes due to high latency and cost for early retrieval.

Azure Data Lake Storage Gen2 with Append Blobs and immutability

Why wrong: Incorrect. While technically possible, Data Lake Storage Gen2 adds cost for the hierarchical namespace and is more suited for analytics purposes, not just append-only immutability.

Azure Files with immutable shares

Why wrong: Incorrect. Azure Files provides SMB/NFS file shares, but immutability is not available for all tiers and append writes are not efficient.

Azure NetApp Files with immutability

Why wrong: Incorrect. Azure NetApp Files is a high-performance file share for enterprise workloads, not optimized for append-only immutability and is cost-prohibitive for large-scale append data.

Enable blob soft delete

Why wrong: Incorrect. Soft delete retains deleted blobs for a period but allows overwriting existing blobs, which violates the immutability requirement.

Enable blob versioning

Why wrong: Incorrect. Versioning preserves earlier versions when a blob is overwritten, but it does not prevent overwrites, so the current version can still be changed.

Enable change feed

Why wrong: Incorrect. Change feed records all modifications to blobs but does not prevent modifications or deletions.

Block blobs in the Cool tier

Why wrong: Block blobs are not optimized for appending; each append would require creating a new block and committing it, which is slower than append blobs for sequential writes.

Page blobs in the Premium tier

Why wrong: Page blobs are optimized for random read/write access patterns, not for sequential append. Premium tier is expensive and unnecessary for this use case.

Block blobs in the Archive tier

Why wrong: Archive tier is for data that is rarely accessed and has significant retrieval latency. It is not suitable for active write workloads.

Provide the storage account key to the user so they can authenticate

Why wrong: Sharing the storage account key grants full administrative access to the entire storage account, which is a security risk.

Assign the user an RBAC role (e.g., Storage Blob Data Reader) and have them authenticate via Microsoft Entra ID

Why wrong: RBAC requires the user to be an Microsoft Entra ID user and authenticated; the question says 'without requiring authentication'.

Set the blob container's public access level to Blob (anonymous read access for blobs)

Why wrong: This would make all blobs in the container publicly accessible, not just the single file, and does not provide time-limited access.

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

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

Why wrong: Cool tier has higher storage cost than Archive and is suitable for data accessed more than once a year.

Hot

Why wrong: Hot tier is for frequent access and has the highest storage cost.

Premium

Why wrong: Premium tier provides high-performance, low-latency access but is very expensive for archival storage.

Use Block blobs and append the data to a single blob

Why wrong: Block blobs are not designed for append-heavy workloads; each append requires a commit, and small blocks lead to high transaction costs and potential performance issues.

Use Page blobs and write each log entry to a page

Why wrong: Page blobs are for frequent read/write of random data, have higher cost, and are not efficient for append-only logs.

Use Block blobs and create a new blob for each log entry

Why wrong: Creating thousands of small blobs increases management overhead and transaction costs, and reduces write throughput.

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

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

Block Blob in Blob Storage with high block count

Why wrong: Block Blobs can be used for appending by managing block IDs, but they are not as efficient as Append Blobs for this scenario. Block Blobs have a block limit (50,000) and require more complex logic.

Azure Data Lake Storage Gen2 with hierarchical namespace

Why wrong: Data Lake Storage Gen2 is built on top of Blob Storage and is optimized for big data analytics and directory structures, not specifically for high-throughput append-only logs.

Azure Files with SMB protocol

Why wrong: Azure Files provides fully managed file shares, but it is not optimized for high-scale append operations and may have performance limitations for billions of small writes.