AZ-400 Practice Questions

Project 1: Team Foundation Version Control (TFVC) TFVC is a Centralized Version Control System (CVCS) that allows for granular permission control down to the file and folder level. Git, being distributed, generally manages permissions at the repository or branch level. For requirements necessitating restrictions on individual files or folders, TFVC is the required choice in Azure Repos.

Project 2: Git The requirement specifies enforcing rules (reviews, work item association) before merging to the main branch. This describes Branch Policies in Azure Repos, which are a feature exclusive to Git repositories. Branch policies protect branches by requiring code reviews and linking work items before a Pull Request can be completed.

Project 3: Git Xcode has native, built-in support for Git. While it is possible to use TFVC with Xcode through external tools (like the deprecated Git-tf or command line), the requirement to work "directly" implies using the native integration, which is Git.

Project 4: Team Foundation Version Control (TFVC) The requirement states the release branch must "only be viewable" by specific users. In a Distributed Version Control System (DVCS) like Git, users typically have a full copy of the repository history, making "hiding" a branch difficult (even if the server ref is restricted, the commit objects exist locally). In a CVCS like TFVC, permissions are path-based; if a user is denied "Read" access to a branch (which acts as a folder), it is completely invisible to them in the Source Control Explorer.

Microsoft Learn: Configure TFVC permissions

Reference: "TFVC only supports a single repository per project. You can set permissions for the repository or repo folders/branches..."

Link: https://learn.microsoft.com/en-us/azure/devops/organizations/security/set-object-level-permissions?view=azure-devops#tfvc-permissions

Microsoft Learn: Improve code quality with branch policies (Git)

Reference: "Branch policies help teams protect their important branches of development. Policies enforce your team's code quality and change management standards." (Specific mentions of "Require a minimum number of reviewers" and "Check for linked work items").

Link: https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops

Apple Developer Documentation: Configuring your Xcode project to use source control

Reference: "Xcode uses Git commands to manage your source control repository that tracks a history of your project file changes."

Link: https://developer.apple.com/documentation/xcode/configuring-your-xcode-project-to-use-source-control

The most effective solution for planning, managing, and visualizing producer/consumer dependencies across multiple projects in Azure DevOps is to use the Dependency Tracker extension. This tool is specifically designed to create and track dependencies between work items, even when they reside in different projects or organizations. It allows teams to explicitly define "producer" (work being depended on) and "consumer" (work that has the dependency) relationships. Crucially, it provides visualizations like dependency graphs and matrices, which fulfill the requirement for an "overview of all the projects."

B. Add a Parent or Child link to the feature or user story for the items of each project.

Parent/Child links are for creating a hierarchical work breakdown structure (e.g., Epic -> Feature), not for tracking producer/consumer dependencies between peer items across teams.

C. Add a Predecessor or Successor link to the feature or user story for the items of each project.

While these links represent a dependency, they are primarily for sequencing tasks. They lack the specific producer/consumer semantics and the advanced cross-project visualization capabilities needed for a high-level overview.

D. Create a custom query to show the consumers and producers and add a widget to a dashboard.

This is not a complete solution. Standard queries and widgets cannot effectively visualize complex dependency chains across projects without a pre-existing mechanism, like the Dependency Tracker, to first create and define these relationships.

1. Microsoft

Azure DevOps Marketplace

Dependency Tracker: "Dependency Tracker is an Azure DevOps extension that helps you manage dependencies across teams

projects

and even organizations. It allows you to create 'Produces For' / 'Consumes From' links between work items... It also provides different visualizations to track dependencies."

Source: Dependency Tracker - Visual Studio Marketplace (Refer to the "Overview" section).

2. Microsoft Learn

Link user stories

issues

bugs

and other work items in Azure Boards: This document details the purpose of different link types. It describes Parent/Child links for "tree topology" and Predecessor/Successor links for "dependency topology

" confirming they are not primarily for managing cross-team producer/consumer models with a high-level overview.

Source: Link user stories

issues

bugs

and other work items in Azure Boards (Refer to the "Link type reference" section).

3. Microsoft Learn

Plan and manage dependencies across teams: This article discusses strategies for managing dependencies. It explicitly recommends the Dependency Tracker extension for complex scenarios: "For more complex dependency tracking

you can use the Dependency Tracker extension."

Source: Plan and manage dependencies across teams - Azure Boards (Refer to the "Dependency Tracker" section).

To utilize Application Change Analysis in Azure, the Microsoft.ChangeAnalysis resource provider must first be registered within the subscription using Register-AzResourceProvider. This allows the subscription to interact with the Change Analysis service.

