AZ-400 Practice Test 34 — 15 Questions

Question 1

Your team uses GitHub Actions and needs to enforce that all workflows must use approved actions from a curated list. What is the best way to implement this?

Accepted Answer

Set up an allowed list of actions in organization settings. GitHub Organizations allow administrators to define an 'allowed list' of actions under Settings > Actions > Policies, restricting workflow execution to only approved actions from the curated list. This directly enforces the requirement that all workflows use only approved actions, preventing the use of unverified or malicious third-party actions.

Answer

Configure branch protection rules

Answer

Enable Dependabot alerts

Answer

Use OpenID Connect (OIDC)

Question 2

You are setting up a GitHub Actions workflow to deploy a containerized application to Azure Kubernetes Service (AKS). You need to securely authenticate to the AKS cluster using a service principal. What is the recommended way to store and use the service principal credentials?

Accepted Answer

Store the service principal credentials as GitHub Actions secrets and reference them in the 'azure/login' action. GitHub Actions secrets are the recommended secure mechanism for storing sensitive credentials like a service principal's client ID and secret. The 'azure/login' action can directly reference these secrets (e.g., `${{ secrets.AZURE_CREDENTIALS }}`) to authenticate to Azure, and then the 'azure/aks-set-context' action uses that authenticated session to connect to the AKS cluster. This approach avoids hardcoding credentials in the workflow file and leverages GitHub's encrypted storage.

Answer

Use managed identity for GitHub Actions and assign it to the AKS cluster

Answer

Store the service principal credentials in a Kubernetes secret in the AKS cluster

Answer

Store the service principal credentials as environment variables in the workflow file

Question 3

You need to monitor the health of your Azure Pipeline agents. Which Azure DevOps Analytics view should you use to identify agents that have not reported in the last hour?

Accepted Answer

Agent Health dashboard. The Agent Health dashboard in Azure DevOps provides real-time status of pipeline agents, including their last communication timestamp. By filtering for agents that have not reported in the last hour, you can identify unhealthy or disconnected agents. This dashboard directly surfaces agent connectivity and health metrics. Note that this is a dashboard, not an Analytics view like Release Analytics, Test Analytics, or Pipeline Run Analytics.

Answer

Release Analytics

Answer

Test Analytics

Answer

Pipeline Run Analytics

Question 4

Your organization uses GitHub for source control. You need to implement a secure source control strategy that prevents secrets from being exposed and ensures code quality. Which THREE practices should you implement?

Accepted Answer

Configure branch protection rules requiring status checks to pass. Branch protection rules enforce required status checks (e.g., CI builds, code reviews) before merging, ensuring only validated changes enter protected branches—this supports code quality. GitHub secret scanning automatically detects known types of secrets in repositories and alerts on exposure, directly preventing secret leaks. Pre-commit hooks scan code for secrets before a commit is created, blocking accidental commits of credentials or tokens. Together, A, D, and E address both secret prevention and code quality. Commit signing (C) verifies authorship but does not prevent secret exposure or enforce code quality checks.

Answer

Store secrets in a .env file committed to the repository

Answer

Require commit signing using GPG keys

Question 5

Your Azure Pipeline is configured as shown in the exhibit. A developer pushes a commit to a feature branch named 'feature/new-login' and creates a pull request targeting the main branch. Which pipeline runs will be triggered?

Accepted Answer

Only a PR build. The pipeline is configured with a PR trigger that activates on pull requests targeting the main branch. When a developer pushes a commit to 'feature/new-login' and creates a PR to main, only the PR build is triggered. The CI trigger is not configured for the feature branch (only for main), so no CI build runs on the feature branch itself.

Answer

No pipeline runs

Answer

Only a CI build on the feature branch

Answer

Both a CI build on the feature branch and a PR build

Question 6

Which TWO practices are recommended for managing secrets in Azure Pipelines?

Accepted Answer

