AZ-400 Design and implement build and release pipelines Practice Test 27 — 15 Questions

Question 1

Your organization uses GitHub Actions for CI/CD. You need to ensure that workflows are only triggered when changes are pushed to the main branch or when a pull request is opened against main. Which two trigger types should you specify in the workflow?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

pull_request: branches: [ main ]. The `pull_request` trigger with `branches: [ main ]` ensures the workflow runs when a pull request is opened (or updated) targeting the main branch. Option B is correct because the `push` trigger with `branches: [ main ]` ensures the workflow runs when commits are pushed directly to the main branch. Together, these two triggers cover the exact requirement: changes pushed to main and pull requests opened against main.

Answer

release

Answer

workflow_dispatch

Answer

schedule

Question 2

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?

Accepted Answer

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

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.

Answer

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.

Answer

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.

Question 3

Your team uses a multi-stage YAML pipeline to build and deploy a .NET Core application. The build stage runs successfully, but the deployment to a Linux web app fails with an error indicating that the Kudu service cannot start because the startup command is missing. What is the most likely cause?

Accepted Answer

The pipeline is missing the 'AzureWebApp@1' task with a 'StartupCommand' parameter.. The Kudu service on Linux web apps requires a startup command to launch the .NET Core application. The 'AzureWebApp@1' task's 'StartupCommand' parameter specifies this command (e.g., 'dotnet myapp.dll'). Without it, Kudu cannot start the process, causing the deployment failure.

Answer

The service connection lacks permission to access the web app.

Answer

The web app is configured with a Windows runtime stack.

Answer

The build output does not include the web.config file.

Question 4

Your organization uses GitHub Actions for CI/CD. You need to ensure that workflows are only triggered when changes are pushed to the main branch or when a pull request is opened against main. Which two trigger types should you specify in the workflow?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Automatic log redaction. GitHub Actions includes a built-in feature that automatically redacts secrets from workflow run logs. When a secret is printed to the console, GitHub detects the secret value and replaces it with '***' in the log output, preventing accidental exposure. This redaction happens at the log rendering layer, not in the workflow execution, so the secret is never visible to users viewing the logs.

Answer

Audit log monitoring

Answer

Secret scanning alerts

Answer

Required reviewers on workflows

Question 5

You are configuring a release pipeline in Azure DevOps to deploy to multiple environments (dev, test, prod). You need to ensure that the production deployment requires manual approval from the release manager. What should you configure?

Accepted Answer

Set pre-deployment approvals on the production stage.. Pre-deployment approvals on the production stage enforce manual sign-off before any deployment to that environment begins. This ensures the release manager must explicitly approve the deployment, meeting the requirement for manual approval on production. Azure DevOps stages support pre-deployment and post-deployment approval gates, with pre-deployment being the correct choice for controlling when a stage starts.

Answer

Add a manual intervention task before the production deployment.

Answer

Set post-deployment approvals on the test stage.

Answer

Use a condition on the production stage to check a variable.

Question 6

You are designing a build validation policy for a GitHub repository. You want to ensure that all pull requests pass a CI check before they can be merged. What should you configure?

Accepted Answer

Add a GitHub Actions workflow that runs on 'pull_request' and set it as a required status check in branch protection.. Branch protection rules in GitHub can require status checks to pass before merging. You set up a rule that requires the CI workflow to succeed.

Answer

Enable Dependabot alerts on the repository.

Answer

Configure a repository rule to require a pull request before merging.

Answer

Create a webhook to trigger a build on Azure Pipelines.

Question 7

Your Azure Pipelines build takes 45 minutes. You want to reduce build time by caching dependencies. Which task should you add to the pipeline?

Accepted Answer

Cache@2. Cache@2 is the correct task because it allows you to cache dependencies (e.g., npm packages, Maven artifacts) between pipeline runs, significantly reducing build time by avoiding re-downloading unchanged dependencies. This task stores and restores a cache keyed by a hash of the dependency files, enabling incremental builds.

Answer

PublishBuildArtifacts@1

Answer

CopyFiles@2

Answer

DownloadBuildArtifacts@0

Question 8

You have a classic release pipeline that deploys to Azure App Service. You need to implement a canary deployment strategy where 10% of traffic is routed to the new version for 30 minutes before full rollout. What should you use?

Accepted Answer

Deploy to a staging slot and then use Azure CLI to update routing rules after deployment.. Canary deployment on Azure App Service is achieved by deploying to a deployment slot and then configuring routing rules to send a percentage of traffic to that slot. In a classic release pipeline, you can use the Azure App Service deploy task to deploy to a slot, followed by an Azure CLI task to set the traffic percentage (e.g., az webapp traffic-routing set). The 'Swap with preview' feature is for multi-phase swap validation, not for setting traffic percentages.

