AZ-400 Practice Test 31 — 15 Questions

Question 1

Which THREE practices are recommended for managing secrets in a Git repository? (Select THREE.)

Accepted Answer

Use tools like GitLeaks to scan for accidentally committed secrets. The recommended practices for managing secrets in a Git repository include using tools like GitLeaks to scan for accidentally committed secrets (Option A), using GitHub Secrets or Azure Pipelines secret variables (Option C), and using Azure Key Vault to store and retrieve secrets at build/release time (Option D). These approaches help avoid storing secrets directly in the repository. Option B is incorrect because storing secrets in an encrypted file committed to the repository still exposes them to anyone who can access the repo and the decryption key. Option E is incorrect because committing a .env file with default values risks including sensitive data and is not a secure practice.

Answer

Store secrets in a separate encrypted file committed to the repository

Answer

Commit a .env file with default values to the repository

Question 2

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets are securely passed to workflows without being exposed in logs. What should you use?

Accepted Answer

GitHub Secrets. GitHub Secrets (Option A) is the correct choice because GitHub Actions provides a built-in secrets management system that encrypts sensitive values at rest and masks them in all workflow logs. When you reference a secret using ${{ secrets.MY_SECRET }}, GitHub automatically redacts the value from any log output, ensuring it is never exposed during execution.

Answer

Environment variables in the workflow YAML

Answer

Hardcode the secrets in the workflow file

Answer

Azure Key Vault with Azure DevOps encrypted variables

Question 3

You are designing a release strategy for a critical application that must maintain high availability. You decide to use Azure Traffic Manager to route traffic between deployments in two Azure regions. Your release pipeline deploys the application to the secondary region first, then switches Traffic Manager priority to route traffic to the secondary region while the primary region is updated. This strategy is known as:

Accepted Answer

Blue-green deployment. This strategy is a blue-green deployment because it uses two complete environments (primary and secondary regions). The new version is deployed to the secondary (green) environment first, then Traffic Manager priority routing switches all traffic from the primary (blue) to the secondary (green). The primary is then updated while idle. This is the classic blue-green pattern applied across regions, not a rolling deployment.

Answer

Canary deployment

Answer

Red/Black deployment

Answer

Rolling deployment across regions

Question 4

Drag and drop the steps to implement infrastructure as code with Azure Resource Manager (ARM) templates into the correct order.

Accepted Answer

Define the ARM template, then parameterize, then store in version control, then validate using what-if, then deploy.. The correct order for implementing infrastructure as code with ARM templates is: first define the ARM template, then parameterize it to make it reusable, then store it in version control (e.g., Git) to track changes, then validate the deployment using the what-if operation to preview changes, and finally deploy the template to Azure.

Answer

Define the ARM template, then parameterize, then deploy, then validate, then store in version control.

Answer

Parameterize, then define the ARM template, then validate, then deploy, then store in version control.

Answer

Define the ARM template, then validate, then parameterize, then deploy, then store in version control.

Question 5

Your team uses GitHub Advanced Security to identify vulnerabilities in code. Which TWO actions can you take to ensure that critical security alerts are addressed before code is merged?

Accepted Answer

Configure branch protection rules to require status checks from code scanning.. Branch protection rules can require passing status checks from code scanning and secret scanning. Pull request annotations show alerts directly in the PR. Dependabot auto-merge and repository rules for bypassing are not relevant for blocking merges based on security alerts.

Answer

Enable secret scanning push protection.

Answer

Create a repository rule that allows bypassing pull request requirements.

Answer

Enable Dependabot auto-merge for pull requests.

Question 6

You are the DevOps lead for a fintech company. The organization uses a multi-tenant Azure DevOps environment with hundreds of pipelines. The compliance team requires that every pipeline run must be auditable with the following attributes captured: who triggered the run, what code changes were included, which artifacts were produced, and whether any secrets (e.g., Azure Key Vault references) were accessed during the run. Additionally, all audit data must be retained for 7 years and be queryable within 5 minutes of a pipeline completion. Current state: pipelines use Azure Key Vault for secrets, and YAML pipelines are defined with variables referencing Key Vault. You need to design an instrumentation strategy to meet these requirements. What should you do?