Define secret variables in the pipeline UI and mark them as secret. Option A is correct because defining variables in the pipeline UI (Library variable groups or pipeline variables) and marking them as secret encrypts them at rest and masks their values in logs, which is the built-in Azure Pipelines mechanism for handling sensitive values. Option C is correct because Azure Key Vault is the recommended centralized secret store, and Azure Pipelines can link a Key Vault as a variable group so secrets are fetched at runtime and never persisted in the pipeline definition. Option B is not recommended because plain environment variables on the build agent are not encrypted or masked and can leak into logs or be read by other processes. Option D is wrong because there is no 'secret' keyword for variables in YAML; secrets must come from the UI, variable groups, or Key Vault. Option E is wrong because storing secrets as plain text in YAML exposes them in source control and build logs.

Answer

Use environment variables in the build agent

Answer

Set secret variables in the YAML file with the 'secret' keyword

Answer

Store secrets as plain text in YAML variables

Question 7

Your team uses Azure Pipelines to build a Java application. The build must produce a JAR file and publish it as a pipeline artifact. Which THREE steps should be included in the build pipeline?

Accepted Answer

Use a Maven or Gradle task to compile and package the application.. A Maven or Gradle task is the standard way to compile and package a Java application into a JAR file. These tasks invoke the build tool's lifecycle (e.g., `mvn package` or `gradle build`) to produce the artifact, which is a prerequisite for publishing.

Answer

Use the DotNetCoreCLI task to build the application.

Answer

Use the NuGetCommand task to pack the JAR.

Question 8

You need to create a build pipeline that runs on a Microsoft-hosted agent. You want to use the latest Ubuntu image. Which YAML snippet should you use?

Accepted Answer

pool: vmImage: 'ubuntu-latest'. In Azure Pipelines YAML, the `pool` keyword is used to specify the agent pool, and `vmImage` is a sub-property that defines the virtual machine image for Microsoft-hosted agents. Setting `vmImage: 'ubuntu-latest'` within the `pool` section selects the latest Ubuntu LTS image provided by Microsoft, ensuring the build runs on a current, maintained environment.

Answer

pool: name: 'ubuntu-latest'

Answer

agent: vmImage: 'ubuntu-latest'

Answer

resources: vmImage: 'ubuntu-latest'

Question 9

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). You need to implement a strategy that allows rolling back to the previous version quickly if a deployment fails. The pipeline should also support canary deployments. Which tool or feature should you use?

Accepted Answer

Helm package manager with Helm deploy task.. Helm is the correct choice because it provides native support for rollbacks via `helm rollback`, which can revert a release to a previous revision quickly. Additionally, Helm supports canary deployments through its upgrade strategy (e.g., `--set canary.enabled=true`) and integration with tools like Flagger or Argo Rollouts, enabling fine-grained traffic shifting. The Helm deploy task in Azure Pipelines wraps these capabilities, making it the most suitable tool for both rollback and canary requirements.

Answer

Terraform with Kubernetes provider.

Answer

Azure Pipelines Kubernetes manifest task with kubectl apply.

Answer

Kubectl task with rolling update strategy.

Question 10

Your organization is implementing a security compliance plan for Azure DevOps. Which TWO actions help enforce the principle of least privilege?

Accepted Answer

Use Azure DevOps security groups to grant minimal permissions. Option B is correct because Azure DevOps security groups (such as Project Administrators, Contributors, or custom groups) let you assign only the specific permissions each team needs, directly implementing least privilege instead of granting broad access. Option D is correct because restricting agent pool creation to a small admin team limits a powerful, organization- or project-level capability (managing agent pools and their security) to the few users who require it, reducing the attack surface. Option A is wrong because allowing all team members to edit security permissions grants everyone the ability to change ACLs, which violates least privilege. Option C is wrong because using built-in roles without customizing can over-grant permissions, since built-in roles often include more rights than a given user needs. Option E is wrong because Project Collection Administrators is the highest-privilege group in Azure DevOps and should be tightly limited, not assigned to all developers.

Answer

Allow all team members to edit security permissions

Answer

Use built-in roles without customizing

Answer

Grant Project Collection Administrators group to all developers

Question 11

Which TWO are valid strategies for managing secrets in Azure Pipelines?

