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

Question 1

Your team uses Azure Pipelines for CI/CD. You want to enforce that every build produces a versioned artifact that includes the Git commit ID. Which predefined variable should you use to get the commit ID in a YAML pipeline?

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

Accepted Answer

Build.SourceVersion. The `Build.SourceVersion` predefined variable in Azure Pipelines resolves to the commit ID (full SHA) of the commit that triggered the pipeline. This makes it the correct choice for embedding the Git commit ID into a versioned artifact. Other variables like `Build.BuildId` or `Build.SourceBranch` do not provide the commit hash.

Answer

Build.Repository.Name

Answer

Build.BuildId

Answer

Build.SourceBranch

Question 2

Refer to the exhibit. You are creating an ARM template to deploy an App Service and its Application Insights configuration. The template fails to deploy with error: 'The resource 'Microsoft.Insights/components/...' is not defined in the template.' What is the most likely cause?

Accepted Answer

The Application Insights component is not defined as a resource in the template.. The error 'The resource 'Microsoft.Insights/components/...' is not defined in the template' indicates that the ARM template references an Application Insights component (e.g., via the `reference()` function or a `dependsOn` property) that is not declared as a resource within the template's `resources` array. In ARM templates, every resource you reference must be explicitly defined; otherwise, the deployment engine cannot resolve it, causing this validation error.

Answer

The reference function cannot be used in a properties object.

Answer

The reference function syntax is incorrect.

Answer

The apiVersion for the config resource is outdated.

Question 3

Your team is adopting Azure Pipelines for a new project. You need to ensure that only authorized users can approve releases to production. Which two methods can you use to implement approval checks?

Accepted Answer

Configure pre-deployment approvals on the Production environment.. Pre-deployment approvals on the Production environment (Option A) allow you to require one or more users or groups to approve a release before it is deployed to that environment. Similarly, setting the 'Required approvers' field on the environment (Option C) specifies the users or groups that must approve the deployment, which is another native Azure Pipelines approval mechanism. Both enforce authorization at the environment level, ensuring only designated approvers can promote a release to production.

Answer

Use Deployment Gates with a manual approval gate.

Answer

Add a Manual Intervention task in the release pipeline.

Answer

Add an Approval Check to the agent pool.

Question 4

You are designing a YAML pipeline that builds a .NET application and publishes it as a NuGet package to Azure Artifacts. Which three tasks should you include in the build stage?

Accepted Answer

DotNetCoreCLI@2 with command 'build'. The DotNetCoreCLI@2 task with the 'build' command compiles the .NET application source code into intermediate language (IL) assemblies. This is a mandatory step after restoring dependencies and before packing the project into a NuGet package. Without a successful build, the subsequent pack and push operations would fail.

Answer

NuGetCommand@2 with command 'install'

Answer

DotNetCoreCLI@2 with command 'push'

Question 5

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?

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 6

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 7

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 8

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub are not exposed in build logs. A developer accidentally printed a secret to the console in a workflow step. What built-in feature of GitHub Actions automatically prevents this?

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 9

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 10

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.. To require a CI check before merge, you add a GitHub Actions workflow triggered on 'pull_request' and then configure branch protection (or a repository ruleset) to mark that workflow's job as a required status check. This blocks merging until the check passes.

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 11

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 12

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 13

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.. Option D is correct because deployment groups let a single pipeline job target a logical set of machines (defined by tags), so one pipeline run can deploy to many VMs without enumerating each machine individually. Option E is correct because deployment groups natively support rolling deployments, where the agent on each target machine runs the deployment steps and the pipeline can perform health checks and stop the rollout if a machine fails. Option A is not a deployment group feature; secrets such as connection strings are handled by Azure Key Vault, variable groups, or secret variables, not by deployment groups themselves. Option B is incorrect because deployment groups do not shut down VMs to save cost; they only orchestrate deployment to registered machines. Option C is incorrect because automatic VM scaling is provided by VM scale sets or autoscale settings, not by deployment groups.

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 14

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.. Option A is correct because environment-specific YAML variable files let a single pipeline definition load different values per environment (e.g., dev/staging/prod) without changing the pipeline logic, keeping configuration externalized and version-controlled. Option D is correct because Azure Key Vault references in variable groups retrieve secrets at runtime, so sensitive values such as connection strings or API keys are never stored in plain text in the pipeline or repo. Option E is correct because variable groups linked to the Azure DevOps library centralize shared and secret variables, allow scoping to specific stages/environments, and support approval and access controls. Option B is wrong because embedding configuration into the container image bakes environment-specific values into an immutable artifact, forcing a rebuild per environment and risking secret leakage. Option C is wrong because hardcoding configuration in pipeline scripts duplicates logic, is error-prone, and exposes secrets in source control.

Answer

Embed configuration values directly into the container image.

Answer

Hardcode configuration in pipeline scripts for each environment.

Question 15

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