MicrosoftProfessional levelAZ-400Page 2 of 4

AZ-400 exam dumps: questions 101 to 200 of 306

Page 2 of the free AZ-400 question bank for the Designing and Implementing Microsoft DevOps Solutions exam. Questions 101 to 200 are listed below, the first 5 in full with answers and explanations. Back to page 1 for the exam overview and FAQ.

Question bank last updated May 2025

Start timed practice exam Questions 101 to 200

Free AZ-400 practice questions

Questions 101 to 105 of 306

Pick an answer before you open the explanation. Each question also has its own page with a permalink.

AZ-400 Question 101

Single answer

You are configuring Azure Artifacts feeds for an organization that develops multiple .NET services. The team wants to store internal packages in a dedicated feed while also retrieving stable packages directly from NuGet.org. However, they need to ensure no pre-release packages from NuGet.org are exposed to the broader development team. Which approach should you take to achieve this requirement?

A
Create one feed in Azure Artifacts and set NuGet.org as an upstream source. Then configure separate package views (e.g., @Prerelease and @Release) to expose stable packages to most developers while isolating pre-release builds in another view.
B
Create two separate feeds: the first for local packages only, and the second that directly references NuGet.org. Require each developer to switch feeds manually based on whether they want stable or pre-release packages.
C
Enable public package consumption in the local feed without configuring any upstream sources. Use NuGet CLI to clone stable packages from NuGet.org into the local feed whenever required.
D
Use Azure Repos to store internal packages in version control, then configure a single feed in Azure Artifacts pointing only to NuGet.org without any views.

Show answer and explanation

Correct answer: A

Explanation

Using Azure Artifacts with upstream sources allows an organization to consume packages from public and private feeds seamlessly. Configuring separate views such as @Prerelease and @Release is a recommended best practice, as documented by Microsoft (e.g., docs.microsoft.com/azure/devops/artifacts). This approach ensures only stable packages reach production pipelines or the broader development team, while pre-release versions are isolated for testing and experimentation.

A. Correct.
Option 1 is correct. A single feed with upstream sources and views is the recommended approach to manage both internal and upstream packages in Azure Artifacts. By creating multiple views, such as @Release for stable packages and @Prerelease for experimental versions, you can control which packages are visible to different groups. This setup avoids any pre-release packages leaking into the main release view.
B. Incorrect.
Option 2 is incorrect. While two separate feeds can technically work, it complicates the process by forcing developers to toggle between feeds for stable or pre-release versions. It also does not streamline the package lifecycle since these feeds do not share package views, making management more cumbersome.
C. Incorrect.
Option 3 is incorrect. Manually cloning packages from NuGet.org is error-prone and unsustainable. It defeats the purpose of configuring an upstream source for automatic updates and does not provide a reliable way to filter out pre-release packages.
D. Incorrect.
Option 4 is incorrect. Storing packages in Azure Repos is not a best practice for binaries, and failing to configure upstream sources or views means you cannot effectively control which packages (stable vs. pre-release) flow into the feed.

AZ-400 Question 102

Select 2

Your organization manages a private npm feed in Azure Artifacts. You also want to incorporate the public npm registry as an upstream source so developers can access external packages without manually connecting to npmjs.com. However, you need to separate prerelease versions from stable releases and ensure that only stable versions from the public registry are used in production. Which two actions should you take to set up your feed and views correctly?

A
Add the public npm registry as an upstream source, then create a 'PreRelease' and 'Release' view in your Azure Artifacts feed.
B
Configure the feed to only store stable versions from the public registry by filtering out prerelease tagged versions, then associate that upstream with a 'Release' view.
C
Enable 'Inherit feed permissions' in the public view to automatically hide prerelease packages from downstream consumers.
D
Create an additional feed specifically for prerelease packages, disallowing any upstream connections to the public registry.

Show answer and explanation

Correct answers: A, B

Explanation