Accepted Answer

Enable Azure DevOps Audit Streams to send audit events to a Log Analytics workspace. Configure a Log Analytics workspace with 7-year retention. Create a dashboard and alert rules for compliance.. Using Azure DevOps Audit Streams to send events to a Log Analytics workspace provides long-term retention and near real-time querying. Azure DevOps Audit logs capture all required attributes including pipeline runs, secret access, and user identity. Option B is incorrect because Azure Event Grid subscription to pipeline run events does not provide long-term retention and querying capabilities; it is event-driven delivery. Option C is incorrect because adding a step to upload pipeline logs as artifacts does not capture the audit trail of who triggered the run or whether secrets were accessed. Option D is incorrect because instrumenting pipelines with custom tasks sending telemetry to Application Insights is for application telemetry, not pipeline audit, and does not capture all required attributes.

Answer

Use Azure Event Grid to subscribe to pipeline run events and store them in Azure Cosmos DB with TTL for 7 years.

Answer

Add a step at the end of each pipeline to upload pipeline logs as pipeline artifacts with a retention policy of 7 years.

Answer

Instrument each pipeline with custom tasks that send telemetry to Application Insights. Set Application Insights to 7-year retention.

Question 7

Which TWO of the following are true about multi-stage pipelines in Azure Pipelines?

Accepted Answer

Stages can run in parallel if dependencies allow.. Azure Pipelines allows stages to run in parallel when their dependencies are configured appropriately. By default, stages run sequentially, but you can use the 'dependsOn' keyword to define dependencies, and if a stage has no dependencies on another, it can execute concurrently. This enables faster pipeline execution by running independent stages simultaneously.

Answer

Each stage can contain only one job.

Answer

Each stage must run on the same agent.

Answer

Stages cannot have conditions.

Question 8

Match each Azure DevOps service to its primary function.

Accepted Answer

Azure Boards: Agile project management and work tracking. The correct matches are: Azure Boards for agile planning, Azure Repos for version control, Azure Pipelines for CI/CD, and Azure Artifacts for package management. Common confusions include swapping Boards with Repos or Pipelines.

Answer

Azure Boards: Source code version control

Answer

Azure Pipelines: Agile project management

Question 9

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets used in workflows are automatically rotated every 90 days. What is the best approach?

Accepted Answer

Use a script that calls the GitHub API to update the secret and run it in a scheduled workflow.. It uses the GitHub API within a scheduled workflow to programmatically rotate secrets, ensuring automation without manual intervention. This approach directly addresses the requirement for automatic rotation every 90 days by generating new secret values and updating the repository or organization secrets via the API.

Answer

Use OpenID Connect (OIDC) to authenticate.

Answer

Manually update the secrets every 90 days.

Answer

Store secrets as environment secrets and configure expiration.

Question 10

You are using GitHub Advanced Security. The security team wants to prevent developers from introducing code with high-severity vulnerabilities. What is the best way to enforce this?

Accepted Answer

Enable code scanning and configure a quality gate to fail PRs with high-severity alerts. Enabling code scanning with a quality gate that fails pull requests (PRs) on high-severity alerts directly prevents vulnerable code from being merged. This enforces security policy at the PR merge point, using GitHub's CodeQL analysis to detect vulnerabilities before they reach the main branch. Dependabot and secret scanning address different risks (outdated dependencies and leaked secrets) and do not block code with high-severity vulnerabilities.

Answer

Enable Dependabot and require pull request reviews for dependency updates

Answer

Enable push protection for all repositories

Answer

Enable secret scanning and block pushes with high-confidence secrets

Question 11

Your company uses Azure DevOps and has a large monorepo with multiple teams. Developers report that Git operations are slow due to the repository size. Which approach should you recommend to improve performance while maintaining a single repository?

Accepted Answer

Enable sparse checkout and shallow fetch. Sparse checkout and shallow fetch are designed to improve Git performance in large monorepos by limiting the working tree to specific directories (sparse checkout) and reducing the history depth (shallow fetch). This keeps the repository intact as a single unit while significantly reducing the amount of data transferred and stored locally, directly addressing the slow Git operations without breaking the monorepo structure.