Answer

Configure multiple deployment slots and use Traffic Manager to distribute traffic.

Answer

Use the 'Azure App Service deploy' task with the 'Deploy to Slot' option, then manually adjust routing rules.

Answer

Use slot swap with 'Swap with preview' and set traffic percentage in the swap settings.

Question 9

Your team uses Azure Pipelines for CI/CD. You need to enforce that all builds sign the assemblies with a code signing certificate stored in Azure Key Vault. What is the recommended approach?

Accepted Answer

Use the 'Azure Key Vault' task to download secrets and then a 'PowerShell' task to sign.. Use the Azure Key Vault task to download the certificate as a secure secret, then use a PowerShell task to sign the assemblies with that certificate.

Answer

Store the certificate as a secure file in the pipeline library and use the 'Download Secure File' task.

Answer

Embed the certificate in the repository and use a script to sign.

Answer

Use the 'Azure CLI' task to retrieve the certificate and then sign.

Question 10

You want to trigger a pipeline automatically when a new tag is pushed to a GitHub repository. Which trigger should you configure in the pipeline YAML?

Accepted Answer

trigger: tags:. The `trigger` block in Azure Pipelines YAML supports a `tags` filter that instructs the pipeline to run automatically when a Git tag matching the specified pattern is pushed. By configuring `trigger: tags: include: ['*']` or a specific tag pattern, the pipeline will start on any new tag push to the GitHub repository, which is the exact requirement.

Answer

pr:

Answer

schedules:

Answer

resources: pipelines:

Question 11

Which TWO are benefits of using deployment groups in Azure Pipelines compared to using individual virtual machines?

Accepted Answer

Simplified targeting of multiple machines with a single pipeline run.. Deployment groups in Azure Pipelines allow you to target multiple machines with a single pipeline run by logically grouping them, enabling parallel or rolling deployments across all machines in the group. This simplifies management compared to configuring each individual VM separately in the pipeline, as you can define the group once and reuse it across releases.

Answer

Built-in secrets management for connection strings.

Answer

Reduced cost because VMs are shut down when not in use.

Answer

Automatic scaling of virtual machines based on load.

Question 12

Which THREE are valid strategies for managing configuration in a multi-environment CI/CD pipeline?

Accepted Answer

Store configuration in environment-specific YAML variable files.. Using variable groups, Key Vault references, and environment-specific YAML variable files are all valid. Storing config in the container image is not recommended because it couples the image to an environment. Hardcoding in scripts is bad practice.

Answer

Embed configuration values directly into the container image.

Answer

Hardcode configuration in pipeline scripts for each environment.

Question 13

Which TWO tasks can be used to run unit tests in an Azure Pipeline?

Accepted Answer

DotNetCoreCLI@2. The DotNetCoreCLI@2 task can run unit tests for .NET Core and .NET 5+ projects by invoking the 'dotnet test' command, which discovers and executes tests in the specified project files. The VSTest@2 task runs unit tests using the Visual Studio Test Runner, supporting a wide range of test frameworks (MSTest, xUnit, NUnit) and can run tests from assemblies or test containers. Both tasks are designed specifically for executing unit tests within an Azure Pipeline, making them the correct choices.

Answer

NuGetCommand@2

Answer

PublishBuildArtifacts@1

Answer

CopyFiles@2

Question 14

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?

Accepted Answer

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

Use Azure Pipelines instead of GitHub Actions because it has better integration with AKS. Store secrets in Azure Key Vault and use variable groups.

Answer

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.

Answer

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.

Question 15

Your organization uses Azure DevOps Server (on-premises) and is planning to migrate to Azure DevOps Services. You have hundreds of build and release pipelines. The migration must be done with minimal downtime and with validation that each pipeline works after migration. You have a test collection of 20 critical pipelines that must be validated first. What is the best approach?

Accepted Answer

Use the Azure DevOps Migration Tools to replicate the test pipelines to a new Azure DevOps Services organization. Validate, fix issues, then migrate the remaining pipelines in batches.. Using the Azure DevOps Migration Tools to perform a trial migration to a test organization allows you to validate and fix issues before migrating the full collection. Direct upgrade is not supported. Manual recreation is error-prone and not minimal downtime. Skipping validation risks breaking pipelines.

Answer

Export all pipelines as JSON from the server and import them into Azure DevOps Services. Skip validation to save time.

Answer

Manually recreate the 20 critical pipelines in Azure DevOps Services and test them. Then recreate the rest manually.

Answer

Perform an in-place upgrade of Azure DevOps Server to the latest version, then migrate to Azure DevOps Services using the Data Migration Tool.