For Azure Web Apps, enabling the "web app-level" scan (to capture guest-level changes) requires adding a specific hidden tag: hidden-related:diagnostics/changeAnalysisScanEnabled set to $true. The Set-AzResource cmdlet is the correct tool to update an existing resource's properties or tags in PowerShell. Invoke-AzResourceAction is inappropriate here as it is intended for executing specific POST actions (like starting or stopping a VM) rather than modifying resource metadata.

Microsoft Learn: Register-AzResourceProvider (Azure PowerShell Documentation).

https://learn.microsoft.com/en-us/powershell/module/az.resources/register-azresourceprovider

Microsoft Learn: Set-AzResource (Azure PowerShell Documentation).

https://learn.microsoft.com/en-us/powershell/module/az.resources/set-azresource

Microsoft Learn: Enable Application Change Analysis (Azure Monitor Documentation). Section: "Enable Change Analysis at scale using PowerShell".

https://learn.microsoft.com/en-us/azure/azure-monitor/change/change-analysis-visualize-web-app

Microsoft Learn: Resource providers and resource types (Azure Resource Manager Documentation).

https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/resource-providers-and-types

To monitor VM1's performance based on specific CPU thresholds, Azure Monitor alert rules use two primary time settings: Aggregation Granularity and Frequency.

1. Aggregation Granularity (Period): This defines the time window over which the metric (CPU usage) is evaluated. The requirement states the alert must trigger when usage exceeds 70% for five minutes, thus the period is 5 minutes.
2. Threshold Value: Since the trigger is a specific, fixed number (70%), a Static threshold is required. Dynamic thresholds are used for machine-learning-based anomaly detection.
3. Operator: The requirement is to trigger when usage exceeds 70%, which corresponds to the Greater than operator.

The evaluation frequency (calculating once every minute) is a separate configuration setting in the alert rule UI, distinct from the aggregation period itself.

Microsoft Learn: Create or edit an Azure Monitor metric alert rule. Section: "Condition logic." This explains how "Aggregation granularity" defines the time window for the metric calculation.

Microsoft Learn: Monitor virtual machines with Azure Monitor: Alerts. Section: "Common alert rules." Details the use of static thresholds for standard performance metrics like Percentage CPU.

Microsoft Learn: Advanced features of metric alerts. Explains the difference between Static and Dynamic thresholds, confirming Static is used for fixed limits.

To configure the virtual machines using Azure Automation State Configuration (DSC), the script must adhere to standard DSC resource syntax:

1. WindowsFeature Resource: The Ensure property specifies whether the role or feature is added or removed. To ensure Windows Defender is installed, the value must be set to 'Present'. (The alternative is 'Absent').
2. Service Resource: The State property specifies the desired runtime state of the service. To ensure the Windows Defender service is up and active, the value must be set to 'Running'. (The alternative is 'Stopped').

Microsoft Learn - DSC Service Resource: Confirms that the State property accepts Running or Stopped.

Microsoft Learn - DSC WindowsFeature Resource: Confirms that the Ensure property accepts Present or Absent.

To build an application for iOS, the build pipeline requires the Xcode build tools and SDKs, which are only available on the macOS operating system; therefore, the Hosted macOS pool must be used.

For an IIS web application running in Docker, the application requires the Windows-based IIS web server. This necessitates a Windows Container (as IIS cannot run in Linux containers). The Hosted Windows Container pool (or a Windows agent configured for containers) is required to build and package Windows-based Docker images.

Microsoft Learn - Microsoft-hosted agents: "If you want to build iOS applications... you need to use a macOS agent." "If you want to build Windows containers, you need to use a Windows agent." Source: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml-agnostic#software

Microsoft Learn - Build and push a Windows container: "To build a Windows container, you must use a Windows agent... The windows-2019 [or equivalent Windows] image is recommended." (Note: The exam question uses the legacy pool name "Hosted Windows Container," which corresponds to the Windows containerization capability described in current documentation). Source: https://learn.microsoft.com/en-us/azure/devops/pipelines/ecosystems/containers/build-image?view=azure-devops#build-a-windows-container

Microsoft Learn - Run your application in a Docker container (IIS): "The image mcr.microsoft.com/windows/servercore/iis is a Windows Container image that includes IIS." Source: https://learn.microsoft.com/en-us/virtualization/windowscontainers/quick-start/run-iis-container

The standard workflow for sharing packages in Azure Artifacts follows a specific sequence documented by Microsoft. First, you must create a feed to act as the container for your packages. Second, you generally connect to the feed; this step involves configuring your local development environment (e.g., creating a nuget.config file with the correct feed URL and credentials) to recognize the new feed source. Once configured, you can publish (push) the package to the feed. Finally, to verify the distribution is working as intended, you install the package into a project to test consumption. "Configure a self-hosted agent" is incorrect because Azure Artifacts is a managed service that works with both Microsoft-hosted and self-hosted agents, but a self-hosted agent is not a mandatory step for the basic action of creating and sharing a package.

