AZ-400 Practice Test 20 — 15 Questions

Question 1

Your organization uses GitHub Actions. You need to create a reusable workflow that builds and tests a Node.js application. Which approach should you use to define the workflow?

Accepted Answer

Define a reusable workflow with 'on: workflow_call'. Reusable workflows are defined in a separate file with workflow_call trigger. Option A is wrong because it defines a workflow that cannot be reused. Option B is wrong because actions are different from workflows. Option C is wrong because composite actions are for multiple steps, not entire workflows.

Answer

Define a standard workflow in .github/workflows/build.yml

Answer

Use a composite action to encapsulate the build steps

Answer

Create a custom action and reference it in multiple workflows

Question 2

Your team uses Azure Pipelines to deploy to production. You need to ensure that deployment only proceeds if a security scan passes and a manual approval is obtained. What is the best approach?

Accepted Answer

Use release gates in release pipelines. Release gates in Azure Pipelines allow you to define automated checks (like security scans) and manual approvals before a deployment proceeds. Option A is incorrect because pipeline variables are used to store values, not to enforce deployment conditions. Option B is incorrect because service connections manage authentication to external services, not approval workflows. Option C is incorrect because branch policies apply to pull requests in repositories, not to release pipelines.

Answer

Add pipeline variables

Answer

Set up service connections

Answer

Configure branch policies

Question 3

Your team uses GitHub Flow for feature development. A developer commits directly to the main branch without creating a pull request. Which practice should you enforce to ensure code quality and prevent direct commits?

Accepted Answer

Configure branch protection rules on the main branch to require pull request reviews before merging.. Branch protection rules prevent direct commits to the main branch and require pull requests with reviews. Option A is incorrect because manual sign-off is not enforceable. Option C is incorrect because a .gitignore file does not block commits or enforce branch policies. Option D is incorrect because a CODEOWNERS file alone does not block direct commits.

Answer

Require a manual sign-off from a team lead after each commit.

Answer

Set up a .gitignore file to prevent certain file types from being committed.

Answer

Add a CODEOWNERS file that automatically assigns reviewers to any changes.

Question 4

Refer to the exhibit. You are migrating repository policies from Azure Repos to GitHub. The JSON shows a branch protection rule you plan to apply to the main branch. A developer pushes a hotfix directly to main without a pull request. What happens?

Accepted Answer

The push succeeds because no push restriction is defined.. The branch protection rule includes required status checks and lockBranch (set to false), but it does not require pull requests before merging. In GitHub, direct pushes to a branch are only blocked if 'Require a pull request before merging' is enabled. Since that is not present here, the developer can push directly to main without a pull request, and the push succeeds. Options A and B are incorrect because required status checks and enforceAdmins do not block direct pushes; they only affect pull request merges. Option D is incorrect because lockBranch set to false allows modifications.

Answer

The push is blocked because required status checks are not met.

Answer

The push is blocked because enforceAdmins is true.

Answer

The push is rejected because lockBranch is false.

Question 5

You are designing an instrumentation strategy for a microservices application deployed to Azure Kubernetes Service (AKS) using Azure Pipelines. The application emits custom metrics using OpenTelemetry. You need to ensure that all pipeline-related events (build, release, and test results) are correlated with application telemetry to enable end-to-end traceability. What should you do?

Accepted Answer

Set a unique Correlation ID in the pipeline variables and pass it to the application's OpenTelemetry instrumentation as a span attribute.. Setting a unique Correlation ID in pipeline variables and passing it as a span attribute to OpenTelemetry allows end-to-end traceability by linking pipeline events with application telemetry. Option A is incorrect because Application Insights can ingest pipeline telemetry, but that alone does not correlate with application telemetry; you need a shared correlation ID. Option B is wrong because storing pipeline logs in Log Analytics and querying with metrics does not provide real-time correlation at the span level. Option C is incorrect because deployment gates based on application metrics do not create correlation; they only block deployments based on conditions.

Answer

Configure Application Insights to ingest pipeline telemetry via a custom exporter.

Answer

Store pipeline logs in an Azure Log Analytics workspace and query them together with application metrics.

Answer

Use Azure Pipelines' Checks feature to enforce deployment gates based on application metrics.

Question 6

Match each Azure Repos policy to its enforcement.

Accepted Answer

Require a minimum number of reviewers: At least two reviewers must approve the pull request before it can be completed.. The correct matches are A, B, C, D. Policy A requires at least two reviewers. Policy B requires linked work items. Policy C requires a successful build. Policy D limits merge types. Policies E and F are incorrect because they swap the descriptions: E describes merge types but is labeled as reviewer count, and F describes reviewer count but is labeled as work item linking.