Accepted Answer

Use a variable group linked to Azure Key Vault and mark variables as secret.. Linking a variable group to Azure Key Vault allows secrets to be securely referenced without exposing them in plaintext; when variables are marked as secret, Azure Pipelines masks their values in logs. Alternatively, the Azure Key Vault task can fetch secrets at runtime and map them to pipeline variables for use in tasks, which also keeps secrets out of YAML and logs. Both approaches are valid strategies for secret management.

Answer

Store secrets in plain text in a variable group.

Answer

Store secrets in a Git repository and read them during build.

Answer

Embed secrets directly in the pipeline YAML file.

Question 12

Which TWO Git operations are considered dangerous and should be used with caution because they rewrite history? (Select TWO.)

Accepted Answer

git push --force. `git push --force` overwrites the remote branch history with the local branch, discarding any commits on the remote that are not in the local history. This can cause other collaborators to lose work if they have based changes on the overwritten commits, making it a history-rewriting operation that must be used with caution.

Answer

git fetch

Answer

git merge

Answer

git revert

Question 13

You are configuring a YAML pipeline in Azure Pipelines. The pipeline must trigger only when changes are pushed to the main branch. Which setting should you configure?

Accepted Answer

Set the trigger to include the main branch.. In Azure Pipelines YAML, the `trigger` section controls which branches cause a CI pipeline to run. By setting `trigger.branches.include` to `main`, only pushes to `main` will trigger the pipeline. All other branches are automatically excluded. There is no separate setting required to disable triggers for other branches; the include list is authoritative.

Answer

Set the PR trigger to include main.

Answer

Set the pipeline to run on every push regardless of branch.

Answer

Use a schedule trigger with cron expression.

Answer

Set the trigger to none for other branches.

Question 14

Refer to the exhibit. This multi-stage YAML pipeline has a variable 'publishEnabled' set to false. The team wants the Publish stage to run only when 'publishEnabled' is true. However, the Publish stage never runs, even when the variable is changed to true at queue time. What is the most likely cause?

Accepted Answer

The variable 'publishEnabled' is not settable at queue time; it is a compile-time variable.. In Azure DevOps YAML pipelines, variables set at the pipeline level (not in a variable group or at queue time) are evaluated at compile time, not at runtime. When 'publishEnabled' is defined as a simple variable in the YAML file, changing it at queue time does not affect the compiled pipeline stages; the condition is evaluated against the compile-time value (false), so the Publish stage never runs. To make it settable at queue time, the variable must be defined as a runtime parameter, or explicitly defined in the pipeline UI with the 'Let users override this value when running this pipeline' checkbox enabled.

Answer

The condition syntax is wrong; it should use 'eq(variables.publishEnabled, true)'.

Answer

The Publish stage is missing 'dependsOn: Build'.

Answer

The 'dependsOn' syntax is incorrect; it should be 'dependsOn: Build'.

Question 15

Which TWO actions help reduce the size of a Git repository over time?

Accepted Answer

Use Git LFS for large binary files.. Option A is correct because Git LFS (Large File Storage) replaces large binary files in the repository with small pointer files while storing the actual content on a separate LFS server, so the Git object database no longer accumulates massive blobs and stays small over time. Option E is correct because 'git filter-branch' or the newer 'git filter-repo' rewrites history to purge obsolete files (e.g., large blobs or secrets) from all commits, and after the rewritten history is pushed and garbage collection runs, those objects are permanently removed, shrinking the repository. Option B is not correct because squashing commits only consolidates commit metadata and does not remove the underlying file blobs, so it has negligible effect on repository size. Option C is not correct because shallow clones ('--depth') only limit history fetched into a local clone; they do not reduce the size of the remote repository itself. Option D is not correct because 'git gc' compresses and packs existing loose objects and prunes unreachable ones, which optimizes storage but does not eliminate reachable large files or obsolete content still referenced in history.

Answer

Squash commits before pushing to the remote.

Answer

Perform shallow clones when cloning the repository.

Answer

Regularly run 'git gc' to compress objects.