Isolating Smoke Test Failures So Only One Tenant's Swap Is Blocked
You are designing a release pipeline for a multi-tenant SaaS application that is deployed to Azure App Service. Each tenant has its own App Service instance. The pipeline must deploy a new version of the application to a staging slot for each tenant, run smoke tests, and then swap the staging slot to production. You need to ensure that if the smoke tests fail for any tenant, the swap is not performed for that tenant, while other tenants continue. Which release pipeline configuration should you use?
Quick Answer
Structuring the release as separate jobs per tenant within one stage keeps each tenant's deploy-test-swap sequence isolated — Azure Pipelines runs each job on its own agent with its own success/failure state. Setting the swap step's run condition to only proceed when prior steps in that job succeeded means one tenant's failed smoke test blocks only that tenant's swap, while every other tenant's job keeps running independently.
⚠ Common exam trap
It's easy for candidates to confuse job-level parallelism with task-level parallelism, assuming that parallel tasks within a single job can achieve the same isolation, but in Azure Pipelines, tasks within a job share the same agent and failure context, so a single failure can halt all tenant deployments.
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
✓
Create a release with multiple jobs (one per tenant) in the same stage, each deploying to a tenant's staging slot, running tests, and conditionally swapping. Set the 'Run this job' condition to 'Only when all previous jobs have succeeded' or use custom conditions to skip swap on failure.
It uses separate jobs per tenant within a single stage, each with its own deployment, smoke test, and conditional swap. By setting the 'Run this job' condition to 'Only when all previous jobs have succeeded' or a custom condition, you ensure that a failed smoke test for one tenant blocks only that tenant's swap, while other tenants' jobs proceed independently. This design aligns with Azure Pipelines' job-level isolation, where each job runs on its own agent and can have independent success/failure conditions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create a release with multiple jobs (one per tenant) in the same stage, each deploying to a tenant's staging slot, running tests, and conditionally swapping. Set the 'Run this job' condition to 'Only when all previous jobs have succeeded' or use custom conditions to skip swap on failure.
Why this is correct
Multiple jobs can run in parallel, and each job can independently handle success/failure for its tenant.
- ✗
Create a single stage with a 'foreach' loop over tenants, and if smoke tests fail, skip the swap using a condition.
Why it's wrong here
A loop within a single job is sequential; a failure would stop the loop unless 'continue on error' is used, but then the swap still runs.
- ✗
Create a single job with parallel tasks for each tenant, and configure failure conditions to skip the swap.
Why it's wrong here
Tasks within a job cannot run in parallel; you need multiple jobs.
- ✗
Create a single stage with multiple deployment tasks, one per tenant, and use a 'continue on error' option on each task.
Why it's wrong here
'Continue on error' allows the pipeline to continue but does not skip the swap for the failed tenant; it would still try to swap.
Visual reference
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
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.
Key term
Azure Pipelines
Azure Pipelines is a cloud-based CI/CD service from Microsoft that automatically builds, tests, and deploys code to any platform or cloud.
About these practice questions
Courseiva writes every AZ-400 question from scratch — 823 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 →
Same concept, more angles
1 more way this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You need to deploy a web app to Azure App Service using Azure Pipelines. The deployment slot should be 'staging' first, and after smoke tests, swap to production. Which deployment strategy should you use?
easy- A.Slot swap
- B.Canary deployment
- C.Rolling update
- ✓ D.Blue-green deployment
Why D: Blue-green deployment is a release strategy that uses two identical environments (blue and green). The new version is deployed to the staging slot (green), smoke tests are run, and traffic is switched to the staging slot by swapping it with the production slot (blue). Slot swap is the Azure App Service mechanism used to implement blue-green deployment, but the strategy itself is blue-green.
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.