AZ-400 Practice Test 33 — 15 Questions

Question 1

Your team uses GitHub and wants to automatically detect and block secrets pushed to repositories. Which GitHub feature should you enable?

Accepted Answer

Push protection. Push protection is the GitHub feature that automatically detects known types of secrets in pushed content and blocks the push, preventing exposure. Secret scanning, on the other hand, scans for secrets and alerts after they exist in the repository but does not block the push unless push protection is enabled. Since the requirement is to 'automatically detect and block secrets pushed', the feature to enable is Push protection.

Answer

Dependabot alerts

Answer

Code scanning

Answer

Secret scanning

Question 2

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 provides a 'Secure files' library feature specifically designed to store files (like Helm values files, certificates, or keystores) that need to be downloaded securely during a pipeline run. The DownloadSecureFile task retrieves the file at runtime, and it can then be passed to the HelmDeploy task, keeping environment-specific configuration out of source control.

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 3

A multinational company uses Azure DevOps with a single project. The project has multiple teams in different time zones. They want to customize the process to reflect different working days for each team. What is the recommended approach?

Accepted Answer

Use the same process and configure working days in the team settings for each team.. Azure DevOps allows each team to have its own working days configured in team settings, independent of the process template. This enables teams in different time zones to define their own non-working days without modifying the shared process, which would affect all teams using that process.

Answer

Create a custom process for each time zone and assign teams accordingly.

Answer

Use the same process but create separate areas for each team, then configure working days per area path.

Answer

Use the same process and configure capacity planning for each team to account for time off.

Question 4

Your team uses a monorepo in Azure Repos. Developers frequently commit directly to the main branch, causing build failures. You need to enforce a policy that requires all changes to go through pull requests with at least one reviewer. What should you configure?

Accepted Answer

Configure a branch policy on the main branch to require a minimum number of reviewers.. Azure Repos allows you to configure branch policies on specific branches (like main) to enforce that all changes must come through pull requests and require a minimum number of reviewers. This directly addresses the need to prevent direct commits to main and ensure code review before merging.

Answer

Configure a repository policy to require a pull request for all branches.

Answer

Create a service hook to reject commits to main that are not from pull requests.

Answer

Enable the 'Require a minimum number of reviewers' setting in the project settings.

Question 5

Which THREE of the following are valid considerations when designing a release pipeline to deploy to multiple environments (dev, test, prod) using Azure Pipelines YAML?

Accepted Answer

Use variable groups scoped to environments to override variables per stage.. Variable groups can be reused across pipelines and stages. In a multi-stage YAML pipeline, you can use different variable groups for each environment by referencing them in the `variables` section of each stage (e.g., a variable group for dev, test, and prod). This allows you to override values such as connection strings per environment without duplicating pipeline code. For production deployments, you should configure approvals and checks on the Azure Pipelines environment resource (e.g., 'prod') to require manual sign-off before the deployment job runs. Stage-level approvals do not exist in Azure Pipelines; approvals are always attached to an environment or a service connection. For branch-based filtering, you can use stage `condition` expressions, such as `and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`, to control which stages run based on the source branch. To reduce duplication, use YAML templates with parameters to define a single deployment template that is reused across environments rather than creating separate templates per environment.

Answer

Use stage-level approvals to gate each stage.

Answer

Use YAML templates to define each environment's deployment steps.

Question 6

Which TWO approaches can you use to enforce consistent commit message formatting across your organization? (Choose two.)

Accepted Answer

Use a pre-receive hook in GitHub to validate commit messages. GitHub's pre-receive hooks are server-side scripts that execute on the repository before accepting a push, allowing you to enforce commit message format validation across all contributors. Similarly, Azure Repos branch policies can include a commit message pattern check, which validates commit messages against a regex and rejects pushes with non-conforming messages. Both approaches enforce the standard on the server side, regardless of local client configurations.

Answer

Use a GitHub workflow that checks PR titles

Answer

Provide a commit message template to developers

Answer

Use Git hooks only on client side

Question 7

