AZ-104 Question #229: Real Exam Question with Answer & Explanation

Question

Case Study 4 - ADatum Overview ADatum Corporation is a financial company that has two main offices in New York and Los Angeles. ADatum has a subsidiary named Fabrikam, Inc. that shares the Los Angeles office. ADatum is conducting an initial deployment of Azure services to host new line-of-business applications and is preparing to migrate its existing on-premises workloads to Azure. ADatum uses Microsoft Exchange Online for email. Existing Environment On-Premises Environment The on-premises workloads run on virtual machines hosted in a VMware vSphere 6 infrastructure. All the virtual machines are members of an Active Directory forest named adatum.com and run Windows Server 2016. The New York office uses an IP address space of 10.0.0.0/16. The Los Angeles office uses an IP address space of 10.10.0.0/16. The offices connect by using a VPN provided by an ISP. Each office has one Azure ExpressRoute circuit that provides access to Azure services and Microsoft Online Services. Routing is implemented by using Microsoft peering. The New York office has a virtual machine named VM1 that has the vSphere console installed. Azure Environment You provision the Azure infrastructure by using the Azure portal. The infrastructure contains the resources shown in the following table. AG1 has two backend pools named Pool11 and Pool12. AG2 has two backend pools named Pool21 and Pool22. Requirements Planned Changes ADatum plans to migrate the virtual machines from the New York office to the East US Azure region by using Azure Site Recovery. Infrastructure Requirements ADatum identifies the following infrastructure requirements: A new web app named App1 that will access third-parties for credit card processing must be deployed. A newly developed API must be implemented as an Azure function named App2. App2 will use a blob storage trigger. App2 must process new blobs immediately. The Azure infrastructure and the on-premises infrastructure must be prepared for the migration of the VMware virtual machines to Azure. The sizes of the Azure virtual machines that will be used to migrate the on-premises workloads must be identified. All migrated and newly deployed Azure virtual machines must be joined to the adatum.com domain. AG1 must load balance incoming traffic in the following manner: AG2 must load balance incoming traffic in the following manner: ER1 must route traffic between the New York office and platform as a service (PaaS) services in the East US Azure region, as long as ER1 is available. ER1 must route traffic between the Los Angeles office and the PaaS services in the West US region, as long as ER2 is available. ER1 and ER2 must be configured to fail over automatically. Application Requirements App2 must be available to connect directly to the private IP addresses of the Azure virtual machines. App2 will be deployed directly to an Azure virtual network. Inbound and outbound communications to App1 must be controlled by using NSGs. Pricing Requirements ADatum identifies the following pricing requirements: The cost of App1 and App2 must be minimized The transactional charges of Azure Storage accounts must be minimized Hotspot Question You need to implement App2 to meet the application requirements. What should you include in the implementation? To answer, select the appropriate options in the answer area. NOTE: Each correct selection is worth one point. Answer:

Options

• __typehotspot
• variantdropdown

Explanation

Selecting the Standard App Service plan and the Always On feature ensures a production-grade, responsive environment for line-of-business applications.

Approach. Based on the case study mentioning the deployment of 'new line-of-business applications', a robust and responsive environment is crucial.

1. App Service plan pricing tier: Standard The 'Standard' tier is chosen because it offers dedicated compute resources, autoscaling capabilities, custom domains, SSL support, and staging slots, making it highly suitable for production line-of-business applications that require reliable performance and scalability. It provides a good balance of features and cost-effectiveness compared to the more basic 'Shared' tier or the high-cost, highly isolated 'Isolated' tier.

2. Enabled feature: Always on The 'Always on' feature is selected because it prevents the web application from being unloaded due to inactivity. For line-of-business applications, it's critical to ensure quick response times and continuous availability, especially for background jobs, API endpoints, or webhooks that might not receive constant user traffic. Enabling 'Always on' ensures the application instance remains loaded and ready to respond without incurring cold starts.

Common mistakes.

• common_mistake. 1. Choosing 'Shared' for the pricing tier: The 'Shared' tier is not suitable for production 'line-of-business applications'. It runs on shared resources, lacks dedicated compute, and offers very limited features, making it prone to performance issues, unreliability, and not meeting typical production requirements.

1. Choosing 'Isolated' for the pricing tier without specific requirements: While 'Isolated' offers the highest level of performance and network isolation (within an Azure Virtual Network), it is also the most expensive. Unless the application explicitly requires VNet integration for enhanced security, hybrid connectivity, or extreme scale beyond what 'Standard' or 'Premium' offers, 'Standard' is a more cost-effective and appropriate choice for general production LOB apps.
2. Choosing 'Auto Swap' for the enabled feature instead of 'Always on': 'Auto Swap' is a deployment feature used with staging slots for automated, zero-downtime deployments. While beneficial for CI/CD, it doesn't address the fundamental need for the application itself to remain active and responsive, which 'Always on' provides.
3. Choosing 'Web Sockets' for the enabled feature instead of 'Always on': 'Web Sockets' is a communication protocol feature for real-time applications. While important for specific architectures, it's not a general operational requirement for an application to stay active and responsive in the way 'Always on' is. 'Always on' ensures the app instance is loaded, irrespective of the communication protocols it uses.

Concept tested. Azure App Service plan pricing tiers and their associated features. This includes understanding the capabilities and limitations of different tiers (Shared, Standard, Isolated) and the purpose and availability of key operational features like 'Always On' for ensuring application responsiveness and reliability in production environments.

No community discussion yet for this question.