AZ-204 Develop Azure compute solutions Practice Question
Which TWO conditions are required to use the 'Run from Package' feature in Azure App Service?
⚠ Common exam trap
It's easy for candidates to assume the package must be in Azure Blob Storage (Option B) or require a managed identity (Option E), but Azure App Service supports any accessible URL and uses SAS tokens for private storage, not managed identities.
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
✓
The package must be accessible via a URL if not deployed locally.
Option C is correct because 'Run from Package' requires the deployment artifact to be a ZIP archive (a .zip file), which App Service mounts as a read-only wwwroot; this is why the setting is exposed as WEBSITE_RUN_FROM_PACKAGE pointing to a .zip. Option A is correct because when the ZIP is not pushed locally via Zip Deploy/Kudu, it must be reachable through a URL that App Service can fetch, such as a SAS URL to Azure Blob Storage, OneDrive, or Dropbox, and the app runs directly from that external package. Option B is not required because the package URL can point to any accessible external location, not exclusively Azure Blob Storage. Option D is not a stated requirement; there is no fixed 500 MB limit for Run from Package (limits relate to the hosting plan and deployment method, not this feature). Option E is not required because access to the package is granted via a SAS token or public URL, not a managed identity.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The package must be accessible via a URL if not deployed locally.
Why this is correct
When utilizing the "Run from Package" deployment method for an Azure App Service, if the application package is not directly uploaded to the App Service's local file system, it must be hosted at a URL that the App Service can access. For private storage locations, such as Azure Blob Storage, this URL typically requires a Shared Access Signature (SAS) token to provide secure, time-limited access without exposing the storage account's primary keys. This allows the App Service to mount the package remotely.
- ✗
The package must be stored in Azure Blob Storage.
Why it's wrong here
While Azure Blob Storage is a highly recommended and common choice for hosting deployment packages due to its scalability and robust access control features, it is not an exclusive requirement for the "Run from Package" feature. The package can also be stored in other accessible locations, such as a public web server, or even directly uploaded to the App Service's `data/SitePackages` directory via Kudu or FTP, where it is then referenced by the `WEBSITE_RUN_FROM_PACKAGE` app setting.
- ✓
The package must be a ZIP file.
Why this is correct
The "Run from Package" feature in Azure App Service strictly requires that the deployment artifact be a standard ZIP file. This specific archive format is the only one supported by the App Service runtime for this deployment method, as it is designed to mount and execute code directly from a ZIP archive without prior extraction. This design choice optimizes application startup times and reduces disk I/O, making other archive types like TAR or GZ incompatible.
- ✗
The package size cannot exceed 500 MB.
Why it's wrong here
The maximum supported size for a deployment package when using the "Run from Package" feature in Azure App Service is 1 GB. If the package exceeds this 1 GB limit, the App Service will be unable to successfully mount and run the application, resulting in deployment failures. It is essential to ensure that the compiled application and all its necessary dependencies remain within this specified size constraint for successful operation.
- ✗
The App Service must have a managed identity to access the package.
Why it's wrong here
An Azure App Service is not strictly required to have a managed identity to access a deployment package for the "Run from Package" feature. While a system-assigned or user-assigned managed identity can be effectively used to grant secure, role-based access to private storage accounts, an equally valid and common alternative is to append a Shared Access Signature (SAS) token to the package URL. This SAS token provides temporary, delegated access without necessitating a managed identity for authentication.
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
Learn chapter
Managed Identities in Code
Key term
Managed identity
A managed identity is an automatically managed service principal in Azure that allows your code to authenticate to any service that supports Microsoft Entra ID authentication without storing credentials.
Key term
Shared Access Signatures
A Shared Access Signature (SAS) is a secure token that grants limited, time-bound access to specific Azure Storage resources without exposing your account key.
About these practice questions
Courseiva writes every AZ-204 question from scratch — 883 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.