How to Define and Version Configuration for 50 App Service Instances?

Answer Correct answer: C — store Bicep files in Azure Repos to declaratively define each App Service instance's configuration and keep a commit-based version history.

You have an Azure subscription. You plan to deploy 50 Azure App Service instances that will host code-based web apps. You need to recommend a solution to define the configuration of the instances and maintain a version history of the configurations. What should you include in the recommendation?

  1. ZIP packages in Azure Repos
  2. images in an Azure container registry
  3. Bicep files in Azure Repos Correct Answer
  4. images in Azure Compute Gallery

Community Insight

The question tests the split between deploying application code and declaring App Service configuration — the trap is picking an artifact (ZIP package or container image) that ships code or a filesystem, not the instance settings that must be versioned.

Deploying 50 code-based App Service instances requires an infrastructure-as-code approach that both declares each app's configuration and keeps a reviewable history of every change. Bicep files stored in Azure Repos satisfy both requirements, which is why they are the recommended inclusion.

Choosing ZIP packages in Azure Repos because the apps are described as 'code-based' — a ZIP package deploys the code payload, but it does not define the App Service instance configuration, so versioning the package does not version the configuration.

Community Discussion (1 comments)

12Micha 👍 1 Selected: C
Question received on exam Oct 2026.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

Bicep is a declarative infrastructure-as-code language that describes the target state of Azure resources, including App Service plans, sites, app settings, connection strings, slots and scale settings. Storing the.bicep files in Azure Repos gives every configuration change a commit history, pull-request review and the ability to roll back to a previous revision — exactly the 'maintain a version history of the configurations' requirement. The same file can be deployed repeatedly across all 50 instances using loops and parameter files, so configuration drift is eliminated. This directly addresses the design of a repeatable compute deployment rather than an application packaging strategy.

Why the Other Options Are Wrong

ZIP packages (A) are a deployment artifact for code and are not configuration definitions; versioning a ZIP in Repos versions the code payload, not the app settings or platform configuration of each instance. Container images in Azure Container Registry (B) package a containerized application and would only be relevant if the apps were container-based rather than code-based, and an image still does not describe App Service configuration such as app settings, slots or autoscale rules. Azure Compute Gallery (D) stores VM images and their versions for virtual machines and scale sets; it has no role in configuring App Service web apps.

Community Comment Notes

As 12Micha noted, this item was encountered on the exam and the selected answer was C, which aligns with the infrastructure-as-code reasoning above. The absence of a large vote spread on this item means there is no strong counter-signal from the community to weigh against the technical analysis. The consistent theme is that configuration management across many instances implies a declarative template plus a Git-based version store, not a deployment package.

Official Reference

Exam Strategy

When a scenario mentions many identical instances plus 'version history' of configuration, look for an infrastructure-as-code file in a Git repository rather than any deployment package. Separate 'what the app runs' (code/ZIP/container) from 'how the app is configured' (Bicep, ARM, app settings) before reading the options.

Frequently Asked Questions

Why are ZIP packages in Azure Repos not enough for versioning App Service configuration?

A ZIP package contains the app's code payload, not the instance configuration such as app settings, slots or scale rules, so its history does not track configuration changes.

Would Azure Container Registry images work since the apps run on App Service?

No. The apps are code-based, not containerized, and a container image still does not declare App Service configuration settings or their version history.

More AZ-305 FAQ →

Related Analysis

Practice All AZ-305 Questions

Access 95 questions with complete answers and detailed explanations.

View Full AZ-305 Practice Test →

← Back to AZ-305 Study Guide