Your team uses a monorepo in Azure Repos with multiple microservices. Developers frequently report merge conflicts due to long-lived feature branches. Which branching strategy minimizes merge conflicts while supporting continuous integration?

Accepted Answer

Use trunk-based development with short-lived feature branches and frequent merges to main. Trunk-based development with short-lived feature branches (typically lasting less than a day) minimizes merge conflicts by ensuring that changes are integrated into the main branch frequently, often multiple times per day. This approach reduces the divergence between branches, making conflicts less likely and easier to resolve. It also supports continuous integration by triggering automated builds and tests on every merge to main, aligning with the team's need for rapid feedback and reduced integration overhead.

Answer

Use release branches for all development work and merge to main only at release time

Answer

Use GitFlow with separate develop and main branches, and long-lived feature branches

Answer

Use a forking workflow where each developer works in a personal fork and submits pull requests

Question 8

Your team uses a monorepo in Azure Repos with multiple projects. You want to trigger a pipeline only when changes are made to a specific subfolder. Which configuration should you use?

Accepted Answer

Add a 'paths' filter to the CI trigger.. Azure Pipelines CI triggers support a 'paths' filter that allows you to specify include or exclude patterns for file changes. When a monorepo contains multiple projects in separate subfolders, adding a 'paths' filter to the CI trigger ensures the pipeline only runs when changes are detected within that specific subfolder, avoiding unnecessary builds for unrelated projects.

Answer

Use a branch filter in the CI trigger.

Answer

Configure the checkout step to only include the subfolder.

Answer

Use a 'file_match' condition on the job.

Question 9

Your team uses Azure DevOps and wants to automate the creation of work items when a build pipeline fails. The work item should be assigned to the last person who committed a change in the failed build. Which approach should you use?

Accepted Answer

Add the 'Create work item on failure' task to the build pipeline.. The 'Create work item on failure' task in Azure DevOps build pipelines automatically creates a bug work item and assigns it to the last committer of the failed build. Option A is incorrect because release pipelines are meant for deployment, not build-time tasks. Option C is incorrect because while Service Hooks can trigger on build failure, they require additional custom logic to assign the work item to the last committer, making it less straightforward. Option D is incorrect because using a PowerShell script to call the REST API is more complex and error-prone compared to the built-in task.

Answer

Create a release pipeline that triggers on build failure and creates a work item.

Answer

Configure a Service Hook to create a work item on build failure.

Answer

Use a PowerShell script in the pipeline to call Azure DevOps REST API.

Question 10

You are building a comprehensive instrumentation strategy for a large-scale Azure DevOps environment. You need to ensure that all pipeline events (build, release, test) are automatically tracked and correlated with application performance data. Which THREE components should you include?

Accepted Answer

A shared Correlation ID that flows from pipeline to application.. Options A, C, and E are correct. A shared Correlation ID (A) flows from pipeline to application, enabling end-to-end trace correlation. Custom pipeline tasks (C) send telemetry (e.g., build/release events) to Application Insights. The OpenTelemetry SDK (E) emits trace context from the application, which can include the correlation ID. Option B is wrong because Azure Monitor Workbooks are visualization tools, not data collection components. Option D is wrong because Azure Boards is for work item tracking, not pipeline event capture.

Answer

Azure Monitor Workbooks to visualize pipeline data.

Answer

Azure Boards to track pipeline run metadata.

Question 11

Your organization uses Azure Pipelines with multiple release stages. You need to instrument the pipeline to capture the duration of each stage and the number of failed tasks. Which TWO approaches should you use?

Accepted Answer

Use the Azure DevOps REST API to retrieve pipeline run statistics after each run.. Options D and E are correct. The goal is to capture stage duration and failed task counts. Option D uses the Azure DevOps REST API to programmatically retrieve pipeline run statistics, which includes stage-level durations and failure information. Option E adds a script task at the end of each stage that logs the stage's duration and task results to a custom log file, providing direct instrumentation. Option A is incorrect because pipeline notifications only alert on failures, they don't capture or log durations. Option B is incorrect because 'runOnce' is a deployment strategy that ensures sequential stages, not an instrumentation method. Option C is incorrect because the 'Summary' tab in the pipeline run provides a high-level overview, not detailed per-stage duration data that can be programmatically captured.

