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

Question 1

You need to integrate Azure Pipelines with GitHub to trigger a build when a release is published in GitHub. Which trigger type should you use in the pipeline?

Accepted Answer

resources:
  repositories:
    - repository: self
      type: github
      trigger:
        release: true. Azure Pipelines supports a GitHub release trigger through the `resources` definition, where you specify a `trigger` with `release: true` under the repository configuration. This tells the pipeline to automatically start a build whenever a new release is published in the linked GitHub repository, which directly matches the requirement.

Answer

pr:

Answer

trigger:

Answer

schedules:

Question 2

Your team is designing a build pipeline for a Java application that uses Maven. The pipeline must run unit tests and integration tests separately, and fail the build if integration tests fail. However, integration tests require a running database container. Which approach should you use to ensure the database is available for the integration tests?

Accepted Answer

Use a Docker Compose task in the pipeline to start the database container before running integration tests.. Docker Compose allows you to define and start a database container as a dependency before running integration tests in a build pipeline. By using a Docker Compose task, you can ensure the database container is running in a clean, isolated environment, and the pipeline can fail the build if the integration tests fail. This approach is ideal for CI/CD pipelines where ephemeral, disposable infrastructure is needed for testing.

Answer

Configure the pipeline to use a self-hosted agent that has the database already installed and running.

Answer

Install the database as a service in the pipeline using the Service Fabric task.

Answer

Use a PowerShell script in the pipeline to install and start the database on the build agent.

Question 3

Your organization uses GitHub Actions for CI/CD. You need to ensure that deployment to production only occurs after a successful deployment to a staging environment and requires approval from a senior developer. The deployment workflow is defined in a single YAML file. What is the most efficient way to achieve this?

Accepted Answer

Use two environments (staging and production) with required reviewers on the production environment, and use conditional steps to deploy to staging first.. GitHub Actions supports deployment environments with required reviewers. By defining separate 'staging' and 'production' environments, you can use a conditional step to deploy to staging first, and then require manual approval from a senior developer before the production deployment proceeds. This approach is built into GitHub Actions and does not require external webhooks or manual workflow triggers, making it the most efficient and secure method.

Answer

Add a step that pauses the pipeline until a manual approval is received via a custom webhook.

Answer

Use a workflow_dispatch trigger and require the senior developer to manually run the production deployment.

Answer

Use a build matrix to run staging and production deployments in parallel.

Question 4

Your Azure DevOps pipeline uses a YAML template to avoid duplication. The template defines common build steps. You need to override one of the steps in a specific pipeline without modifying the template. Which approach should you use?

Accepted Answer

Use template parameters with a 'steps' object that can be injected to override the step.. Azure DevOps YAML templates support parameterized steps objects. By defining a template parameter of type 'steps' with a default value, the calling pipeline can pass a custom steps object as an argument to that parameter, effectively overriding the default steps without modifying the template. No 'replace' keyword is used; the override is achieved by directly injecting the steps object via the parameter.

Answer

Use the 'overrides' keyword in the pipeline YAML to specify which steps to replace.

Answer

Create a copy of the template and modify the step directly.

Answer

Use a conditional 'if' statement in the template to skip steps based on a parameter.

Question 5

Your release pipeline deploys a .NET Core web app to Azure App Service using a deployment slot for staging. The pipeline runs integration tests against the staging slot. After tests pass, you want to swap the staging slot with production. However, the swap fails sometimes because the staging slot has different configuration settings. What is the best practice to ensure swapping succeeds?

Accepted Answer

Use slot-specific configuration settings (deployment slot settings) for connection strings and app settings that differ between slots.. Azure App Service allows you to mark specific configuration settings (like connection strings and app settings) as 'deployment slot settings.' When a setting is marked as slot-specific, it stays with the slot during a swap, preventing failures caused by mismatched configurations. This ensures that the staging slot retains its test-specific settings (e.g., a test database connection string) while the production slot keeps its own settings, making the swap predictable and reliable.

Answer

Manually update the production slot settings to match staging before each swap.

Answer

Perform a swap with preview and then complete the swap after verifying the staging slot.

Answer

Write a custom PowerShell script to copy configuration from staging to production before swapping.

Question 6

