AZ-400 Practice Question: Design and implement build and release pipelines
Your organization uses GitHub Actions with self-hosted runners on Azure virtual machines. You notice that some workflows are taking longer than expected because runners are busy. You need to improve the performance without adding more permanent runners. Which solution should you implement?
⚠ Common exam trap
Candidates often confuse vertical scaling (increasing VM size) with horizontal scaling (adding more runner instances), mistakenly believing a larger VM can process multiple jobs concurrently when in fact each self-hosted runner handles only one job at a time.
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
✓
Implement auto-scaling for self-hosted runners using a scale set or Kubernetes-based runner controller.
Auto-scaling self-hosted runners using a scale set or a Kubernetes-based runner controller (e.g., actions-runner-controller) dynamically provisions and deprovisions runner instances based on workflow demand. This eliminates idle runner waste while ensuring sufficient capacity during peak loads, directly addressing the bottleneck without adding permanent infrastructure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Migrate all workflows to GitHub-hosted runners.
Why it's wrong here
Migrating all workflows to GitHub-hosted runners can reduce queue wait times via elastic capacity, but it is often infeasible due to compliance, data-residency, or networking requirements, and hosted runners lack the custom OS and software layers that self-hosted environments provide.
- ✗
Reduce the number of concurrent jobs in each workflow.
Why it's wrong here
Reducing the number of concurrent jobs in each workflow lowers contention on the runner fleet, but it directly decreases throughput and increases end-to-end pipeline duration, causing longer developer feedback loops without addressing the underlying capacity constraint.
- ✓
Implement auto-scaling for self-hosted runners using a scale set or Kubernetes-based runner controller.
Why this is correct
Implementing auto-scaling for self-hosted runners using a scale set or Kubernetes-based Actions Runner Controller dynamically matches runner count to job demand, provisioning new runners during peak times and scaling to zero when idle, which optimizes both latency and cost.
- ✗
Increase the size of the existing self-hosted runner VMs to handle more jobs.
Why it's wrong here
Increasing the size of existing self-hosted runner VMs improves per-job compute resources and may allow more parallel jobs per runner, but it does not eliminate the concurrency ceiling of each individual runner and is a costly, static over-provisioning approach compared with horizontal auto-scaling.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
GitHub
GitHub is a cloud-based platform for storing, tracking, and collaborating on code using Git version control.
Key term
Anthos
Anthos is a Google Cloud platform that lets you run applications consistently across different computing environments, like on-premises data centers and multiple public clouds.
About these practice questions
This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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-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.