Build and release pipelines are the heart of AZ-400 — Microsoft weights this area at 50-55% of the exam, more than every other domain combined. This set starts that journey with the decisions you make before a single deployment runs: GitHub Actions or Azure Pipelines, Microsoft-hosted or self-hosted agents, which triggers fire when, how jobs and stages are ordered, and how to reuse pipeline logic safely.
This is the second post in our AZ-400 series (Questions 11-20). If you have not done the first set yet, start with AZ-400 Questions 1-10: DevOps Processes and Source Control. Every question is an original practice scenario, not a copy of a real exam item.
Pick your answer before revealing it, and read why each wrong option is wrong — that is where most of the learning happens.
Question 11: Choosing Between GitHub Actions and Azure Pipelines
Contoso hosts all of its code in GitHub, tracks work in GitHub Issues, and wants CI/CD that lives right next to the code with no additional service to administer. Which deployment automation solution best fits?
A) Azure Pipelines classic release pipelines
B) GitHub Actions
C) Azure Automation runbooks
D) Azure Logic Apps
👁 Reveal Answer
Correct Answer: B
Explanation: GitHub Actions runs workflows defined in YAML files inside the repository itself, so CI/CD is managed in the same place as the code and issues, with no separate organization to administer. A would work with GitHub repositories, but it adds an Azure DevOps organization to manage, and classic pipelines are not stored as code. C runs operational scripts, not build and release workflows. D orchestrates business integrations, not CI/CD. On the exam, “everything already in GitHub” is a strong signal for GitHub Actions; a need for Azure Boards, Azure Artifacts, or existing Azure DevOps investments points toward Azure Pipelines.
Question 12: Reaching On-Premises Servers from a Pipeline
Fabrikam must deploy to application servers inside its datacenter. The security team will not open any inbound firewall ports from the internet. Which agent setup allows Azure Pipelines to deploy to these servers?
A) Microsoft-hosted agents with a public IP allow-list on the servers
B) A Microsoft-hosted agent with a site-to-site VPN created per job
C) A self-hosted agent installed inside the datacenter network
D) Running the deployment manually and marking the pipeline stage as skipped
👁 Reveal Answer
Correct Answer: C
Explanation: A self-hosted agent polls Azure DevOps over outbound HTTPS, so it needs no inbound ports. Placed inside the datacenter, it can reach the internal servers directly while still receiving jobs from the cloud — the classic hybrid pipeline pattern. A requires inbound access from Microsoft-hosted IP ranges, which change and which the security team has ruled out. B is not a supported way to use Microsoft-hosted agents. D defeats the purpose of automation.
Question 13: Scheduled Pipeline Runs
Northwind Traders wants a YAML pipeline to run a full regression suite every weekday at 02:00 UTC, but only if main has changed since the last scheduled run. What should you add to the YAML?
A) A schedules block with a cron expression and always: false
B) A trigger block that lists main
C) A pr block that lists main
D) A schedules block with always: true
👁 Reveal Answer
Correct Answer: A
Explanation: Scheduled triggers use a schedules block with a cron expression (times are in UTC). The always setting controls whether the run happens even when nothing changed; it defaults to false, so the scheduled run is skipped if the branch has no new changes since the last successful scheduled run. B is a CI trigger that runs on every push, not on a timetable. C triggers on pull requests. D forces a run every night even with no changes, which wastes agent time.
Question 14: Running Jobs in Parallel
A stage in your YAML pipeline contains three jobs: UnitTests, Lint, and Package. Package must start only after both other jobs succeed, while UnitTests and Lint should run at the same time. Enough parallel jobs are available. How should you configure the jobs?
A) Put all three jobs in separate stages
B) Set parallel: 3 on the stage
C) Add dependsOn to every job
D) Add dependsOn: [UnitTests, Lint] to the Package job only
👁 Reveal Answer
Correct Answer: D
Explanation: Jobs in a stage with no dependsOn run in parallel when agents are available, so UnitTests and Lint start together. Adding dependsOn: [UnitTests, Lint] to Package makes it wait for both, and its default condition requires them to succeed. A forces everything to run in sequence, because stages run one after another by default, which slows the pipeline. C would create unnecessary or circular dependencies. B is not valid on a stage; the related strategy: parallel setting on a job slices one job across several agents (for example, splitting tests), which is not the same as ordering separate jobs.
Question 15: Reusing Steps Across Many Pipelines
Your organization has 40 YAML pipelines that each run the same five build and security steps. Changes to those steps must be made once and picked up by every pipeline. What should you create?
A) A YAML step template stored in a shared repository and referenced by each pipeline
B) A task group
C) A variable group containing the five commands
D) A copy of the steps pasted into each pipeline with a comment linking to the original
👁 Reveal Answer
Correct Answer: A
Explanation: YAML templates let you define steps (or jobs, stages, or variables) once and include them with - template:. Storing the template in a shared repository and referencing it as a repository resource lets every pipeline consume the same version-controlled logic. B is the reuse mechanism for classic pipelines; it does not apply to YAML. C stores values, not steps. D guarantees the 40 copies drift apart. For governance, the same idea goes further with extends templates plus a required template check, which forces pipelines to build on an approved template.
Question 16: Approvals Before Production
Woodgrove Bank’s YAML pipeline deploys to a production stage. Two release managers must approve before any deployment to production starts, regardless of which pipeline targets it. Where should you configure this?
A) In a variable group linked to the production stage
B) In the YAML file, using a manualApproval keyword on the stage
C) As a branch policy on main
D) On the production environment, as an approvals check
👁 Reveal Answer
Correct Answer: D
Explanation: In YAML pipelines, approvals and checks belong to the resource being protected — here, the production environment. Every deployment job that targets that environment, from any pipeline, waits for the required approvers. Because the check lives on the environment rather than in the YAML, a developer cannot remove it by editing the pipeline file. B is not a YAML keyword. C controls merges into a branch, not deployments. A stores values only. Other environment checks include business hours, Azure Monitor alerts, and invoking a REST API — useful for automated release gates.
Question 17: Keeping Pipeline Values in One Place
Several pipelines need the same database server name and a connection password. The password is already stored in Azure Key Vault and must not be copied anywhere else. What should you use?
A) Pipeline variables defined in each YAML file
B) A variable group linked to the Azure Key Vault
C) A secure file containing the password
D) A YAML parameter with a default value
👁 Reveal Answer
Correct Answer: B
Explanation: A variable group can be linked to an Azure Key Vault, so its secret values are read from the vault at run time rather than copied into Azure DevOps. Multiple pipelines can reference the same group, giving one place to manage shared values. A duplicates values across files and invites plain-text secrets. C is for files such as certificates or signing keys, not individual values. D stores defaults in the YAML itself, which is the wrong place for a password.
Question 18: Triggering One Pipeline from Another
Adventure Works has a build-api pipeline that publishes an artifact. A separate deploy-api YAML pipeline must start automatically whenever build-api completes successfully on main. What should you configure in deploy-api?
A) A resources: pipelines entry with a trigger for main
B) A CI trigger on main
C) A scheduled trigger every five minutes
D) A service hook that emails the release team
👁 Reveal Answer
Correct Answer: A
Explanation: A pipeline resource declares another pipeline as a dependency; adding a trigger to it starts deploy-api when build-api completes, and it can filter by branch. The triggered run can also download the artifact from that exact upstream run. B fires on code pushes to deploy-api’s own repository, not on another pipeline finishing. C polls on a timer and could deploy stale or half-finished builds. D notifies people but automates nothing.
Question 19: Scaling Self-Hosted Agents
Tailspin Toys runs dozens of self-hosted agents on Azure VMs that are idle most nights and overloaded during the day. They want agents that scale out under load, scale in when idle, and need less manual patching. What should they consider?
A) Adding more permanently running VMs
B) An elastic agent pool, such as Managed DevOps Pools or Azure virtual machine scale set agents
C) Running all jobs on a single, larger VM
D) Switching every pipeline to manual triggers
👁 Reveal Answer
Correct Answer: B
Explanation: Elastic pools grow and shrink with demand, so the team pays for capacity only when jobs are waiting, and fresh agents can be created from a maintained image. Managed DevOps Pools is Microsoft’s managed service for this; virtual machine scale set agent pools are the earlier approach the exam may also describe. A increases cost without fixing idle time. C creates a single point of failure and still cannot run many jobs at once. D hides the load problem instead of solving it. When the exam weighs agent options, think about cost, tooling, licensing (parallel jobs), network connectivity, and maintenance.
Question 20: Moving from Classic to YAML
Litware still uses classic build and release pipelines configured in the web portal. The team lead wants pipeline changes to be reviewed in pull requests and versioned alongside the application. What is the main reason to migrate to YAML pipelines?
A) YAML pipelines run faster on the same agents
B) Classic pipelines cannot deploy to Azure
C) YAML pipeline definitions live in the repository, so they are versioned, branched, and reviewed with the code
D) YAML pipelines do not need agents
👁 Reveal Answer
Correct Answer: C
Explanation: The key benefit of YAML pipelines is pipeline-as-code: the definition is a file in the repository, so every change goes through branches, pull requests, and history like application code. Many newer features — such as environments with checks and extends templates — are built for YAML too. A is false; the same tasks run on the same agents. B is false; classic pipelines can deploy to Azure. D is false; YAML jobs still run on agents (except agentless server jobs). A practical migration path is to export or recreate each classic pipeline in YAML, run both side by side, then retire the classic version.
Study Tips for AZ-400 Pipeline Design
- Learn the trigger keywords.
trigger(CI),pr(pull requests),schedules(cron, UTC), andresources: pipelines(pipeline completion) each answer a different scenario. - Know the default ordering. Stages run in sequence; jobs in a stage run in parallel unless
dependsOnsays otherwise. - Put protection on resources, not YAML. Approvals and checks live on environments, service connections, and agent pools so pipeline authors cannot remove them.
- Match the reuse tool to the pipeline type. YAML uses templates; classic uses task groups. Values go in variable groups, files in secure files.
- Think hybrid. Any scenario with private networks or strict firewalls points to self-hosted agents, which need only outbound HTTPS.
Keep Practicing for AZ-400
Next in the series is AZ-400 Questions 21-30: Package Management and Testing Strategy, covering Azure Artifacts feeds, versioning, and test integration. For deeper reading, Microsoft’s guide to approvals and checks pairs well with Question 16, and the official AZ-400 study guide lists every skill measured.
