AZ-400 Practice Question: Design and implement build and release pipelines
Your team uses a multi-stage YAML pipeline to build and deploy a .NET Core application. The build stage runs successfully, but the deployment to a Linux web app fails with an error indicating that the Kudu service cannot start because the startup command is missing. What is the most likely cause?
⚠ Common exam trap
The trap here is that candidates might think the issue is a missing web.config file (common for Windows deployments) or a permission problem, but on Linux, the startup command is the critical missing piece, not a configuration file.
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 pipeline is missing the 'AzureWebApp@1' task with a 'StartupCommand' parameter.
The Kudu service on Linux web apps requires a startup command to launch the .NET Core application. The 'AzureWebApp@1' task's 'StartupCommand' parameter specifies this command (e.g., 'dotnet myapp.dll'). Without it, Kudu cannot start the process, causing the deployment failure.
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 pipeline is missing the 'AzureWebApp@1' task with a 'StartupCommand' parameter.
Why this is correct
On Linux-based Azure App Service, the runtime is containerized and requires an explicit entry point to start the application. The AzureWebApp@1 task (or AzureWebAppContainer@1 when deploying a container) exposes a StartupCommand parameter that injects this command (for example, `pm2 start /home/site/wwwroot/server.js`) into the App Service configuration. Without that parameter, the platform falls back to a default command that may not exist, producing the exact error about a missing startup command. The fix is to add the task with the appropriate StartupCommand, or to configure the startup command in the app's Application settings.
- ✗
The service connection lacks permission to access the web app.
Why it's wrong here
A missing startup command error originates from the App Service runtime configuration layer, after the deployment artifact has already been successfully delivered to the site. If the service connection lacked permission, Azure DevOps would fail much earlier—typically with an 'Access denied', 'Authentication failed', or 'Authorization failed' error when trying to publish the artifact—not with a configuration-level message about the startup command. The error text quoted focuses on runtime configuration, not on deployment credentials, so a permission problem would produce a different category of failure entirely. Thus, this option incorrectly conflates the deployment pipeline's security state with the web app's runtime settings.
- ✗
The web app is configured with a Windows runtime stack.
Why it's wrong here
A Windows runtime stack in the web app would surface as a completely different failure type—typically an HTTP 500 error, a WebDeploy configuration mismatch, or a Web.config-related issue—not an explicit diagnostic about a missing startup command. The error message specifically identifies the target as a Linux web app, so the runtime stack is already known to be Linux, making the Windows hypothesis directly contradictory. Even if the pipeline accidentally targeted a Windows app, the deployment task would either handle it via MSDeploy or fail with a credential/permission error, never with a startup command request.
- ✗
The build output does not include the web.config file.
Why it's wrong here
Linux App Service plans do not use web.config at all; that file is IIS-specific and only meaningful for Windows-hosted applications. On Linux, the application is launched via a startup command, a container entry point, or the stack's default process manager (such as PM2 for Node.js), none of which rely on web.config. If web.config were actually required, the error would mention it or the deployment would fail during artifact parsing, not by prompting for a startup command. Therefore, this option misattributes a Windows deployment mechanism to a Linux scenario, where it is entirely irrelevant.
Go deeper
Related to this question
Learn chapter
Designing a Build Pipeline
Key term
Task
A Task in Azure DevOps is a predefined, reusable step that performs a specific action during a build or release pipeline, like compiling code or running tests.
Key term
Stage
A stage is a discrete phase in a software development or deployment pipeline where code is built, tested, integrated, or released in a controlled environment.
About these practice questions
One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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-400 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-400 exam.