AZ-400 Practice Test 2 — 10 Questions

Question 1

You are designing a source control strategy for a team that uses GitHub Copilot. The team wants to ensure that code suggestions do not include sensitive data. Which approach should you recommend?

Accepted Answer

Configure content exclusions in GitHub Copilot settings to block sensitive data patterns. GitHub Copilot's content exclusions allow you to define patterns (e.g., regex for API keys, tokens, or PII) that Copilot will block from being used as context for code suggestions. This directly prevents sensitive data from appearing in suggestions without disabling the tool entirely. It is the most targeted and least disruptive approach to meet the team's goal.

Answer

Use pre-commit hooks to scan for secrets

Answer

Disable GitHub Copilot for the organization

Answer

Enable secret scanning for the repository

Question 2

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 3

A team uses Azure Boards to manage work items. They want to automatically update the state of a work item when a related pull request is merged in Azure Repos. Which TWO actions should they configure to enable this integration?

Accepted Answer

Add a branch policy that requires a linked work item for pull requests.. A branch policy that requires linked work items for pull requests ensures that every PR is associated with a work item. When the PR is merged, Azure Repos automatically updates the state of the linked work item (e.g., from 'Active' to 'Resolved') based on the default or configured transition rules. This integration is built into Azure DevOps without requiring external services.

Answer

Set up a webhook in Azure Repos to call Azure Logic Apps on pull request merge.

Answer

Configure a Service Hooks subscription in Azure DevOps to send pull request merge events to Azure Boards.

Answer

Create an Azure Function that listens for pull request merge events and updates work items via the REST API.

Question 4

Refer to the exhibit. You have configured a Conditional Access policy in Microsoft Entra ID to require MFA for Azure DevOps. However, users report that they can still access Azure DevOps without MFA when using a PAT for authentication. What is the most likely reason?

Accepted Answer

PATs are not subject to Conditional Access policies because they use legacy authentication.. B is correct because Personal Access Tokens (PATs) in Azure DevOps are considered legacy authentication tokens. Conditional Access policies in Microsoft Entra ID do not evaluate requests made using legacy authentication protocols, including PATs, OAuth device code flow, or IMAP/POP. Therefore, even if a Conditional Access policy requires MFA for Azure DevOps, users authenticating with a PAT bypass the policy entirely.

Answer

The policy should include 'Require device to be marked as compliant'.

Answer

The policy should be scoped to 'All cloud apps' instead of just Azure DevOps.

Answer

The Conditional Access policy is not enabled.

Question 5

You need to enforce that all builds in Azure Pipelines use a specific version of the .NET SDK. What is the best approach?

Accepted Answer

Add a UseDotNet task to the pipeline that specifies the required SDK version.. The UseDotNet task in Azure Pipelines can be configured to download and install a specific version of the .NET SDK, ensuring that all builds use exactly that version, regardless of what is pre-installed on the agent. Option B is incorrect because setting a pipeline variable DotNetVersion and using it in the DotNetCoreCLI task does not enforce the SDK version; the DotNetCoreCLI task uses the SDK already available on the agent, unless explicitly redirected, and the variable alone does not install or enforce a specific SDK. Option C is incorrect because installing the SDK manually via a script is not a reliable or repeatable approach; it depends on the agent's state and does not automatically enforce the version across different agents or pipeline runs. Option D is incorrect because including a global.json file in the repository does not guarantee that the required SDK version is installed on the agent; the build agent may not respect global.json if the specified SDK is not present, and there is no enforcement mechanism without additional steps.

Answer

Set a pipeline variable DotNetVersion and use it in the DotNetCoreCLI task.

Answer

Install the SDK manually on the build agent using a script.

Answer

Include a global.json file in the repository and rely on the build agent to respect it.

Question 6

A team uses Terraform to manage Azure infrastructure. They want to store the Terraform state file securely and enable collaboration. What is the recommended approach?

Accepted Answer

Store the state file in an Azure Storage account with state locking enabled. Storing the Terraform state file in an Azure Storage account with state locking enabled is the recommended approach because it provides a centralized, durable backend that supports native state locking via Azure Blob Storage leases. This prevents concurrent modifications and state corruption, enabling safe collaboration among team members. Azure Storage also offers encryption at rest and access control via RBAC, aligning with security best practices for infrastructure-as-code.

Answer

Store the state file in a local folder and commit to Git

Answer

Store the state file in Terraform Cloud

Answer

Store the state file in a Git repository with manual locking

Question 7

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 8

Your team uses GitHub with a monorepo containing frontend and backend code. You need to implement a strategy where changes to the frontend folder trigger a frontend CI pipeline, changes to the backend folder trigger a backend CI pipeline, and changes to both trigger both. You also want to ensure that pull requests include changes only to one area to reduce complexity. What should you do?

Accepted Answer

Configure separate CI pipelines with path filters so that each pipeline triggers only on changes to its respective folder.. GitHub Actions and Azure Pipelines support path filters (e.g., `paths` in YAML triggers) that allow you to define separate CI pipelines for frontend and backend folders. When a pull request includes changes to both folders, both pipelines automatically trigger, satisfying the requirement. This approach ensures that each pipeline runs only when its relevant code changes, reducing unnecessary builds and complexity.

Answer

Use CODEOWNERS to assign different reviewers for frontend and backend, and rely on manual pipeline triggers.

Answer

Create branch policies that require specific builds based on the branch name.

Answer

Use a single pipeline that runs all tests on every change.

Question 9

Your organization uses GitHub Actions for CI/CD. You have a workflow that deploys to Azure App Service. The deployment uses a publish profile secret stored as a GitHub secret. You want to improve security by using OpenID Connect (OIDC) to authenticate to Azure without storing secrets. What should you do?

Accepted Answer

Configure the GitHub workflow to use the 'azure/login' action with OIDC, and set up a federated identity credential in Microsoft Entra ID for the GitHub environment.. Configuring OIDC with Microsoft Entra ID (formerly Azure AD) using a federated identity credential for the GitHub environment allows token-based authentication without storing secrets. Option A is incorrect because Azure Managed Identity cannot be used directly from a GitHub runner; Managed Identity is designed for Azure-hosted resources, not external runners. Option C is incorrect because replacing the publish profile secret with a service principal secret still requires storing a secret, which does not improve security compared to OIDC. Option D is incorrect because setting the 'Publish Profile' parameter to an empty string does not enable OIDC authentication; the deployment would fail due to missing credentials.

Answer

Remove the secret and use Azure AD Managed Identity directly from the GitHub runner.

Answer

Replace the publish profile secret with an Azure service principal secret stored as a GitHub secret.

Answer

Use the 'Azure App Service Deploy' task with the 'Publish Profile' parameter set to an empty string.

Question 10

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub repository secrets are not exposed in build logs. Which security practice should you implement?

Accepted Answer

Use GitHub Actions secrets and ensure they are marked as masked. GitHub Actions automatically masks secret values in build logs when referenced via the secrets context, such as ${{ secrets.SECRET_NAME }}. Option B is wrong because storing secrets in a repository YAML file exposes them to anyone with repo access. Option C is wrong not because environment variables are unsecurely logged, but because it is not the recommended practice; secrets should be referenced directly through the secrets context to avoid risk of unintended exposure (e.g., if the value is modified or used outside GitHub's masking). Option D, while a valid security practice, does not directly address preventing log exposure unless the fetched secrets are also masked.

Answer

Store secrets in a YAML file within the repository

Answer

Pass secrets as environment variables in the workflow

Answer

Use a third-party secret management service and fetch secrets at runtime