AZ-400 Practice Question: Design and implement build and release pipelines
You are a DevOps engineer for a large e-commerce company. The development team uses GitHub for source control and GitHub Actions for CI/CD. The application is a microservices architecture with 15 services, each in its own repository. You need to implement a continuous delivery pipeline that builds and deploys each service to a Kubernetes cluster in Azure (AKS). The pipeline must meet the following requirements: - Each service must have its own pipeline that triggers on pushes to the main branch. - Deployment to AKS must use Helm charts. - The pipeline must automatically increment the Helm chart version and update the deployment manifest in the repository. - Security scanning must be performed on container images before deployment. - The pipeline must support manual approval for production deployment. - All secrets (e.g., AKS credentials, registry credentials) must be stored securely and not exposed in logs. You need to design the workflow. What is the best course of action?
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 reusable workflow with OIDC authentication to Azure. Use Helm to deploy, increment chart version, and commit back. Use GitHub environments for approval gates. Integrate container scanning with Docker Scout or Trivy.
Using GitHub Actions with OIDC to authenticate to Azure avoids storing long-lived secrets. Helm chart version bumping can be done with a script. The workflow uses environments for approval gates. Container scanning using tools like Trivy can be added as a step.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use Azure Pipelines instead of GitHub Actions because it has better integration with AKS. Store secrets in Azure Key Vault and use variable groups.
Why it's wrong here
The requirement explicitly specifies GitHub Actions, so replacing it with Azure Pipelines violates the stated constraint, even though Azure Pipelines offers native AKS integration and variable groups can be linked to Azure Key Vault. This option fails to meet the core condition of using GitHub Actions as the CI/CD platform.
- ✓
Create a reusable workflow with OIDC authentication to Azure. Use Helm to deploy, increment chart version, and commit back. Use GitHub environments for approval gates. Integrate container scanning with Docker Scout or Trivy.
Why this is correct
Using OIDC eliminates long-lived Azure credentials by exchanging short-lived tokens from GitHub Actions, satisfying secure auth without storing secrets. Helm manages releases with chart version increments and rollback capabilities, and committing the bumped chart back maintains GitOps traceability. GitHub environments provide protected branches and approval gates per stage, while Trivy or Docker Scout scans container images for vulnerabilities before deployment.
- ✗
Create a workflow per service with direct deployment. Use kubectl commands to deploy. Store all secrets in a single GitHub secret. Skip security scanning to save time.
Why it's wrong here
Direct kubectl commands bypass Helm's release management, versioning, and rollback capabilities, making deployments harder to track and revert. Consolidating all secrets into a single GitHub secret violates least-privilege principles and increases the blast radius if exposed, while skipping container scanning entirely leaves known vulnerabilities unpatched and undermines security compliance.
- ✗
Create a single reusable workflow that each service calls. Use Azure CLI to deploy Helm charts. Store AKS credentials as GitHub secrets. Use a manual approval step via environment protection rules.
Why it's wrong here
Although Azure CLI is capable of deploying Helm charts, storing AKS cluster credentials as GitHub secrets creates a security liability—secrets persist in the repository and can be exposed via workflow logs or compromised third-party actions. The manual approval step via environment protection rules is a valid gate, but it does not mitigate the risk of static credential leakage. OIDC federation would be more secure, and a single reusable workflow is acceptable only if each service's deployment parameters are parameterized properly.
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
Branch
A branch is a pointer to a specific commit in a version control system that allows you to work on features or fixes in isolation from the main codebase.
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.