Answer

Require a minimum number of reviewers: Specify which merge strategies are allowed, such as squash merge or rebase.

Answer

Check for linked work items: At least two reviewers must approve the pull request before it can be completed.

Question 7

Which TWO actions should you take to ensure that Azure Pipelines artifacts are scanned for vulnerabilities before production deployment? (Choose two.)

Accepted Answer

Run dependency scanning on the artifact manifest. For ensuring Azure Pipelines artifacts are scanned for vulnerabilities before production deployment, the correct actions are A and C. Option A: Running dependency scanning on the artifact manifest (e.g., package.json, pom.xml) identifies known vulnerabilities in open-source dependencies. Option C: Using Microsoft Defender for Cloud to scan artifacts (such as container images) during the pipeline provides comprehensive vulnerability detection. Option B is incorrect because signing artifacts with a code signing certificate ensures integrity and authenticity, not vulnerability scanning. Option D is incorrect because scanning Infrastructure as Code (IaC) templates addresses configuration security, not artifact vulnerabilities. Option E is incorrect because static code analysis examines source code for coding flaws, not dependencies or artifacts.

Answer

Sign the artifacts with a code signing certificate

Answer

Scan the infrastructure as code templates

Answer

Run static code analysis on the source code

Question 8

Your organization has multiple GitHub repositories that use shared workflows. You want to centrally manage these workflows and ensure they are always up to date. What is the recommended approach?

Accepted Answer

Create a central repository with reusable workflows and reference them using the 'uses' keyword in your workflows.. The recommended approach is to create a central repository with reusable workflows and reference them using the 'uses' keyword. This is a native GitHub Actions feature that allows you to define shared workflow files in one repository and call them from any other repository in your organization. This ensures all workflows stay up to date centrally. The other options are not recommended: B uses API scheduling which is unnecessary and harder to manage; C downloads workflows from blob storage as inline scripts which loses the benefits of shared workflow versioning; D uses Git submodules which are designed for code dependencies and do not integrate well with GitHub Actions workflow execution.

Answer

Use the GitHub API to push workflow files to each repository on a schedule.

Answer

Download the workflows from a central blob storage and include them as inline scripts.

Answer

Store the workflows in a separate repository and use Git submodules to include them.

Question 9

You are designing a build pipeline for a Python application that uses multiple external packages from PyPI. You want to ensure that builds are reproducible and not affected by package updates. Which strategy should you use?

Accepted Answer

Pin exact versions in requirements.txt.. Pinning exact versions in requirements.txt ensures that the same package versions are installed every time, making builds reproducible. Option A is wrong because while Pipfile.lock contains exact resolved versions, the Pipfile itself typically uses version ranges; if the lock file is regenerated (e.g., via 'pipenv lock'), it may resolve to different package versions, breaking reproducibility. Option B is wrong: Dependabot is a tool for automated dependency updates, which introduces version changes and thus breaks reproducibility. Option D is wrong because 'pip install <package>' without version specifiers fetches the latest version, causing non-deterministic builds.

Answer

Use a Pipfile and Pipfile.lock without version pinning.

Answer

Use a dependency update tool like Dependabot weekly.

Answer

Use 'pip install <package>' without version specifiers.

Question 10

Your company uses GitHub and wants to implement a compliance framework that requires signed commits for all repositories. Developers use various IDEs and Git clients. What is the best way to enforce signed commits across the organization?

Accepted Answer

Enable 'Require signed commits' in the branch protection rules for the default branch.. GitHub allows repository administrators to enable 'Require signed commits' in branch protection rules. Option A is incorrect because it is not enforceable; commits can be unsigned. Option B is incorrect because it only encourages, not enforces. Option D is incorrect because it does not enforce signing.

Answer

Set the repository to 'Require pull request reviews before merging' and rely on reviewers to check commit signatures.

Answer

Ask developers to configure GPG keys and sign commits manually.

Answer

Use a GitHub Action that fails if commits are unsigned.

Question 11

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a pipeline that automatically builds and tests a Python application on every pull request to the main branch, but only if the pull request is from a fork. The pipeline must also publish test results as a build artifact. What should you do?

Accepted Answer

Configure a branch protection rule on main that requires status checks from Azure Pipelines. Set the pipeline trigger to 'Pull request validation' and include a condition to run only if the pull request is from a fork.. It configures a branch protection rule on the main branch that requires status checks from Azure Pipelines. By setting the pipeline trigger to 'Pull request validation' and including a condition to run only if the pull request is from a fork, the pipeline automatically builds and tests the Python application on every pull request from a fork to main. The pipeline can also publish test results as a build artifact. Option A is incorrect because GitHub Actions is not Azure Pipelines; the requirement specifies using Azure Pipelines for CI/CD. Option B is incorrect because a scheduled trigger polling for PRs is inefficient and not the proper way to handle PR events. Option C is incorrect because a pipeline completion trigger runs after a merge, not on pull requests.