Your organization uses Azure Pipelines to build a large monolithic application. The build takes over 60 minutes. Management wants to reduce the build time to under 30 minutes. The application has multiple independent modules that could be built in parallel. What is the most effective strategy to reduce build time?

Accepted Answer

Refactor the build pipeline to use multiple parallel jobs, each building a separate module.. The build time is dominated by sequential compilation of independent modules. By refactoring the pipeline to use multiple parallel jobs, each building a separate module, Azure Pipelines can leverage its built-in parallelism to reduce wall-clock time significantly. This directly addresses the root cause—lack of concurrency—without sacrificing code quality or infrastructure cost.

Answer

Reduce the number of unit tests run during the build.

Answer

Upgrade the build agent to a larger VM size with more CPU and memory.

Answer

Move the build to a self-hosted agent in the same network as the source code repository.

Question 7

Your Azure DevOps pipeline uses a variable group to store secrets. The variable group is linked to a Key Vault. You need to use a secret variable in a pipeline task. How should you reference the secret in the YAML pipeline?

Accepted Answer

Reference the variable as $(VariableName) in the pipeline tasks.. When a variable group is linked to an Azure Key Vault, secret variables are automatically available in the pipeline. You can reference them directly using the standard $(VariableName) syntax in any pipeline task. No special task or script is required. Option A is incorrect because you do not need to restrict to script tasks or use 'env' mapping; the $(VariableName) works everywhere. Option B is incorrect because 'task.getVariable' is a scripting method used within tasks, not a YAML syntax. Option D is incorrect because the Azure Key Vault task is unnecessary; the variable group handles the retrieval automatically.

Answer

Reference the variable as $(VariableName) but only in a script task using 'env' mapping.

Answer

Use the 'task.getVariable' method in a PowerShell script.

Answer

Use the Azure Key Vault task to retrieve the secret and then reference the output variable.

Question 8

You are setting up a GitHub Actions workflow to deploy an Azure Resource Manager (ARM) template. The workflow must run whenever a pull request is opened against the main branch. Which trigger should you use?

Accepted Answer

pull_request: branches: [main] types: [opened]. The `pull_request` trigger with `branches: [main]` and `types: [opened]` ensures the workflow runs only when a pull request targeting the `main` branch is newly opened. This is the correct trigger for the stated requirement. Note that `pull_request` events from forks run with limited permissions and do not have access to repository secrets by default, which is a safety measure. If secrets are required for deployment, additional configuration such as using `pull_request_target` (with caution) or environment-scoped secrets would be necessary, but the trigger itself remains `pull_request`.

Answer

pull_request_target: branches: [main]

Answer

workflow_dispatch

Answer

push: branches: [main]

Question 9

Your Azure DevOps pipeline deploys a microservice to a Kubernetes cluster using Helm. The Helm chart requires a values file that contains environment-specific configurations. You want to store the values file securely and use it during deployment. What is the recommended approach?

Accepted Answer

Store the values file as a secure file in Azure Pipelines library.. Azure Pipelines Library's Secure Files feature allows storing files like Helm values securely and referencing them in pipeline tasks (e.g., HelmDeploy with the 'filePath' parameter). Option A is incorrect because variable groups store key-value pairs, not entire files. Option B is incorrect because the HelmDeploy task's 'overrideValues' parameter expects individual key-value overrides, not a file; Azure Key Vault is for secrets, but using it for a whole values file is not straightforward. Option D is incorrect because storing the values file in a separate Git repository still exposes it to source control, reducing security compared to Secure Files.

Answer

Store the values in a variable group and map them to Helm values.

Answer

Store the values file in Azure Key Vault and use the HelmDeploy task's 'overrideValues' parameter to set values.

Answer

Store the values file in a separate Git repository and clone it during the pipeline.

Question 10

Your team uses Azure Repos for source control. You need to enforce that all builds must pass unit tests before code can be merged into the main branch. Which branch policy should you configure?

Accepted Answer

Add a build validation policy that triggers the CI pipeline and requires it to succeed.. Azure Repos branch policies allow you to add a build validation policy that triggers a CI pipeline (e.g., a YAML or classic build pipeline) and requires it to succeed before a pull request can be completed. This ensures that all code merged into the main branch has passed unit tests, enforcing quality gates directly in the PR workflow.

Answer

Require a linked work item.

Answer

Require a minimum number of reviewers.

Answer

