AZ-400 Quick Quiz — 10 Questions

Question 1

Which THREE factors should you consider when designing a release pipeline for a critical production application? (Choose three.)

Accepted Answer

Rollback strategy. A release pipeline for a critical production application must include a rollback strategy (e.g., deployment slots or redeploying a previous artifact) to recover quickly from failed releases, deployment health monitoring (e.g., Application Insights, Azure Monitor) to detect issues early and trigger rollbacks or alerts, and approval gates before production deployment to ensure manual or automated checks are passed. These three factors together minimize downtime and ensure controlled, safe releases.

Answer

Use of service principal with least privilege

Answer

Single environment deployment

Question 2

Drag and drop the steps to implement a branch policy in Azure Repos for pull requests into the correct order.

Accepted Answer

Step 1: Access the repository settings. Step 2: Select the branch for which to configure the policy. Step 3: Add policy requirements (e.g., minimum reviewers, linked work items). Step 4: Save the policy.. Branch policies are set by accessing repo settings, selecting branch, adding requirements, and saving.

Answer

Step 1: Select the branch. Step 2: Add policy requirements. Step 3: Access the repository settings. Step 4: Save the policy.

Answer

Step 1: Access the repository settings. Step 2: Add policy requirements. Step 3: Select the branch. Step 4: Save the policy.

Answer

Step 1: Access the repository settings. Step 2: Select the branch. Step 3: Save the policy. Step 4: Add policy requirements.

Question 3

Your team uses Azure Pipelines to build and test code. You want to automatically trigger a pipeline when a pull request is created targeting the main branch. Which trigger should you configure?

Accepted Answer

PR trigger. A PR trigger is the correct choice because Azure Pipelines supports a 'pr' trigger that automatically starts a pipeline when a pull request is created targeting a specified branch (e.g., main). This is distinct from a CI trigger, which runs on commits to a branch, and is essential for validating changes before merging.

Answer

Scheduled trigger

Answer

CI trigger

Answer

Manual trigger

Question 4

You are designing a release pipeline that must deploy to multiple environments in sequence: Dev, Test, and Prod. Each environment requires manual approval before deployment. You want to minimize the number of approvals while ensuring that Prod is never deployed without approval. What should you do?

Accepted Answer

Add a pre-deployment approval only to the Prod environment.. Configuring a pre-deployment approval only on the Prod environment ensures that Prod deployments are gated by manual approval, while Dev and Test deploy automatically. This reduces the total number of approvals to one per release, meeting the requirement to minimize approvals and protect Prod. It is the most efficient approach for sequential environments.

Answer

Use a single approval for all environments by adding an approval to the pipeline.

Answer

Add a post-deployment approval to the Test environment.

Answer

Add a pre-deployment approval to each environment.

Question 5

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 6

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 7

Your team uses GitHub Actions for CI/CD. You want to reuse a workflow across multiple repositories without duplicating code. Which approach should you use?

Accepted Answer

Create a reusable workflow in a central repository and reference it using 'uses: owner/repo/.github/workflows/workflow.yml@ref'.. GitHub Actions supports reusable workflows that allow you to define a workflow in a central repository and reference it from other repositories using the 'uses' syntax with the format 'owner/repo/.github/workflows/workflow.yml@ref'. This eliminates code duplication while maintaining a single source of truth for the workflow logic, and the referenced workflow can be triggered by events in the caller repository.

Answer

Store the workflow in a shared repository and use environment secrets to share credentials.

Answer

Create a composite action and reference it from each workflow.

Answer

Create a workflow template in the organization's .github repository.

Question 8

You are designing a release pipeline that deploys to multiple environments (dev, test, prod) with approval gates between each. You need to ensure that the same build artifact is deployed to all environments. Which strategy should you use?

Accepted Answer

Use a single build pipeline and promote the same build artifact through each environment.. Promoting the same build artifact through each environment ensures consistency and traceability. In Azure Pipelines, a single build produces one immutable artifact; deploying that same artifact across dev, test, and prod eliminates the risk of environment-specific build variations. Approval gates between stages control the promotion, while the artifact remains unchanged.

Answer

Use a multi-stage YAML pipeline with a separate artifact for each stage.

Answer

Create a separate build pipeline for each environment to ensure environment-specific configurations.

Answer

Use a single build pipeline but trigger a new build for each environment.

Question 9

Your organization uses Azure DevOps for a multi-tier web application. The application consists of a React frontend, a Node.js API, and a SQL database. The security team has mandated the following: (1) All code changes must be scanned for secrets before merging to the main branch. (2) Infrastructure-as-code templates (ARM) must be validated for security compliance before deployment. (3) Production deployments must use a service connection with a managed identity that has only the required permissions. You have set up a CI/CD pipeline with two stages: Build and Release. The Build stage runs on pull requests and the Release stage deploys to a production environment. Recently, a developer accidentally committed a secret (API key) to a configuration file. The secret was not caught by the pipeline, and the code was merged to main. You need to prevent this in the future. What should you do?

Accepted Answer

Add a 'Credential Scanner' task to the Build pipeline and configure it to fail the build if any secrets are found. Also, move all secrets to Azure Key Vault and reference them via variable groups.. It directly addresses the root cause: secrets were not being scanned before merge. The Credential Scanner task (part of Microsoft Security Code Analysis) scans for hardcoded secrets and can fail the build, preventing the merge. Moving secrets to Azure Key Vault and referencing them via variable groups (linked to the vault) ensures secrets are never stored in the repository, eliminating the risk of accidental commits.

Answer

Configure a branch policy to require at least two reviewers on pull requests to the main branch.

Answer

Implement a manual approval gate on the Release stage to review each deployment for secrets.

Answer

Use a pipeline decorator to inject a validation step that runs Azure Policy on the code repository.

Question 10

Refer to the exhibit. The JSON above shows a branch policy configuration for the main branch in Azure Repos. A developer pushes a third commit to an existing pull request after two reviewers have already approved. What happens?

Accepted Answer

The existing approvals remain valid because dismiss_stale_reviews is false.. In Azure Repos, the 'Block on last push' policy (require_last_push_approval) only revokes an approval from the user who made the most recent push, preventing them from approving their own changes. It does not invalidate approvals from other reviewers. The setting that resets all approvals when new commits are pushed is 'Reset code reviewer votes when there are new changes' (dismiss_stale_reviews). Since dismiss_stale_reviews is false in the given configuration, the two existing approvals remain valid when the developer pushes a third commit.

Answer

The pull request is automatically merged because allowed merge types include squash.

Answer

The approvals are dismissed because require_last_push_approval is true.

Answer

The pull request is blocked because the merge type is not allowed.