Answer

Configure pipeline notifications for failed tasks.

Answer

Implement a 'runOnce' deployment strategy to ensure sequential stages.

Answer

Enable the 'Summary' tab in the pipeline run to view stage durations.

Question 12

Your team is adopting Infrastructure as Code (IaC) using Bicep. You need to validate the Bicep file syntax and run pre-deployment checks as part of the build pipeline. Which task should you use?

Accepted Answer

Azure CLI task with 'az bicep build'. The `az bicep build` command compiles a Bicep file into an ARM template and performs syntax validation, making it the correct choice for validating Bicep syntax and running pre-deployment checks in a build pipeline. This task ensures that the Bicep code is syntactically correct before any deployment attempt, aligning with Infrastructure as Code (IaC) best practices.

Answer

Azure Resource Group Deployment task

Answer

Terraform task

Answer

PowerShell task with Invoke-RestMethod

Question 13

Your team uses Git with a trunk-based development strategy. They want to ensure that all code changes are integrated into the main branch at least once a day, and that branch lifetimes are short. Which practice best supports this?

Accepted Answer

Developers work on short-lived feature branches (less than a day) and merge to main via pull requests after successful CI.. Trunk-based development emphasizes short-lived feature branches (typically less than a day) that are merged into the main branch via pull requests after passing continuous integration (CI) checks. This ensures all code changes are integrated at least daily, keeping branch lifetimes short and reducing merge conflicts.

Answer

Developers use GitFlow with develop and feature branches, merging to develop daily and to main at release.

Answer

Developers commit directly to a release branch, and then the release branch is merged to main at the end of the sprint.

Answer

Developers work on long-lived feature branches and merge to main only after all features are complete.

Question 14

Which TWO practices should you follow to ensure compliance with regulatory requirements (e.g., PCI DSS) when using Azure DevOps? (Choose two.)

Accepted Answer

Enable Azure DevOps audit logging to track changes to pipelines and policies.. Option C is correct because enabling Azure DevOps audit logging captures a tamper-evident trail of events such as pipeline modifications, policy changes, permission updates, and user access, which is essential for demonstrating compliance with regulatory frameworks like PCI DSS that require monitoring and traceability of changes to systems handling cardholder data. Option E is correct because branch policies enforce mandatory code reviews, minimum approver counts, and build validation before changes merge, providing the segregation of duties and change-control evidence that PCI DSS requires for modifications to production pipelines and code. Option A is not appropriate because manually tracking pipeline changes in a spreadsheet is error-prone, unauditable, and lacks the integrity and automation of native Azure DevOps audit logs. Option B is incorrect because unrestricted pipeline creation and modification violates the principle of least privilege and PCI DSS change-control requirements. Option D is incorrect because disabling audit logging removes the very evidence needed for compliance and directly contradicts regulatory monitoring obligations.

Answer

Manually track changes to pipelines in a spreadsheet.

Answer

Allow all users to create and modify pipelines without restrictions.

Answer

Disable audit logging to reduce storage costs.

Question 15

Your team uses Azure Pipelines with Microsoft-hosted agents. You need to ensure that sensitive variables like API keys are securely passed to build tasks, but not exposed in logs. Which approach should you use?

Accepted Answer

Store the API key as a secret variable in the pipeline library or variable group. Secret variables in Azure Pipelines are encrypted at rest and masked in logs, ensuring sensitive values like API keys are never exposed. Storing the API key as a secret in a pipeline library or variable group allows it to be securely referenced by tasks without appearing in output or debug logs.

Answer

Retrieve the API key from Azure Key Vault at runtime using the Azure Key Vault task, but do not mark the output as secret

Answer

Define the API key in a variable template with 'isSecret: false'

Answer

Store the API key as a plain text variable in the pipeline and use it as an environment variable