AZ-400: Designing and Implementing Microsoft DevOps solutions
You are configuring project metrics for dashboards in Azure DevOps.
You need to configure a chart widget that measures the elapsed time to complete work items once they become active.
Which of the following is the widget you should use?
Cumulative Flow Diagram
Burnup
Cycle time
Burndown
Answer is Cycle time
Cycle time measures the time it takes for your team to complete work items once they begin actively working on them.
Cycle time, on the other hand, specifically measures the elapsed time from when a work item becomes active to when it is completed, making it the best option to fulfill the requirement in the question.
A. Cumulative Flow Diagram shows the number of work items in different states over time and can be used to monitor progress and identify bottlenecks, but it doesn't specifically measure elapsed time.
B. Burnup charts show the progress of completed work items over time and can be used to measure progress towards a goal, but it doesn't measure elapsed time once work items become active.
D. Burndown charts show the remaining work over time and can be used to measure progress towards completing a set of work items, but it doesn't measure elapsed time once work items become active.
Reference:
https://docs.microsoft.com/en-us/azure/devops/report/dashboards/cycle-time-and-lead-time?view=vsts
You need to consider the underlined segment to establish whether it is accurate.
The Burnup widget measures the elapsed time from creation of work items to their completion.
Select `No adjustment required` if the underlined segment is accurate. If the underlined segment is inaccurate, select the accurate option.
No adjustment required.
Lead time
Test results trend
Burndown
Answer is Lead time
Lead time measures the total time elapsed from the creation of work items to their completion.
Reference:
https://docs.microsoft.com/en-us/azure/devops/report/dashboards/cycle-time-and-lead-time?view=vsts
Your company is currently making use of Team Foundation Server 2013 (TFS 2013), but intend to migrate to Azure DevOps.
You have been tasked with supplying a migration approach that allows for the preservation of Team Foundation Version Control changesets dates, as well as the changes dates of work items revisions. The approach should also allow for the migration of all TFS artifacts, while keeping migration effort to a minimum.
You have suggested upgrading TFS to the most recent RTW release.
Which of the following should also be suggested?
Installing the TFS kava SDK
Using the TFS Database Import Service to perform the upgrade.
Upgrading PowerShell Core to the latest version.
Using the TFS Integration Platform to perform the upgrade.
Answer is Using the TFS Database Import Service to perform the upgrade.
With the release of Azure DevOps Server 2019, the TFS Database Import Service has been rebranded as the data migration tool for Azure DevOps. This change includes TfsMigrator (Migrator) becoming the data migration tool. This service works exactly the same as the former import service. If you're running an older version of on-premises Azure DevOps Server with the TFS branding, you can still use this feature to migrate to Azure DevOps as long as you've upgraded to one of the supported server versions.
Reference:
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/azure-best-practices/contoso-migration-tfs-vsts
You are making use of Azure DevOps manage build pipelines, and also deploy pipelines.
The development team is quite large, and is regularly added to.
You have been informed that the management of users and licenses must be automated when it can be.
Which of the following is a task that can't be automated?
Group membership changes
License assignment
Assigning entitlements
License procurement
Answer is License procurement
Group membership changes, license assignment, and assigning entitlements can all be automated using tools such as Azure DevOps and Azure Active Directory. However, license procurement involves purchasing licenses from a vendor, which typically requires manual intervention.
You have an on-premises Bitbucket Server with a firewall configured to block inbound Internet traffic. The server is used for Git-based source control.
You intend to manage the build and release processes using Azure DevOps. This plan requires you to integrate Azure DevOps and Bitbucket.
Which of the following will allow for this integration? (You can select more than one)
A self-hosted agent
A Microsoft-hosted agent
An External Git service connection
Service Hooks
Answers are;
A self-hosted agent
An External Git service connection
You can integrate your on-premises Bitbucket server or another Git server with Azure Pipelines. Your on-premises server may be exposed to the Internet or it may not be.
If your on-premises server is reachable from the servers that run Azure Pipelines service, then:
you can set up classic build and configure CI triggers.
If your on-premises server is not reachable from the servers that run Azure Pipelines service, then:
you can set up classic build pipelines and start manual builds
you cannot configure CI triggers
If your on-premises server is reachable from the hosted agents, then you can use the hosted agents to run manual, scheduled, or CI builds. Otherwise, you must set up self-hosted agents that can access your on-premises server and fetch the code.
Reference:
https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/on-premises-bitbucket?view=azure-devops
You are making use of Azure DevOps to configure Azure Pipelines for project, named PROJ-01.
You are preparing to use a version control system that allows for source code to be stored on a managed Windows server located on the company network.
Which of the following is the version control system you should use?
Github Enterprise
Bitbucket cloud
Github Professional
Git in Azure Repos
Answer is Github Enterprise
GitHub Enterprise is the on-premises version of GitHub.com. GitHub Enterprise includes the same great set of features as GitHub.com but packaged for running on your organization's local network. All repository data is stored on machines that you control, and access is integrated with your organization's authentication system (LDAP, SAML, or CAS).
Reference:
https://docs.github.com/en/enterprise-server@3.8/admin/overview/about-github-enterprise-server#about-github-enterprise-server
You need to consider the underlined segment to establish whether it is accurate.
To find when common open source libraries are added to the code base, you should add Jenkins to the build pipeline.
Select `No adjustment required` if the underlined segment is accurate. If the underlined segment is inaccurate, select the accurate option.
No adjustment required.
SourceGear Vault
WhiteSource
OWASP ZAP
Answer is WhiteSource
WhiteSource is the leader in continuous open source software security and compliance management. WhiteSource integrates into your build process, irrespective of your programming languages, build tools, or development environments. It works automatically, continuously, and silently in the background, checking the security, licensing, and quality of your open source components against WhiteSource constantly-updated definitive database of open source repositories.
Azure DevOps integration with WhiteSource Bolt will enable you to:
1. Detect and remedy vulnerable open source components.
2. Generate comprehensive open source inventory reports per project or build.
3. Enforce open source license compliance, including dependencies' licenses.
4. Identify outdated open source libraries with recommendations to update.
Note: Black duck would also be a good answer, but it is not an option here.
Reference:
https://www.azuredevopslabs.com/labs/vstsextend/WhiteSource/
You need to consider the underlined segment to establish whether it is accurate.
To compile an Internet Information Services (IIS) web application that runs docker, you should use a Default build agent pool.
Select `No adjustment required` if the underlined segment is accurate. If the underlined segment is inaccurate, select the accurate option.
No adjustment required.
Hosted Windows Container
Hosted
Hosted macOS
Answer is Hosted Windows Container
Azure Pipelines can run Linux or Windows Containers. Use either hosted Ubuntu for Linux containers, or the Hosted Windows Container pool for Windows containers. (The Hosted macOS pool doesn't support running containers.)
When you need to compile an Internet Information Services (IIS) web application that runs on Docker, you should use a Hosted Windows Container build agent pool. This is because IIS is a web server created by Microsoft specifically for Windows-based systems. Since you want to run the application in a Docker container, a Hosted Windows Container build agent pool will provide the necessary Windows environment along with Docker support.
A build agent pool is a collection of agents used for running build and deployment tasks in a continuous integration and delivery pipeline. The Hosted Windows Container build agent pool is a pre-configured, managed pool provided by Azure DevOps or other CI/CD platforms, which supports running Docker containers on a Windows-based system. By using this pool, you can ensure that your IIS web application is built and run in the appropriate environment.
Reference:
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/service-containers?view=azure-devops&tabs=yaml#requirements
You need to consider the underlined segment to establish whether it is accurate.
To deploy an application to a number of Azure virtual machines, you should create a universal group.
Select `No adjustment required` if the underlined segment is accurate. If the underlined segment is inaccurate, select the accurate option.
No adjustment required.
security
deployment
resource
Answer is deployment
A deployment group is a logical set of deployment target machines that have agents installed on each one. Deployment groups represent the physical environments; for example, "Dev", "Test", or "Production" environment. In effect, a deployment group is just another grouping of agents, much like an agent pool.
When authoring an Azure Pipelines or TFS Release pipeline, you can specify the deployment targets for a job using a deployment group. If the target machines are Azure VMs, you can quickly and easily prepare them by installing the Azure Pipelines Agent Azure VM extension on each of the VMs, or by using the Azure Resource Group Deployment task in your release pipeline to create a deployment group dynamically.
Reference:
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/deployment-groups/?view=azure-devops
You intend to make use of Azure Artifacts to share packages that you wrote, tested, validated, and deployed.
You want to use a solitary feed to release several builds of each package. You have to make sure that the release of packages that are in development is restricted.
Which of the following actions should you take?
You should make use of static code analysis.
You should make use of views.
You should make use of dynamic code analysis.
You should make use of upstream sources.
Answer is You should make use of views.
Views in Azure Artifacts allow you to control the visibility and access to specific packages within a feed. By creating views, you can restrict the release of packages that are still in development and control who has access to them.
You can configure views to include or exclude specific packages based on criteria such as version ranges, tags, or other metadata. This allows you to define separate views for different stages of development, such as a "Development" view for packages still in progress and a "Release" view for packages that have been validated and are ready for deployment.
By using views, you can effectively restrict the release of packages that are in development while using a single feed in Azure Artifacts. This helps maintain control over the availability and visibility of packages to different teams and stakeholders.
Options A, C, and D are not the most appropriate actions
Reference:
https://learn.microsoft.com/en-us/azure/devops/artifacts/concepts/views?view=azure-devops