AZ-400 Practice Test 42 — 15 Questions

Question 1

Your team wants to implement a policy that requires all pull requests to have at least one approval from a member of the 'Senior Developers' group before merging. Which mechanism should you use?

Accepted Answer

Create a branch policy on the target branch that requires a minimum number of reviewers from the 'Senior Developers' group.. Azure Repos branch policies allow you to enforce required reviewers on pull requests. By creating a branch policy on the target branch that requires a minimum number of reviewers from the 'Senior Developers' group, you ensure that no pull request can be completed without at least one approval from that group. This directly meets the requirement without relying on file-level ownership or external scripts.

Answer

Add a CODEOWNERS file that designates 'Senior Developers' as owners of all files.

Answer

Configure the pull request dashboard to display required reviewers.

Answer

Set up a build validation policy that runs a script to check approvals.

Question 2

Which THREE are common Git branching strategies used by development teams? (Select THREE.)

Accepted Answer

GitFlow. GitFlow is a common branching strategy that uses a main branch (master/main) alongside develop, feature, release, and hotfix branches. It provides a structured model for managing releases, hotfixes, and parallel development, making it suitable for projects with scheduled release cycles.

Answer

Monorepo

Answer

Centralized version control

Question 3

Your team uses GitHub Actions to build and deploy a Node.js application to Azure Functions. You need to implement a CI/CD pipeline that automatically deploys to a staging environment on every push to the main branch, and then promotes to production after a manual approval via GitHub Environments. The pipeline must also run unit tests and linting. You want to use the official Azure actions. What should you do?

Accepted Answer

Create a single GitHub Actions workflow with multiple jobs. Use a job for build and test, then a job for deploy to staging, and a job for deploy to production with an environment that requires approval.. The correct approach is to create a single GitHub Actions workflow with multiple jobs: one for build and test, one for deploy to staging, and one for deploy to production that uses a GitHub Environment with required reviewers. This allows automatic deployment to staging on push to main, and manual approval for production. The official Azure actions (e.g., azure/functions-action) can be used. Option C is the only one that meets all requirements.

Answer

Create two separate workflows: one for CI (build, test, deploy staging) and one for CD (deploy production) that triggers manually.

Answer

Use a single workflow with a step that deploys to staging and then to production, using a condition to require manual approval via GitHub Issues.

Answer

Use Azure Pipelines with a multi-stage YAML pipeline that includes a stage for staging and a stage for production with pre-deployment approvals.

Question 4

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?

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 5

You are setting up a build pipeline for a .NET Core application. The build should run on every pull request to the 'main' branch. Which trigger configuration should you use in the YAML pipeline?

Accepted Answer

pr: branches: include: - main. In Azure Pipelines YAML, the `pr` trigger is used to define pull request validation triggers, separate from the `trigger` keyword which controls CI triggers on branch pushes. By specifying `pr: branches: include: - main`, the pipeline will automatically run on every pull request targeting the `main` branch, which matches the requirement exactly.

Answer

trigger: pr: branches: include: - main

Answer

trigger: branches: include: - main

Answer

pr: autoCancel: false branches: include: - '*'

Question 6

Your team uses Azure Pipelines to deploy a microservices application to Azure Kubernetes Service (AKS). Each microservice has its own pipeline that builds a Docker image and deploys it to a shared AKS cluster. The deployment must support rolling updates with zero downtime. You need to ensure that if a deployment fails (e.g., health check fails), the pipeline automatically rolls back to the previous version. Which deployment strategy should you implement in the pipeline?

Accepted Answer

Use a rolling update strategy with the 'kubectl apply' command, and include a post-deployment step that checks the rollout status. If the rollout fails, run 'kubectl rollout undo' to roll back.. It directly implements the required behavior: using `kubectl apply` for a rolling update (which inherently supports zero-downtime by gradually replacing pods), followed by a post-deployment step that checks the rollout status. If the rollout fails (e.g., due to health check failures), the pipeline runs `kubectl rollout undo` to automatically revert to the previous version, ensuring rollback on failure.

Answer