Microsoft Learn - Azure DevOps: "Get started with NuGet packages in Azure Artifacts"

Relevance: This official guide explicitly lists the workflow steps in this exact order: 1. Create a feed, 2. Connect to feed, 3. Publish a package, 4. Install a package.

Link: https://learn.microsoft.com/en-us/azure/devops/artifacts/get-started-nuget

Microsoft Learn - Azure DevOps: "Publish and download packages in Azure Artifacts"

Relevance: confirms the necessity of configuring (connecting) the tool with the feed URL before publishing or restoring (installing) packages.

Link: https://learn.microsoft.com/en-us/azure/devops/artifacts/nuget/publish

Calendar Versioning (CalVer) uses a format based on the release date, such as YYYY.MM.MICRO. The major, minor, and micro segments are typically numeric and derived from the calendar or a sequence. To denote a pre-release status, such as 'alpha' or 'beta', CalVer uses an optional component called a modifier. This modifier is appended to the core version string to provide additional context about the release's stability or purpose, without altering the chronologically significant parts of the version.

A. micro: This segment is typically a numeric, incrementing value representing a patch, build, or revision within a specific day or month. It is not intended for alphabetic tags.

B. minor: This is a core, calendar-based numeric segment of the version, such as the month (MM) or week (WW). It does not accommodate non-numeric stability tags.

C. major: This is the most significant calendar-based numeric segment, almost always the full year (YYYY) or short year (YY). It is not used for optional tags.

1. CalVer.org

"Calendar Versioning": The official specification for CalVer explicitly defines the use of modifiers. It states

"CalVer versions may also have a modifier for pre-releases

builds and other uses

e.g. v201712.0-alpha.1 or v201712.0-beta". This directly confirms that 'modifier' is the correct term for a 'beta' tag. (Source: https://calver.org/

"About" section).

2. Microsoft Learn

"Package versioning": While often referencing Semantic Versioning (SemVer)

the documentation for Azure Artifacts and package management reinforces the concept of separating core version numbers from pre-release tags. It describes pre-release versions (e.g.

-beta

-rc) as suffixes appended to the main Major.Minor.Patch version

which is analogous to the CalVer modifier. (Source: Microsoft Learn

Document ID: docs.microsoft.com/en-us/azure/devops/artifacts/concepts/package-versioning

Section: "Pre-release versions").

To create a Desired State Configuration (DSC) script, the script block must be defined using the Configuration keyword. This is the top-level container that defines the configuration name (in this case, MyDsc) and holds the node blocks.

Inside the Node block, you must specify the resource required to manage the configuration. The goal is to deploy Internet Information Services (IIS), which corresponds to the Windows Server role named 'Web-Server'. The correct DSC resource to install or manage Windows roles and features is WindowsFeature. The properties shown (Ensure = 'Present' and Name = 'Web-Server') are standard parameters for the WindowsFeature resource.

Microsoft Learn. (2023). Get started with Desired State Configuration (DSC) for Windows. Retrieved from https://learn.microsoft.com/en-us/powershell/dsc/getting-started/wingettingstarted

Relevance: This document outlines the basic syntax of a DSC script, confirming the use of the Configuration keyword to define the block.

Microsoft Learn. (2022). DSC WindowsFeature Resource. Retrieved from https://learn.microsoft.com/en-us/powershell/dsc/reference/resources/windows/windowsfeatureresource

Relevance: This reference documents the WindowsFeature resource, confirming it is used to ensure roles/features (like 'Web-Server') are added or removed, matching the properties Ensure and Name seen in the question.

To optimize a Git repository by removing unreachable history, a two-step process is required. First, the reflog must be cleared. The command git reflog expire --expire-unreachable=now --all removes entries from the reference logs that point to commits no longer reachable from any branch tip.

Second, the actual data objects must be deleted from the disk. The gc (garbage collect) command identifies and removes "orphaned" objects. By using the --prune=now flag, Git is instructed to bypass the default 2-week grace period and immediately delete all unreachable objects, effectively shrinking the repository and removing history not present in any current branch.

Git Official Documentation: git-reflog Manual Page. "expire" section. [Online]. Available: https://git-scm.com/docs/git-reflog

Git Official Documentation: git-gc Manual Page. "--prune=" section. [Online]. Available: https://git-scm.com/docs/git-gc

Chacon, S., & Straub, B. (2014): Pro Git. Chapter 10.7: Git Internals - Maintenance and Data Recovery. Apress.

MIT CSAIL: Version Control (Git). Missing Semester of Your CS Education. [Online]. Available: https://missing.csail.mit.edu/2020/version-control/