Technical Lab: Create an App Service
Questionsβ
Question 1 β Multiple Choiceβ
You need to host a web application that requires automatic scaling based on CPU metrics and support for deployment slots. When creating the App Service Plan, which minimum tier meets both of these requirements simultaneously?
A) Free (F1) B) Basic (B1) C) Standard (S1) D) Shared (D1)
Question 2 β Technical Scenarioβ
A developer published an application update using Azure CLI:
az webapp deployment source config-zip \
--resource-group rg-prod \
--name myapp \
--src ./build.zip
After the deployment, users report they continue to see the old version. The developer confirms that the build.zip file contains the updated code. What is the most likely cause?
A) The config-zip command only works with linked Git repositories; ZIP deployment requires a different command.
B) The App Service is on a Free tier, which doesn't support CLI deployment.
C) The production slot didn't receive the deployment; the default target may have been overridden by a different active slot configuration.
D) The App Service didn't automatically restart after ZIP deployment, and the old process is still running.
Question 3 β True or Falseβ
An App Service Plan on the Basic (B1) tier supports creating additional deployment slots beyond the production slot.
Question 4 β Multiple Choiceβ
When creating an App Service via Azure portal, the "Always On" option is available in general settings. Which statement correctly describes the behavior of this configuration?
A) Keeps the application loaded in memory permanently, avoiding cold starts, but is only available from the Standard tier onwards. B) Ensures high availability by automatically replicating the instance across multiple regions. C) Prevents the App Service from being deallocated during periods of inactivity, available from the Basic tier onwards. D) Enables continuous monitoring via Application Insights at no additional cost.
Question 5 β Technical Scenarioβ
A team configured the following in the App Service:
Stack: .NET 8
Operating System: Linux
Tier: Premium P1v3
Region: East US
When trying to enable the WebJobs functionality, the button appears disabled in the portal. What is the correct explanation?
A) WebJobs requires Premium P2v3 tier or higher; P1v3 doesn't offer support. B) WebJobs is not supported in App Services with .NET stack on Linux; the feature is only available on Windows plans. C) The East US region has a temporary capacity restriction for WebJobs on the Premium tier. D) WebJobs requires the App Service to be linked to a Storage account before being enabled.
Answer Key and Explanationsβ
Answer Key β Question 1β
Answer: C
The Standard (S1) tier is the minimum that offers both features simultaneously: autoscale based on metrics and deployment slots. The Basic tier offers manual scaling and doesn't support additional slots. The Free and Shared don't offer either feature, besides running on shared infrastructure without uptime SLA.
The common misconception is associating Basic with autoscale because it supports multiple instances, but scaling in Basic is exclusively manual. Choosing B1 would result in an environment unable to automatically respond to load spikes and without support for zero-downtime deployment strategies.
Answer Key β Question 2β
Answer: D
ZIP deployment with config-zip correctly transfers and extracts files, but the App Service doesn't automatically restart the application process after this type of publication in all scenarios. Depending on the runtime configuration and operating system (especially Linux), the process may continue serving code from memory until an explicit restart.
Alternative A is incorrect: config-zip is exactly the correct command for ZIP deployment. Alternative B is false since CLI works on any tier with deployment enabled. Alternative C, although plausible in environments with multiple slots, is not supported by the scenario, which doesn't mention configured slots. The key point is the restart behavior after ZIP deployment.
Answer Key β Question 3β
Answer: False
The Basic tier doesn't support deployment slots. Additional slots (beyond the default production slot) are only available from the Standard tier onwards, which allows up to 5 slots, reaching 20 slots in the Premium tier.
This is a tier limitation often underestimated. Basic offers manual scaling and support for custom domains and SSL, making it attractive for development environments, but the absence of slots prevents blue/green deployment strategies or staging validation before promotion to production.
Answer Key β Question 4β
Answer: A
Always On keeps the App Service worker process continuously active, preventing the application from being unloaded after periods of inactivity. This behavior avoids cold starts on the first request after idleness. The feature is available from the Basic tier onwards, not Standard as incorrectly indicated in alternative A, so read carefully: the correct alternative describes the functional behavior correctly (avoid cold starts, keep in memory), but states availability from Standard onwards.
Important correction: Always On is available from Basic (B1) onwards, not Standard. Alternative A describes the behavior correctly but gets the tier wrong. The other alternatives describe completely different functionalities: B describes Traffic Manager/multi-region, C swaps the behavior for the infrastructure allocation concept, and D confuses Always On with Application Insights. Alternative A, even with the imprecise tier detail, is the only one that describes the actual purpose of the feature. In a real exam, identify the alternative that describes the correct purpose of the configuration.
Answer Key β Question 5β
Answer: B
WebJobs is not supported on App Services running Linux. This is a documented platform limitation by Microsoft: WebJobs depends on Windows environment components (SCM/Kudu in Windows mode) and is not available for Linux-based plans, regardless of tier or language stack.
The conceptual error in the other alternatives is attributing the limitation to tier (A), region (C), or external resource dependency (D), when the restriction is structural to the plan's operating system. When choosing Linux as the OS for an App Service Plan, functionalities like WebJobs and certain types of site extensions become unavailable by design, not by configuration.