AZ-204 Develop for Azure storage Practice Question
You are designing a solution that stores large media files (up to 5 GB each) in Azure Blob Storage. The application must support concurrent uploads with the ability to pause and resume. You need to ensure efficient use of network bandwidth and provide progress reporting. Which approach should you use?
⚠ Common exam trap
A common mix-up: candidates confuse AzCopy's resume capability with programmatic pause/resume, or assume Append blobs are suitable for large file uploads because they support chunking, but they lack the block-level control needed for concurrent uploads and progress tracking.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use the Azure Storage SDK to upload blobs in blocks, and implement pause/resume logic using block IDs.
Azure Blob Storage supports block blobs, which allow you to upload large files in independent blocks. By using the Azure Storage SDK, you can assign unique block IDs to each block, enabling pause/resume by tracking which block IDs have been committed. This approach also provides fine-grained progress reporting per block and efficient network bandwidth usage through parallel uploads.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use AzCopy with the --resume parameter.
Why it's wrong here
AzCopy is a robust command-line utility designed for high-performance data transfer to and from Azure Storage, offering built-in resume capabilities via the --resume parameter. However, the question asks about designing a solution that implies programmatic control and integration within an application. AzCopy is a standalone executable, not a library or SDK component that can be directly embedded into an application to provide custom progress reporting or fine-grained control over the upload process from within the application's code, making it unsuitable for this specific design requirement.
- ✗
Use Page blobs with 512-byte pages.
Why it's wrong here
Page blobs are specifically optimized for random read/write operations and are primarily used for Azure Virtual Machine disks, where data is accessed in 512-byte pages. While they support fixed-size pages, their underlying design is not efficient for large, sequential media file uploads. Attempting to upload a large media file by breaking it into 512-byte pages would result in excessive overhead and poor performance compared to other blob types designed for sequential data streams, making them an inappropriate choice for this scenario.
- ✓
Use the Azure Storage SDK to upload blobs in blocks, and implement pause/resume logic using block IDs.
Why this is correct
The Azure Storage SDK, when used with Block blobs, provides the most suitable mechanism for uploading large media files with pause/resume functionality. Block blobs allow files to be broken into smaller, independently uploaded blocks, each identified by a unique block ID. The SDK enables uploading these blocks concurrently, and by tracking which blocks have been successfully committed, an application can pause an upload and later resume by only re-uploading the uncommitted or missing blocks, ensuring data integrity and efficiency.
- ✗
Use Append blobs and append data in chunks.
Why it's wrong here
Append blobs are optimized for append operations, making them ideal for logging scenarios where new data is continuously added to the end of a blob. They are designed for fast, atomic appends and do not support modifying existing content or arbitrary block-level management. This append-only nature and lack of explicit block IDs for tracking individual chunks make them entirely unsuitable for implementing pause/resume logic or efficiently managing large, potentially mutable media file uploads, as they lack the necessary block-level control.
Quick reference
Azure Blob Storage Tier Comparison
| Tier | Storage Cost | Retrieval Cost | Latency | Use Case |
|---|---|---|---|---|
| Hot | Highest | Lowest | Immediate | Active data, frequent reads |
| Cool | Lower | Higher | Immediate | Data accessed < once / month |
| Cold | Lower still | Higher | Immediate | Data accessed < once / quarter |
| Archive | Lowest | Highest + rehydration delay | Hours | Long-term compliance retention |
Go deeper
Related to this question
About these practice questions
This AZ-204 question is part of Courseiva's 881-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-204 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-204 exam.