Answer

Use GitHub Actions to build and test the application on PRs, and then trigger Azure Pipelines for deployment.

Answer

Use a scheduled trigger to run the pipeline every hour and check for new PRs from forks.

Answer

Set up a pipeline completion trigger on the main branch that runs the pipeline after every merge.

Question 12

Your team uses GitHub Enterprise with GitHub Actions. Compliance requires that all contributors sign commits with a verified GPG key. You have enabled 'Require signed commits' on the repository. However, a developer reports that their commits are being rejected even though they have configured a GPG key. The error says 'Commit must have a valid signature.' The developer's GPG key is listed in their GitHub account settings. What is the most likely cause?

Accepted Answer

The developer's local Git email does not match the email associated with the GPG key in GitHub.. The most likely cause is that the developer's local Git email does not match the email associated with their GPG key in GitHub. When GitHub checks a signed commit, it verifies that the committer email matches one of the emails in the GPG key's UID. If they differ, the signature is considered unverified, even if the key is uploaded. Option A is incorrect because an expired key would produce a different error. Option B is incorrect because the developer already has the key uploaded. Option D is incorrect because GitHub supports GPG, not just S/MIME.

Answer

The developer's GPG key has expired.

Answer

The developer's GPG key is not uploaded to GitHub.

Answer

GitHub only supports S/MIME, not GPG.

Question 13

Your team uses GitHub Actions for CI/CD. You need to collect and analyze build and deployment logs centrally to identify recurring failures. Which service should you use to ingest and query these logs?

Accepted Answer

Azure Log Analytics. Azure Log Analytics is the correct service for centralizing and querying logs from GitHub Actions. It can ingest logs via connectors or API, enabling analysis of build and deployment logs to identify recurring failures. Azure Monitor Alerts (A) is for setting up alerts, not for storing or querying logs. GitHub Insights (C) provides reporting and analytics for GitHub repositories but is not designed for custom log querying from CI/CD pipelines. Application Insights (D) focuses on application performance monitoring and telemetry, not CI/CD pipeline logs.

Answer

Azure Monitor Alerts

Answer

GitHub Insights

Answer

Application Insights

Question 14

Refer to the exhibit. A build pipeline fails at the 'Publish Artifact' step. The pipeline has two jobs: 'Build' and 'Test'. Both jobs have a 'PublishBuildArtifacts' task with artifact name 'drop'. What is the most likely cause?

Accepted Answer

Two jobs are publishing artifacts with the same name.. Artifact names must be unique within a build. Both jobs publish with the same name 'drop', causing a conflict.

Answer

The artifact name 'drop' contains invalid characters.

Answer

The artifact is too large to publish.

Answer

The pipeline does not have permission to publish artifacts.

Question 15

You are designing a Git branching strategy for a large enterprise with multiple Azure DevOps projects. The strategy must support hotfixes for production releases, feature development in isolated branches, and release branches for stabilization. The team uses CI/CD pipelines that trigger on branch creation. You need to minimize merge conflicts and ensure that hotfix changes are propagated to all active branches. Which branching model should you recommend and how should you configure branch policies?

Accepted Answer

Use GitFlow with main, develop, and hotfix branches. Configure branch policies on main and develop to enforce pull requests with required reviewers. Use a pipeline to automatically merge hotfix branches into both main and develop.. (GitFlow) is the correct recommendation because it provides dedicated hotfix branches that can be merged into both main and develop, ensuring hotfix changes are propagated to all active branches. GitFlow also supports feature branches, release branches for stabilization, and minimizes merge conflicts by isolating work. Branch policies on main and develop enforce pull requests with required reviewers, and a pipeline can automate merging hotfixes into both branches. Option A (GitHub Flow) lacks dedicated hotfix branches and release branches, making hotfix propagation difficult. Option B (trunk-based) relies on feature toggles and does not isolate hotfixes, increasing risk. Option C (forking) is designed for external contributions, not internal enterprise collaboration, and does not inherently handle hotfix propagation.

Answer

Use GitHub Flow with feature branches merging directly to main. Use a release branch for stabilization. Use pull requests for all merges.

Answer

Use trunk-based development with short-lived feature branches. Use feature toggles for incomplete work. No separate hotfix branch.

Answer

Use a forking workflow where each developer forks the repository and submits pull requests. Use branch policies on the upstream main branch.