AZ-400 Practice Question: Design and implement build and release pipelines
You are a DevOps engineer at a large enterprise that develops a cloud-native application using microservices architecture. The application consists of 15 microservices, each stored in a separate GitHub repository. Your team uses GitHub Actions for CI/CD and Azure Kubernetes Service (AKS) for production. The current deployment process is manual and error-prone. You need to design an automated CI/CD pipeline that supports the following requirements:
1. Each microservice must have its own build and test pipeline triggered on pull requests and merges to the main branch. 2. Upon merging to main, a container image must be built, tagged with the Git commit SHA, and pushed to Azure Container Registry (ACR). 3. A separate release pipeline must deploy the updated images to AKS using a GitOps approach with Flux v2. 4. The release pipeline must support rolling back to a previous version quickly if a deployment fails. 5. The entire solution must be defined as code to ensure reproducibility.
Which approach should you recommend?
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
✓
Use GitHub Actions in each microservice repo for CI to build and push images to ACR. Use a separate GitOps repository that contains Kubernetes manifests. Configure Flux v2 in AKS to sync from the GitOps repo. When a new image is pushed to ACR, update the manifest in the GitOps repo via a GitHub Action, triggering Flux to deploy. For rollback, revert the commit in the GitOps repo.
It aligns with all requirements: each microservice has its own GitHub Actions CI pipeline (requirement 1), images are built and pushed to ACR with commit SHA tags (requirement 2), a separate GitOps repo with Flux v2 handles deployment to AKS (requirement 3), rollback is achieved by reverting the Git commit (requirement 4), and everything is defined as code in repositories (requirement 5). Option A is wrong because it uses a monorepo, violating the separate repository requirement, and uses kubectl in the pipeline instead of GitOps. Option B is wrong because it uses Azure Pipelines, which is not consistent with GitHub Actions, and uses Helm rollback instead of Git-based rollback. Option C is wrong because it deploys directly via kubectl in the same workflow, mixing CI and CD, and uses Argo CD instead of Flux v2 as specified.
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 single monorepo with all microservices. Use GitHub Actions with a multi-branch pipeline that builds only changed services. Deploy to AKS using kubectl commands in the pipeline. For rollback, redeploy the previous image tag.
Why it's wrong here
A monorepo contradicts the explicit requirement for separate repositories per microservice, breaking independent versioning and team autonomy. Deploying with kubectl directly from the pipeline bypasses GitOps (no declarative state in Git), and rolling back by manually redeploying a previous image tag is error-prone, lacking the auditability and automatic reconciliation that Flux v2 provides via reverting a commit.
- ✗
Use Azure Pipelines with a single build pipeline that triggers on any change in any repo using webhooks. Use Azure DevOps Release Pipelines to deploy to AKS using Helm. Store Helm charts in Azure Container Registry. For rollback, use Helm rollback command.
Why it's wrong here
A single Azure Pipeline triggered from multiple repositories tightly couples all microservice CI/CD, so a change in any one service invokes the same pipeline for all, breaking independent versioning and team autonomy. This approach also treats rollback as an imperative Helm rollback command, which is out-of-band and not reflected in Git, causing the cluster to drift from a declarative desired state and leaving no auditable history. Additionally, it introduces Azure Pipelines as a separate CI/CD platform, adding toolchain fragmentation rather than keeping everything native to GitHub Actions.
- ✗
Use GitHub Actions for CI and deploy directly to AKS using kubectl in the same workflow. Store Kubernetes manifests in each microservice repo. Use Argo CD to monitor the repos and sync.
Why it's wrong here
Deploying kubectl commands directly from a GitHub Actions workflow is an imperative deployment anti-pattern that bypasses GitOps entirely, so the cluster's actual state is not reconciled from a centralized declarative source. Storing manifests in each microservice repo scatters the desired state across many repositories, making coordinated, atomic rollbacks and a complete audit trail nearly impossible. Adding Argo CD to monitor the repos is contradictory and redundant because the workflow already applies changes imperatively, and Argo CD is not as native to Azure/GitHub as Flux v2, which is the preferred GitOps operator for AKS.
- ✓
Use GitHub Actions in each microservice repo for CI to build and push images to ACR. Use a separate GitOps repository that contains Kubernetes manifests. Configure Flux v2 in AKS to sync from the GitOps repo. When a new image is pushed to ACR, update the manifest in the GitOps repo via a GitHub Action, triggering Flux to deploy. For rollback, revert the commit in the GitOps repo.
Why this is correct
This pattern correctly separates CI from CD: each microservice repository has its own GitHub Actions workflow to build and push only its image to ACR, preserving independent versioning and team autonomy. Kubernetes manifests live in a dedicated GitOps repository, and Flux v2 running in AKS continuously reconciles the cluster to that repository, so updating an image tag in a commit automatically triggers the deployment. Rollback is simply a git revert of that commit, giving an immutable, auditable, declarative rollout/rollback workflow with Git as the single source of truth—fully satisfying the requirements for GitHub Actions, AKS, and GitOps-based rollback.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
Key term
DevOps
DevOps is a set of practices that combines software development (Dev) and IT operations (Ops) to shorten the development lifecycle and deliver high-quality software continuously.
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 →
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.