Explanation/Reference:
Testlet 1
Case study
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirement, existing environment, and problem statements. If the case study has an All Information tab, note that the information displayed is identical to the information displayed on the subsequent tabs. When you are ready to answer a question, click the Question button to return to the question.
Overview
Contoso, Ltd. is a US-based financial services company that has a main office in New York and a branch office in San Francisco.
Existing Environment
Payment Processing System
Contoso hosts a business-critical payment processing system in its New York data center. The system has three tiers: a front-end web app, a middle-tier web API, and a back-end data store implemented as a Microsoft SQL Server 2014 database. All servers run Windows Server 2012 R2.
The front-end and middle-tier components are hosted by using Microsoft Internet Information Services (IIS). The application code is written in C# and ASP.NET. The middle-tier API uses the Entity Framework to communicate to the SQL Server database. Maintenance of the database is performed by using SQL Server Agent jobs.
The database is currently 2 TB and is not expected to grow beyond 3 TB.
The payment processing system has the following compliance-related requirements:
Encrypt data in transit and at rest. Only the front-end and middle-tier components must be able to

access the encryption keys that protect the data store.
Keep backups of the data in two separate physical locations that are at least 200 miles apart and can

be restored for up to seven years.
Support blocking inbound and outbound traffic based on the source IP address, the destination IP

address, and the port number.
Collect Windows security logs from all the middle-tier servers and retain the logs for a period of seven

years.
Inspect inbound and outbound traffic from the front-end tier by using highly available network

appliances.
Only allow all access to all the tiers from the internal network of Contoso.

Tape backups are configured by using an on-premises deployment of Microsoft System Center Data Protection Manager (DPM), and then shipped offsite for long term storage.
Historical Transaction Query System
Contoso recently migrated a business-critical workload to Azure. The workload contains a .NET web service for querying the historical transaction data residing in Azure Table Storage. The .NET web service is accessible from a client app that was developed in-house and runs on the client computers in the New York office. The data in the table storage is 50 GB and is not expected to increase.
Current Issues
The Contoso IT team discovers poor performance of the historical transaction query system, at the queries frequently cause table scans.
Requirements
Planned Changes
Contoso plans to implement the following changes:
Migrate the payment processing system to Azure.

Migrate the historical transaction data to Azure Cosmos DB to address the performance issues.

Migration Requirements
Contoso identifies the following general migration requirements:
Infrastructure services must remain available if a region or a data center fails. Failover must occur

without any administrative intervention.
Whenever possible, Azure managed services must be used to minimize management overhead.

Whenever possible, costs must be minimized.

Contoso identifies the following requirements for the payment processing system:
If a data center fails, ensure that the payment processing system remains available without any

administrative intervention. The middle-tier and the web front end must continue to operate without any additional configurations.
Ensure that the number of compute nodes of the front-end and the middle tiers of the payment

processing system can increase or decrease automatically based on CPU utilization.
Ensure that each tier of the payment processing system is subject to a Service Level Agreement (SLA)

of 99.99 percent availability.
Minimize the effort required to modify the middle-tier API and the back-end tier of the payment

processing system.
Generate alerts when unauthorized login attempts occur on the middle-tier virtual machines.

Ensure that the payment processing system preserves its current compliance status.

Host the middle tier of the payment processing system on a virtual machine.

Contoso identifies the following requirements for the historical transaction query system:
Minimize the use of on-premises infrastructure services.

Minimize the effort required to modify the .NET web service querying Azure Cosmos DB.

Minimize the frequency of table scans.

If a region fails, ensure that the historical transactions query system remains available without any

administrative intervention.
Information Security Requirements
The IT security team wants to ensure that identity management is performed by using Active Directory.
Password hashes must be stored on-premises only.
Access to all business-critical systems must rely on Active Directory credentials. Any suspicious authentication attempts must trigger a multi-factor authentication prompt automatically. legitimate users must be able to authenticate successfully by using multi-factor authentication.
Testlet 2
Case study
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirement, existing environment, and problem statements. If the case study has an All Information tab, note that the information displayed is identical to the information displayed on the subsequent tabs. When you are ready to answer a question, click the Question button to return to the question.
Overview
Fabrikam, Inc. is an engineering company that has offices throughout Europe. The company has a main office in London and three branch offices in Amsterdam, Berlin, and Rome.
Existing Environment
Active Directory Environment
The network contains two Active Directory forests named corp.fabrikam.com and rd.fabrikam.com. There are no trust relationships between the forests.
Corp.fabrikam.com is a production forest that contains identities used for internal user and computer authentication.
Rd.fabrikam.com is used by the research and development (R&D) department only.
Network Infrastructure
Each office contains at least one domain controller from the corp.fabrikam.com domain. The main office contains all the domain controllers for the rd.fabrikam.com forest.
All the offices have a high-speed connection to the Internet.
An existing application named WebApp1 is hosted in the data center of the London office. WebApp1 is used by customers to place and track orders.
WebApp1 has a web tier that uses Microsoft Internet Information Services (IIS) and a database tier that runs Microsoft SQL Server 2016. The web tier and the database tier are deployed to virtual machines that run on Hyper-V.
The IT department currently uses a separate Hyper-V environment to test updates to WebApp1.
Fabrikam purchases all Microsoft licenses through a Microsoft Enterprise Agreement that includes Software Assurance.
Problem Statements
The use of Web App1 is unpredictable. At peak times, users often report delays. At other times, many resources for WebApp1 are underutilized.
Requirements
Planned Changes
Fabrikam plans to move most of its production workloads to Azure during the next few years.
As one of its first projects, the company plans to establish a hybrid identity model, facilitating an upcoming Microsoft Office 365 deployment.
All R&D operations will remain on-premises.
Fabrikam plans to migrate the production and test instances of WebApp1 to Azure.
Technical Requirements
Fabrikam identifies the following technical requirements:
Web site content must be easily updated from a single point.

User input must be minimized when provisioning new app instances.

Whenever possible, existing on-premises licenses must be used to reduce cost.

Users must always authenticate by using their corp.fabrikam.com UPN identity.

Any new deployments to Azure must be redundant in case an Azure region fails.

Whenever possible, solutions must be deployed to Azure by using platform as a service (PaaS).

An email distribution group named IT Support must be notified of any issues relating to the directory

synchronization services.
Directory synchronization between Azure Active Directory (Azure AD) and corp.fabrikam.com must not

be affected by a link failure between Azure and the on-premises network.
Database Requirements
Fabrikam identifies the following database requirements:
Database metrics for the production instance of WebApp1, must be available for analysis so that

database administrators can optimize the performance settings.
To avoid disrupting customer access, database downtime must be minimized when databases are

migrated.
Database backups must be retained for a minimum of seven years to meet compliance requirements.

Security Requirements
Fabrikam identifies the following security requirements:
Company information including policies, templates, and data must be inaccessible to anyone outside

the company.
Users on the on-premises network must be able to authenticate to corp.fabrikam.com if an Internet link

fails.
Administrators must be able authenticate to the Azure portal by using their corp.fabrikam.com

credentials.
All administrative access to the Azure portal must be secured by using multi-factor authentication.

The testing of WebApp1 updates must not be visible to anyone outside the company.