Azure Artifacts supports adding external package sources (e.g., npmjs.com) as upstreams and using views to segment different package versions or states (such as pre-release vs. release). Following official Microsoft documentation (https://learn.microsoft.com/azure/devops/artifacts/) ensures best practices for configuring multiple views and filtering packages so that only stable versions flow into production, while prerelease packages remain in development or testing environments.

A. Correct.
Correct: By adding the public npm registry as an upstream source, you can seamlessly consume both local and external packages. Creating separate views (e.g., 'PreRelease' and 'Release') allows you to segregate prerelease packages from production-ready versions, matching common best practices in Azure Artifacts.
B. Correct.
Correct: You can filter out prerelease versions when configuring the feed's upstream source, so only stable releases from npmjs.com are cached. Associating the upstream source with a 'Release' view ensures that only stable versions are displayed in that view, keeping development and production packages organized.
C. Incorrect.
Incorrect: 'Inherit feed permissions' does not specifically hide or filter prerelease packages. This option manages permission inheritance, not package filtering. Relying on inherited permissions alone will not achieve the requirement of separating prerelease from stable packages.
D. Incorrect.
Incorrect: Creating an entirely separate feed for prerelease packages without allowing upstream connections to npmjs.com ignores the need to pull external prerelease packages if needed. Additionally, you lose the capability to manage stable and prerelease packages within a single feed structure that uses multiple views.

AZ-400 Question 103

Select 2

Your DevOps team manages several internal libraries that are currently versioned using Semantic Versioning (SemVer). However, you are introducing a new, more frequent release cycle aligned with monthly sprints and plan to move to a date-based versioning (CalVer) scheme. You must also ensure that any backward-incompatible changes are easily identifiable to consumers of these libraries. Which two approaches should you adopt to achieve these goals?

A
Adopt CalVer but discontinue SemVer increments, even when introducing breaking changes.
B
Adopt a hybrid approach: apply date-based tags for monthly releases and maintain SemVer rules for indicating compatibility.
C
Overwrite existing packages in your artifact repository to unify version numbering with the new CalVer approach.
D
Keep both the date-based label and increment the major version if changes break compatibility or require a migration path.

Show answer and explanation

Correct answers: B, D

Explanation

When migrating to a date-based versioning strategy (CalVer), it is best practice to still follow SemVer guidelines for changes that affect compatibility. This ensures that new releases are easily tracked by date, while major version increments clearly indicate when consumers must prepare for potential code changes. Refer to official documentation on Semantic Versioning (semver.org) and Microsoft DevOps best practices to learn more about combining these approaches effectively.

A. Incorrect.
Option 1 is incorrect. Completely abandoning SemVer increments means you lose clear signaling of backward-incompatible changes, which can confuse consumers about when they must adjust their code.
B. Correct.
Option 2 is correct. Many teams use a hybrid strategy: the date-based version conveys the release timestamp, while SemVer rules ensure clarity on whether an update introduces breaking changes or bug fixes.
C. Incorrect.
Option 3 is incorrect. Overwriting existing packages undermines traceability and can break existing builds that rely on previously acquired packages.
D. Correct.
Option 4 is correct. Even when employing CalVer for release cadence, you should still bump the major version to indicate breaking changes, which is essential to maintain compatibility awareness for your consumers.

AZ-400 Question 104

Single answer

Your development team maintains multiple shared libraries used by various internal applications. You release new features at the end of each quarter and sometimes introduce breaking changes that require a major version increment. However, senior leadership wants a straightforward way to identify the release timeframe from the library version itself. Which single versioning approach best meets these needs?

A
Use strict Semantic Versioning (SemVer) for every release cycle without incorporating dates.
B
Adopt standard date-based versioning (CalVer) and ignore the concept of major/minor increments.
C
Combine SemVer for major/minor/patch increments while integrating the date of release within a build metadata or pre-release label.
D
Issue the release date as the patch version number and only use major increments when forced to by policy.

Show answer and explanation

Correct answer: C

Explanation

Microsoft DevOps best practices recommend maintaining clear versioning conventions that highlight breaking changes as well as release cycles. Semantic Versioning (SemVer) helps inform users about incompatibility risks, while date-based (CalVer) markers make it easy to identify when a release occurred. By blending the two�employing SemVer� major/minor/patch increments and adding date information in a pre-release or metadata segment�you balance clarity for both dependency management and release timelines. For reference, see official guidance on Semantic Versioning (https://semver.org/) and versioning strategies in Microsoft Docs (https://learn.microsoft.com/azure/devops/pipelines/library/versioning-strategies).

A. Incorrect.
Option 1: Incorrect. While SemVer is good for communicating breaking changes, it does not incorporate release date information, which is specifically requested by leadership.
B. Incorrect.
Option 2: Incorrect. CalVer simplifies date-based identification but lacks the clarity needed for conveying breaking changes, which is a primary concern when managing shared libraries.
C. Correct.
Option 3: Correct. Combining SemVer with date information (e.g., using a pre-release label such as '1.2.0-2023.10') captures both the semantic meaning (major/minor/patch) and the release timeframe. This meets leadership desires and maintains clarity about breaking changes.
D. Incorrect.
Option 4: Incorrect. Using the release date as a patch version can become confusing (e.g., '1.2.202310'), as it conflates patch increments with date identifiers and fails to cleanly distinguish truly minor fixes from major or minor SemVer changes.

AZ-400 Question 105

Single answer

Your organization has a microservices architecture where each service depends on a common shared library. Historically, the library used Semantic Versioning (SemVer) to communicate backward-incompatible changes. However, your leadership wants to release new modules and enhancements on a time-based schedule every quarter. They are discussing switching entirely to date-based versioning (CalVer) for all code assets. Which strategy best meets both the need to indicate breaking changes and the need for predictable release timelines?

A
Adopt a pure date-based versioning model (CalVer) for every release, replacing SemVer completely to focus on scheduled milestones.
B
Use SemVer for all builds but reset the major version number every quarter to reflect the scheduled release cycle.
C
Continue using SemVer for libraries to clearly indicate breaking changes, while attaching date-based version identifiers at the CI/CD pipeline level or as release metadata.
D
Maintain parallel versioning schemes for every release�one using SemVer for developers to track compatibility and another using CalVer for management oversight.

Show answer and explanation

Correct answer: C

Explanation

In most real-world DevOps scenarios, Semantic Versioning (SemVer) is critical for communicating to consumers of a library when a release contains potentially breaking changes. However, teams often also want to align their release cycles with predictable schedules. The recommended practice is to maintain SemVer for compatibility signaling while using date-based markers (CalVer) at the pipeline or metadata level to align with organizational release plans. Refer to semver.org and official Azure DevOps documentation for more on best practices regarding semantic and date-based versions.

A. Incorrect.
Incorrect: While date-based versioning can simplify scheduling, removing SemVer entirely makes it difficult for developers to quickly identify backward-incompatible changes. Relying only on dates could lead to confusion about compatibility.
B. Incorrect.
Incorrect: Resetting the major version regularly undermines SemVer� core principle of indicating breaking changes. This approach may cause confusion because a new major version might not always introduce incompatibilities.
C. Correct.
Correct: SemVer remains the best option for signaling backward-incompatible changes and forcing clients to acknowledge potential breaking updates. Date-based identifiers can be appended at the pipeline level to meet scheduled release needs without losing the benefits of SemVer.
D. Incorrect.
Incorrect: Having two distinct production-facing version systems on the same artifact can be unnecessarily complex. This might confuse consumers who are unsure which version scheme to track for compatibility and updates.

Timed practice exam

Take a AZ-400 practice test under exam conditions

70 questions in 90 minutes, drawn from this bank, with a score report and a per-question review when you finish.

Start timed exam

AZ-400 practice questions 101 to 200 of 306

Every question has a page with the answer and explanation. Numbers are stable, so you can bookmark or share them. The bank is split into 4 pages of up to 100 questions.

More Microsoft exam dumps

All Microsoft exams

AZ-305243 questions

Azure Solutions Architect exam dumps

Designing Microsoft Azure Infrastructure Solutions

AZ-700310 questions

Azure Network Engineer exam dumps

Designing and Implementing Microsoft Azure Networking Solutions

AI-102492 questions

Azure AI Engineer exam dumps

Designing and Implementing a Microsoft Azure AI Solution

AI-900285 questions

Azure AI Fundamentals exam dumps

Microsoft Azure AI Fundamentals

AZ-500273 questions

Azure Security Engineer exam dumps

Microsoft Azure Security Technologies

AZ-104288 questions

Azure Administrator exam dumps

Microsoft Certified: Azure Administrator Associate