Use a canary deployment strategy with a pipeline task that gradually shifts traffic to the new version and monitors error rates. If errors exceed a threshold, the task stops the canary.

Answer

Use the 'KubernetesManifest' task with the 'rollout status' option, which automatically rolls back if the rollout status indicates failure.

Answer

Use a blue-green deployment strategy with two separate AKS clusters. Deploy the new version to the green cluster, run health checks, and then update the load balancer to point to green. If health checks fail, keep pointing to blue.

Question 7

Refer to the exhibit. You have this Azure Pipeline YAML. When you run the pipeline, it fails because the resource group name is not correctly resolved. What is the likely cause?

Accepted Answer

The variable 'resourceGroupName' uses $(environment) which cannot reference a parameter.. In Azure DevOps YAML pipelines, the `$()` syntax is used to reference runtime variables, not parameters. Parameters are defined using `parameters:` and are referenced with `${{ parameters.parameterName }}`. Using `$(environment)` attempts to resolve a variable named 'environment', but since 'environment' is defined as a parameter, it is not available as a variable at runtime, causing the resource group name to remain unresolved and the pipeline to fail.

Answer

The script type 'pscore' is not supported on Ubuntu.

Answer

Parameters cannot be used in YAML pipelines; they must be defined in a template.

Answer

The 'trigger: none' prevents the pipeline from running.

Question 8

Your development team uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub repository secrets are not exposed in build logs. What is the best practice?

Accepted Answer

Store secrets in GitHub repository secrets and reference them in workflows using ${{ secrets.SECRET_NAME }}. GitHub automatically masks secrets in logs.. GitHub automatically masks secrets referenced via the ${{ secrets.SECRET_NAME }} syntax in workflow logs. When a secret is used in a workflow, GitHub Actions scans the log output and replaces any occurrence of the secret value with '***', preventing exposure. This built-in mechanism is the recommended best practice as it requires no additional configuration and works across all steps and actions.

Answer

Use a custom action to manually mask secrets in the logs.

Answer

Define secrets as environment variables directly in the workflow YAML.

Answer

After the workflow runs, delete the logs from GitHub.

Question 9

Your organization uses Azure Pipelines and wants to enforce that all builds must pass a security scan before being deployed to production. The security scan is performed by a third-party tool that is not available as a built-in task. You have installed the tool on a self-hosted agent. What is the best way to integrate the security scan into the pipeline?

Accepted Answer

Use a command-line task (e.g., Bash, PowerShell) to execute the security scan tool.. The security scan tool is installed on a self-hosted agent but not available as a built-in task or marketplace extension. Using a command-line task (Bash or PowerShell) allows you to directly invoke the tool's executable from the agent's file system, passing necessary parameters and capturing exit codes to determine success or failure. This approach integrates seamlessly with Azure Pipelines' standard task execution model without requiring custom extensions or external service hooks.

Answer

Add the tool as a capability of the agent pool and use the 'Install Tool' task.

Answer

Add the 'Run Security Scan' task from the Azure DevOps marketplace.

Answer

Create a custom service hook to trigger the scan externally and wait for results.

Question 10

You are designing a release pipeline for a critical production application. The pipeline must ensure that changes are deployed to a staging environment first, and if integration tests pass, they are automatically deployed to production. However, if the tests fail, the deployment to production must be blocked. What is the best approach?

Accepted Answer

Create a multi-stage YAML pipeline with a gate on the production stage that evaluates test results from the staging stage.. A multi-stage YAML pipeline with a gate on the production stage allows you to evaluate the results of integration tests run in the staging stage before proceeding to production. The gate can be configured to check for test pass/fail status from the staging stage, blocking the production deployment if tests fail. This approach provides a clear, automated approval flow within a single pipeline definition, aligning with the requirement for conditional promotion based on test results.

Answer

Create a single stage in the pipeline with conditional tasks to deploy to staging and then to production based on test results.

Answer

Create two separate pipelines: one for staging and one for production. Use a pipeline trigger to run the production pipeline after staging completes.

Answer

Use a classic release pipeline with pre-deployment approvals on the production stage.

Question 11