Answer

Use Git LFS to store all files

Answer

Split the monorepo into multiple smaller repositories

Answer

Add a .gitattributes file with filter directives

Question 12

Your team uses Azure Pipelines to deploy to multiple environments. The compliance team requires that all deployments to the production environment are approved by a security officer. Which feature should you use?

Accepted Answer

Configure approvals and checks on the production environment in Azure Pipelines.. Approvals and checks in Azure Pipelines allow you to require manual approval before a deployment to a specific environment, such as production. By configuring an approval on the production environment, you ensure that a designated security officer must approve the deployment before it proceeds, meeting the compliance team's requirement.

Answer

Create a branch policy that requires approval for pull requests.

Answer

Use a service connection with a managed identity that requires approval.

Answer

Store the production credentials in a variable group with approval required.

Question 13

Your team uses GitHub Actions for CI/CD and needs to ensure that secrets such as Azure service principal credentials are not exposed in logs. What is the best practice to prevent secret exposure?

Accepted Answer

Store secrets as GitHub Actions secrets and reference them in workflows. GitHub Actions secrets are encrypted environment variables that are automatically masked in workflow logs when referenced. By storing Azure service principal credentials as GitHub Actions secrets and using the `${{ secrets.SECRET_NAME }}` syntax in workflows, the actual secret values are never written to logs, preventing exposure. This is the recommended approach for handling sensitive data in GitHub Actions CI/CD pipelines.

Answer

Store secrets in the workflow YAML file

Answer

Use environment protection rules to mask secrets

Answer

Encrypt workflow logs after the run completes

Question 14

Your team manages a large-scale microservices application deployed on Azure Kubernetes Service (AKS). The code is hosted in Azure Repos, and you use Azure Pipelines for CI/CD. You have recently adopted GitHub Copilot for code suggestions. Your compliance team requires that all pipeline runs include a security scan using Microsoft Defender for Cloud. Additionally, all pull requests must have at least two reviewers from separate teams before merging. The current pipeline completes in 45 minutes, and you want to minimize overhead. You need to design a process that enforces these requirements without degrading developer productivity. Which approach should you recommend?

Accepted Answer

Integrate the security scan as a step early in the CI pipeline, and configure branch policies on the main branch to require two reviewers from different teams and a successful CI build including the scan. Document the process and use Copilot to generate commit messages that reference work items.. It integrates the security scan early in the CI pipeline, ensuring it runs on every build without adding a separate pipeline overhead. Branch policies enforce both the required two reviewers from different teams and the successful CI build (including the scan) before merging, which minimizes additional pipeline complexity and maintains developer productivity.

Answer

Configure a branch policy on the main branch that requires a successful build and security scan before merging, and use a single pipeline that includes the scan.

Answer

Create a separate security scan pipeline triggered on pull request creation, and require its successful completion via branch policy. Then set up a separate PR policy requiring two reviewers.

Answer

Add a manual approval gate in the release pipeline that requires the security officer to approve after the scan completes.

Question 15

Your company uses GitHub for source control. The security team requires that all commits to the main branch be signed with an approved GPG key. Additionally, developers must use their corporate email for commits. You need to configure branch protection rules and repository settings to enforce these requirements. Which combination of settings should you use?

Accepted Answer

Enable 'Require signed commits' in branch protection and use a required status check that runs a custom action to verify commit author email.. GitHub branch protection rules can require signed commits, but they only verify that a commit is signed with any GPG key, not that the signer's email matches a corporate domain. To enforce the corporate email requirement, you must add a required status check that runs a custom action (e.g., using `actions-ecosystem/action-check-commit-email`) to verify the commit author email matches the corporate domain. This combination satisfies both the GPG signature and email domain requirements.

Answer

Configure repository to require commit signature verification via SSH keys.

Answer

Enable 'Require signed commits' in branch protection rules and use a pre-receive hook to validate email domain.

Answer

Use a GitHub Actions workflow that checks commit signatures and email and rejects if invalid.