Free AZ-400 flashcards

On an Azure Artifacts feed, which capability keeps builds working during a public registry outage and retains every external version even after upstream unlists it?

Configuring the public registry as an upstream source turns the Azure Artifacts feed into a transparent caching proxy. The first restore of a version pulls it from upstream and saves a copy into the feed; later restores are served from that saved copy. Builds survive an upstream outage and keep resolving versions even after they are unlisted at the source.

Pointing build restores directly at the public NuGet gallery via a service connection protects builds from gallery outages.

Restoring straight from the public gallery keeps the build wholly dependent on gallery uptime and saves no local copy. An outage still breaks the build, and unlisted versions are lost. An Azure Artifacts upstream source is needed to proxy and cache versions locally.

In Azure Repos, how do you automatically create a traceability link from a commit or pull request to its Azure Boards work item without editing the item by hand?

Reference the work item identifier with hash syntax (for example 'Fixes #142') in the commit message or pull request description. Azure Repos parses that reference on save and writes a development link onto the named work item, so requirement-to-source traceability builds itself as developers work.

Adding the work item title as a tag on a pull request lets Azure Boards match the wording and attach the commit to the right story.

Matching on free-text titles is unreliable and is not how Azure Boards forms a development link. A tag creates no link to the work item. The supported mechanism is a hash-prefixed work item identifier in the commit message or pull request description.

Which branching strategy minimises merge conflicts and integration debt for a team integrating many times a day?

Trunk-based development. Everyone commits small changes to a single shared trunk and any branches are short-lived, merged back within hours. Because divergence never accumulates, conflicts stay small and changes integrate continuously, which suits a team running CI on every commit.

A release branch model is the best fit for a team that integrates code many times a day.

No. A release branch model gives each version a dedicated long-lived branch that stabilises independently. That long-lived divergence is the opposite of frequent small integrations, so it suits stabilising a shipping version rather than high-frequency integration. Trunk-based development fits that need.

How can an Azure Resource Manager service connection authenticate to Microsoft Entra without storing any long-lived credential?

Configure the service connection to use workload identity federation. A federated credential in Microsoft Entra trusts tokens issued by Azure DevOps, so at run time the connection presents a short-lived OpenID Connect token and exchanges it for an Azure access token. No client secret or certificate is ever stored, which removes the credential entirely rather than just hiding it.

Storing a service principal client secret in Azure Key Vault and reading it at run time satisfies a no-stored-credential requirement.

Putting the secret in a vault improves storage hygiene but the client secret is still a long-lived credential that can be exported or leaked. A no-stored-credential requirement is met only by removing the credential, for example with workload identity federation, not by relocating it.