You are developing an iOS application by using Azure DevOps.
You need to test the application manually on 10 devices without releasing the application to the public.
Which two actions should you perform? Each correct answer presents part of the solution.
NOTE: Each correct selection is worth one point.
B F
Explanation:
B: Follow these steps to register the devices:
Select the Register devices button.
A dialog prompts for your username and password used in the Apple Developer portal.
Once you sign in with your Apple username and password, App Center adds the unprovisioned devices to both your Apple
developer account and the releases provisioning profile. Optionally you can upload a .p12 file to re-sign the app and
distribute it to the newly added devices. Read more on how to generate a .p12 file.
F: Registering a device means making it part of the list of devices on the Apple Developer portal that can then be included in
a provisioning profile.
Incorrect Answers:
C: Only register the application in the iTunes store when it is ready for public release.
Reference:
https://docs.microsoft.com/en-us/appcenter/distribution/auto-provisioning
You have a private distribution group that contains provisioned and unprovisioned devices.
You need to distribute a new iOS application to the distribution group by using Microsoft Visual Studio App Center.
What should you do?
B
Explanation:
When releasing an iOS app signed with an ad-hoc or development provisioning profile, you must obtain tester's device IDs
(UDIDs), and add them to the provisioning profile before compiling a release. When you enable the distribution group's
Automatically manage devices setting, App Center automates the before mentioned operations and removes the constraint
for you to perform any manual tasks. As part of automating the workflow, you must provide the user name and password for
your Apple ID and your production certificate in a .p12 format.
App Center starts the automated tasks when you distribute a new release or one of your testers registers a new device. First,
all devices from the target distribution group will be registered, using your Apple
ID, in your developer portal and all provisioning profiles used in the app will be generated with both new and existing device
ID. Afterward, the newly generated provisioning profiles are downloaded to App Center servers.
Reference:
https://docs.microsoft.com/en-us/appcenter/distribution/groups
Your company develops an application named App1 that is deployed in production.
As part of an application update, a new service is being added to App1. The new service requires access to an application
named App2 that is currently in development.
You need to ensure that you can deploy the update to App1 before App2 becomes available. You must be able to enable the
service in App1 once App2 is deployed.
What should you do?
A
Explanation:
Feature flags support a customer-first DevOps mindset, to enable (expose) and disable (hide) features in a solution, even
before they are complete and ready for release.
Incorrect Answers:
C: Branch policies are an important part of the Git workflow and enable you to:
Isolate work in progress from the completed work in your master branch Guarantee changes build before they get to
master
Reference:
https://docs.microsoft.com/en-us/azure/devops/migrate/phase-features-with-feature-flags
Your company has a project in Azure DevOps for a new web application.
The company uses ServiceNow for change management.
You need to ensure that a change request is processed before any components can be deployed to the production
environment.
What are two ways to integrate ServiceNow into the Azure DevOps release pipeline? Each correct answer presents a
complete solution.
NOTE: Each correct selection is worth one point.
B D
Explanation:
An example of a release pipeline that can be modeled through a release pipeline in shown below:
In this example, a release of a website is created by collecting specific versions of two builds (artifacts), each from a different
build pipeline. The release is first deployed to a Dev stage and then forked to two QA stages in parallel. If the deployment
succeeds in both the QA stages, the release is deployed to Prod ring 1 and then to Prod ring 2. Each production ring
represents multiple instances of the same website deployed at various locations around the globe.
Reference:
https://docs.microsoft.com/en-us/azure/devops/pipelines/release
HOTSPOT
You have a project in Azure DevOps.
You plan to create a build pipeline that will deploy resources by using Azure Resource Manager templates. The templates
will reference secrets stored in Azure Key Vault.
You need to ensure that you can dynamically generate the resource ID of the key vault during template deployment.
What should you include in the template? To answer, select the appropriate options in the answer area.
NOTE: Each correct selection is worth one point.
Hot Area:
Explanation:
Box 1: "Microsoft.Resources/deployments"
Reference a secret with dynamic ID. You need to reference a key vault secret that varies based on the current deployment.
Example:
"resources": [
{
"name": "dynamicSecret",
"type": "Microsoft.Resources/deployments",
"properties": {
"mode": "Incremental",
"templateLink": {
Box 2: "templateLink"
In your parent template, you add the linked template and pass in a parameter that contains the dynamically generated
resource ID.
References: https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-keyvault-parameter
You have an Azure DevOps project named Project1 and an Azure subscription named Sub1. Sub1 contains an Azure SQL
database named DB1.
You need to create a release pipeline that uses the Azure SQL Database Deployment task to update DB1.
Which artifact should you deploy?
B
Explanation:
Use Azure SQL Database Deployment task in a build or release pipeline to deploy to Azure SQL DB using a DACPAC or run
scripts using SQLCMD.
Reference: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/sql-azure-dacpac-deployment
SIMULATION
You need to ensure that an Azure web app named az400-123456789-main supports rolling upgrades. The solution must
ensure that only 10 percent of users who connect to az400-123456789-main use update versions of the app.
The solution must minimize administrative effort.
To complete this task, sign in to the Microsoft Azure portal.
See explanation below.
Explanation:
Set up staging environments in Azure App Service
1. Open Microsoft Azure Portal
2. Log into your Azure account, select your app's resource page, in the left pane, select Deployment slots > Add Slot.
3. In the Add a slot dialog box, give the slot a name, and select whether to clone an app configuration from another
deployment slot. Select Add to continue.
4. After the slot is added, select Close to close the dialog box. The new slot is now shown on the Deployment slots page. By
default, Traffic % is set to 0 for the new slot, with all customer traffic routed tothe production slot.
5. Select the new deployment slot to open that slot's resource page.
6. Change TRAFFIC % to 10
Reference: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots
You have a free tier of an Azure DevOps organization named Contoso. Contoso contains 10 private projects. Each project
has multiple jobs with no dependencies. The build process requires access to resource files located in an on-premises file
system.
You frequently run the jobs on five self-hosted agents but experience long build times and frequently queued builds.
You need to minimize the number of queued builds and the time it takes to run the builds.
What should you do?
B
Explanation:
If you want Azure Pipelines to orchestrate your builds and releases, but use your own machines to run them, use self-hosted
parallel jobs. For self-hosted parallel jobs, you'll start by deploying our selfhosted agents on your machines. You can register
any number of these self-hosted agents in your organization.
Incorrect:
Not D: Microsoft-hosted CI/CD
If you want to run your jobs on machines that Microsoft manages, use Microsoft-hosted parallel jobs. Your jobs run on our
pool of Microsoft-hosted agents.
We provide a free tier of service by default in every organization.
Reference:
https://docs.microsoft.com/en-us/azure/devops/pipelines/licensing/concurrent-jobs
DRAG DROP
You have an Azure DevOps organization named Contoso.
You have 10 Azure virtual machines that run Windows Server 2019. The virtual machines host an application that you build
and deploy by using Azure Pipelines. Each virtual machine has the Web Server (IIS) role installed and configured.
You need to ensure that the web server configurations on the virtual machines is maintained automatically. The solution
must provide centralized management of the configuration settings and minimize management overhead.
Which four actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the
answer area and arrange them in the correct order.
Select and Place:
Explanation:
Step1: Create an Azure Automation account. An Azure Automation account is required.
Step 2: Install the custom Desired State Configuration (DSC) extension on the virtual machines
Under the hood, and without an administrator having to remote into a VM, the Azure VM Desired State Configuration
extension registers the VM with Azure Automation State Configuration.
Step 3: Onboard the virtual machines to the Azure Automation account.
Step 4: Complete the Desired State Configuration (DSC) configuration. Create a DSC configuration.
Reference: https://docs.microsoft.com/en-us/azure/automation/automation-dsc-onboarding
Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a
unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while
others might not have a correct solution.
After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in
the review screen.
You have an approval process that contains a condition. The condition requires that releases be approved by a team leader
before they are deployed.
You have a policy stating that approvals must occur within eight hours.
You discover that deployment fail if the approvals take longer than two hours.
You need to ensure that the deployments only fail if the approvals take longer than eight hours.
Solution: From Post-deployment conditions, you modify the Timeout setting for post-deployment approvals.
Does this meet the goal?
B
Explanation:
Use Pre-deployments conditions instead.
Use a gate instead of an approval instead.
Reference:
https://docs.microsoft.com/en-us/azure/devops/pipelines/release/approvals/gates
DRAG DROP
You are defining release strategies for two applications as shown in the following table.
Which release strategy should you use for each application? To answer, drag the appropriate release strategies to the
correct applications. Each release strategy may be used once, more than once, or not at all. You may need to drag the split
bar between panes or scroll to view content.
NOTE: Each correct selection is worth one point.
Select and Place:
Explanation:
App1: Canary deployment
With canary deployment, you deploy a new application code in a small part of the production infrastructure. Once the
application is signed off for release, only a few users are routed to it. This minimizes any impact.
With no errors reported, the new version can gradually roll out to the rest of the infrastructure.
App2: Rolling deployment:
In a rolling deployment, an applications new version gradually replaces the old one. The actual deployment happens over a
period of time. During that time, new and old versions will coexist without affecting functionality or user experience. This
process makes it easier to roll back any new component incompatible with the old components.
Incorrect Answers:
Blue/Green deployment
A blue/green deployment is a change management strategy for releasing software code. Blue/green deployments, which
may also be referred to as A/B deployments require two identical hardware environments that are configured exactly the
same way. While one environment is active and serving end users, the other environment remains idle.
Blue/green deployments are often used for consumer-facing applications and applications with critical uptime requirements.
New code is released to the inactive environment, where it is thoroughly tested. Once the code has been vetted, the team
makes the idle environment active, typically by adjusting a router configuration to redirect application program traffic. The
process reverses when the next software iteration is ready for release.
References: https://dev.to/mostlyjason/intro-to-deployment-strategies-blue-green-canary-and-more-3a3
Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a
unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while
others might not have a correct solution.
After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in
the review screen.
You have an approval process that contains a condition. The condition requires that releases be approved by a team leader
before they are deployed.
You have a policy stating that approvals must occur within eight hours.
You discover that deployment fail if the approvals take longer than two hours.
You need to ensure that the deployments only fail if the approvals take longer than eight hours.
Solution: From Pre-deployment conditions, you modify the Timeout setting for pre-deployment approvals.
Does this meet the goal?
B
Explanation:
Use a gate instead of an approval instead.
Reference:
https://docs.microsoft.com/en-us/azure/devops/pipelines/release/approvals/gates
Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a
unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while
others might not have a correct solution.
After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in
the review screen.
You have an approval process that contains a condition. The condition requires that releases be approved by a team leader
before they are deployed.
You have a policy stating that approvals must occur within eight hours.
You discover that deployment fail if the approvals take longer than two hours.
You need to ensure that the deployments only fail if the approvals take longer than eight hours.
Solution: From Pre-deployment conditions, you modify the Time between re-evaluation of gates option.
Does this meet the goal?
A
Explanation:
Gates allow automatic collection of health signals from external services, and then promote the release when all the signals
are successful at the same time or stop the deployment on timeout. Typically, gates are used in connection with incident
management, problem management, change management, monitoring, and external approval systems.
Approvals and gates give you additional control over the start and completion of the deployment pipeline. Each stage in a
release pipeline can be configured with pre-deployment and post-deployment conditions that can include waiting for users to
manually approve or reject deployments, and checking with other automated systems until specific conditions are verified.
Reference:
https://docs.microsoft.com/en-us/azure/devops/pipelines/release/approvals/gates
Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a
unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while
others might not have a correct solution.
After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in
the review screen.
You have an approval process that contains a condition. The condition requires that releases be approved by a team leader
before they are deployed.
You have a policy stating that approvals must occur within eight hours.
You discover that deployment fail if the approvals take longer than two hours.
You need to ensure that the deployments only fail if the approvals take longer than eight hours.
Solution: From Post-deployment conditions, you modify the Time between re-evaluation of gates option.
Does this meet the goal?
B
Explanation:
Use a gate From Pre-deployment conditions instead.
Reference:
https://docs.microsoft.com/en-us/azure/devops/pipelines/release/approvals/gates
DRAG DROP
You have an Azure Kubernetes Service (AKS) cluster.
You need to deploy an application to the cluster by using Azure DevOps.
Which three actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the
answer area and arrange them in the correct order.
Select and Place:
Explanation:
You can set up a CI/CD pipeline to deploy your apps on a Kubernetes cluster with Azure DevOps by leveraging a Linux
agent, Docker, and Helm.
Step 1: Create a service principle in Azure Active Directory (Azure AD)
We need to assign 3 specific service principals with specific Azure Roles that need to interact with our ACR and our AKS.
Create a specific Service Principal for our Azure DevOps pipelines to be able to push and pull images and charts of our
ACR.
Create a specific Service Principal for our Azure DevOps pipelines to be able to deploy our application in our AKS.
Step 2: Add a Helm package and deploy a task to the deployment pipeline This is the DevOps workflow with containers:
Step 3: Add a Docker Compose task to the deployment pipeline.
Dockerfile file is a script leveraged by Docker, composed of various commands (instructions) and arguments listed
successively to automatically perform actions on a base image in order to create a new Docker image by packaging the app.
Reference: https://cloudblogs.microsoft.com/opensource/2018/11/27/tutorial-azure-devops-setup-cicd-pipeline-kubernetes-
docker-helm/
Implement Dependency Management