You have a pipeline that builds a Docker image and pushes it to Azure Container Registry. You need to ensure that only the latest successful build image is tagged as 'latest'. Which tagging strategy should you use?

Accepted Answer

Use a conditional step that runs only when the build succeeds to tag the image as 'latest'. It ensures the 'latest' tag is applied only after a successful build, preventing broken or incomplete images from being tagged as 'latest'. In Azure Pipelines, you can use a condition like `condition: succeeded()` on a script or Docker task that runs `docker tag` and `docker push` to update the 'latest' tag only when the preceding build steps succeed. This maintains a reliable 'latest' pointer to the most recent stable image.

Answer

Use the build ID as the tag and manually update 'latest'

Answer

Use the Git commit hash as the tag and push 'latest' separately

Answer

Always tag the image as 'latest' regardless of build status

Question 12

Your team uses Microsoft Defender for Cloud to monitor Azure resources. You need to ensure that all Azure DevOps pipelines are scanned for security misconfigurations before deployment. Which integration should you enable?

Accepted Answer

Enable the 'Defender for DevOps' integration in Microsoft Defender for Cloud.. Microsoft Defender for Cloud includes a 'Defender for DevOps' integration that allows you to connect Azure DevOps environments and scan pipelines for security misconfigurations, such as Infrastructure as Code (IaC) template issues or exposed secrets, before deployment. This integration provides built-in security posture assessments and actionable recommendations directly within the Defender for Cloud dashboard, enabling shift-left security practices.

Answer

Connect Azure DevOps to Microsoft Sentinel.

Answer

Deploy Microsoft Intune policies to Azure DevOps agents.

Answer

Configure Microsoft Purview to scan Azure DevOps repositories.

Question 13

Your team uses Azure Pipelines and needs to comply with SOC 2 requirements. Which TWO features should you use to meet audit log requirements? (Select TWO.)

Accepted Answer

Enable Azure DevOps audit logging. Azure DevOps audit logging (Option C) captures a detailed, immutable record of events such as pipeline runs, permission changes, and access attempts, which is essential for SOC 2 audit log requirements. Streaming these logs to Azure Monitor Log Analytics (Option E) enables long-term retention, advanced querying, and alerting, satisfying the need for secure log storage and monitoring.

Answer

Configure network security groups to block public access

Answer

Automate secret rotation for service connections

Answer

Create service principals for pipeline authentication

Question 14

Refer to the exhibit. An Azure DevOps administrator has configured the branch policy for the main branch as shown. A developer attempts to push a commit directly to the main branch. What will happen?

Accepted Answer

The push is rejected because branch policies require a pull request. The branch policy for the main branch requires that all changes be submitted via a pull request. When a developer attempts to push a commit directly to main, Azure Repos enforces this policy by rejecting the push. The push is blocked at the server level before any build validation or other checks occur.

Answer

The push triggers the build validation pipeline

Answer

The push is allowed because allowForcePush is false

Answer

The push is allowed because requireLinearHistory is false

Question 15

Which TWO practices help improve the security of container images in a CI/CD pipeline? (Choose two.)

Accepted Answer

Sign container images to verify their integrity.. Option C is correct because signing container images (e.g., with Docker Content Trust/Notary or Sigstore Cosign) creates a cryptographic signature that lets the pipeline and runtime verify image integrity and provenance, preventing tampered or spoofed images from being deployed. Option E is correct because integrating an image vulnerability scanner (such as Trivy, Clair, or Grype) into the build stage detects known CVEs in OS packages and dependencies early, allowing the pipeline to fail or block promotion of vulnerable images. Option A is wrong because running containers as root increases the attack surface and violates least-privilege; non-root users or user namespaces should be used instead. Option B is wrong because public registries expose images to unauthorized pulls and tampering; private, access-controlled registries are preferred. Option D is wrong because the mutable 'latest' tag is non-deterministic and can silently pull unvetted or breaking changes; pinned, immutable tags or digests should be used.

Answer

Run containers with root privileges to avoid permission issues.

Answer

Store container images in a public registry for easy access.

Answer

Use the 'latest' tag for base images to always get the newest patches.