Require comment resolution.

Question 11

Which TWO of the following are valid ways to trigger a release pipeline in Azure DevOps? (Select TWO.)

Accepted Answer

Continuous deployment trigger after a build completes.. Azure DevOps release pipelines can be triggered in multiple ways. A continuous deployment trigger (A) automatically creates a release whenever a build artifact is successfully produced. A scheduled release trigger (E) creates a release at a defined time (e.g., nightly). Manual release creation via the 'Create release' button (C) is a manual action, not an automated configured trigger. Pull request triggers (D) are valid only for build pipelines, not release pipelines. 'Source version trigger' (B) is not a standard release trigger type. Therefore, the two valid trigger types are A and E.

Answer

Source version trigger.

Answer

Manual trigger via the 'Create release' button.

Answer

Pull request trigger.

Question 12

Which THREE of the following are best practices for managing secrets in Azure Pipelines? (Select THREE.)

Accepted Answer

Use Azure Key Vault to store secrets and link them to variable groups.. Azure Key Vault is the recommended service for securely storing and managing secrets, keys, and certificates. By linking a Key Vault to a variable group in Azure Pipelines, you can reference secrets without exposing them in YAML or logs, and the pipeline retrieves them at runtime using a managed identity or service principal. This approach ensures secrets are never hardcoded and access can be audited and controlled centrally.

Answer

Hardcode secrets directly in the YAML file and use variable substitution at runtime.

Answer

Enable 'Allow scripts to access the OAuth token' for all build pipelines.

Question 13

Which THREE of the following are valid deployment strategies that can be implemented using Azure DevOps release pipelines? (Select THREE.)

Accepted Answer

Rolling deployment.. Rolling deployment is a valid strategy in Azure DevOps release pipelines, where instances of the previous version are gradually replaced with the new version, typically by updating a subset of instances (e.g., in a virtual machine scale set or Kubernetes cluster) while the rest continue serving traffic. Blue-green deployment is also valid, maintaining two identical environments and switching all traffic from the blue (old) to the green (new) environment after validation, often implemented using deployment slots or Kubernetes namespaces. Canary deployment is a third valid strategy, where a small percentage of traffic is routed to the new version initially, gradually increasing it while monitoring health, commonly implemented with deployment slots or progressive exposure in Kubernetes. Red-black, while sometimes used as a synonym for blue-green, is not a distinct deployment strategy recognized in Azure DevOps documentation, and linear deployment is not a recognized industry-standard pattern.

Answer

Red-black deployment.

Answer

Linear deployment.

Question 14

Your team uses Azure Pipelines for CI/CD. You need to enforce that all pipeline runs use approved agents from a specific agent pool with the latest security patches. The agents are self-hosted on Azure VMs. What should you implement?

Accepted Answer

Add a demand on the agent for a custom capability that only approved agents have. By adding a demand for a custom capability (e.g., 'SecurityPatchLevel = latest') on the pipeline, only agents that possess that capability can run the pipeline. This allows you to enforce that only approved, patched agents are used. Option C is incorrect because 'setting an agent pool to use a specific agent queue with an isolation scope' is not a recognized Azure Pipelines feature; agent pools use demands, not isolation scopes, to filter agents. Options A and B are also incorrect because configuring pool permissions or creating a deployment pool does not enforce that only agents with specific patches are used; they only control access or assignment but not the selection logic based on capabilities.

Answer

Configure pipeline permissions for the agent pool

Answer

Create a deployment pool and assign the agents to it

Answer

Set the agent pool to use a specific agent queue with an isolation scope

Question 15

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub Actions are not exposed in logs. A developer accidentally logs a secret using 'echo ${{ secrets.API_KEY }}' in a workflow step. What is the default behavior?

Accepted Answer

The secret value is masked with asterisks in the log output. GitHub Actions automatically masks secrets in workflow logs. When a secret is used in a step (e.g., via `${{ secrets.API_KEY }}`), GitHub replaces any occurrence of the secret's value in the log output with `***`. This redaction happens at runtime, so even if a developer accidentally echoes the secret, the log will show asterisks instead of the actual value.

Answer

The secret value is replaced with an empty string in the log

Answer

The workflow run fails with an error about secret exposure

Answer

The secret is redacted before the step runs, and the step fails if it tries to use the secret