In the last chapter, you learned how to organize and manage core resources and solutions across Azure’s global enterprise infrastructure. Organizational and geographic distribution is just one part of familiarizing yourself with Azure. Whether you are building a cloud environment from scratch or utilizing preexisting assets available in the Azure Marketplace, you must build a baseline infrastructure before you deploy cloud solutions. To do so requires compute, databases, storage, and networking resources, which are the backbone of the Azure Cloud. The chapter reviews each of these resource types at length to prepare you for the AZ-900 exam.

An Introduction to Compute Resources

Microsoft Azure is broken down into service groups. Among the most important groups are those associated with compute resources, which cover storage, database, and networking. Azure offers users many options to build and deploy applications, from the underlying infrastructure to a communication backbone. Microsoft Azure allows for infrastructure to scale on demand in a variety of scenarios. You may want to deploy virtual machines with a core operating system, creating an Infrastructure as a Service (IaaS) baseline or containerize applications using Platform as a Service (PaaS)–based support. If there is a need for unique storage or database features, one can provision such capabilities within the virtualized environments. As you begin exploring this chapter, keep in mind that Microsoft Azure offers a variety of pricing options from pay-as-you-go, to enterprise licensing arrangements, to prepayment commitments. You should consider how much you need and how long you will utilize a service as you select your technology options.

Azure Virtual Machines

To the everyday computing user, with the press of the power button on a desktop or laptop computer, an operating system loads with all their computer files. The user goes about doing everyday tasks, be it surfing the Internet, actively using software applications, listening to multimedia files stream, or allowing for files to remain stored on the device, as a means of backup, to complete. However, the hard drive on a computer has clear limits. There is no way to scale beyond the physical confines of the computer storage limits. In other words, you cannot create a computer within a computer! What happens if you wanted to run multiple operating systems—would it be possible? Is it possible for you to grow and expand your storage footprint effortlessly? These are some of the common challenges an end user might face if they rely exclusively on their computer to manage operational activity. How is it, then, that one can overcome these massive technical limitations? The use of virtual machines, also called images, is the solution.

A virtual machine is a standalone file that can be stored on your local computer or in the cloud in isolation from any other system. There is absolutely no interaction whatsoever with a host operating system. This means that any activity that a user completes on the virtual instance will have no bearing whatsoever on the computer the virtual instance operates on. Sounds too perfect to be true, right? You can create test and development environments without harming another system. If the test system is compromised by an accidental virus or error created by programmatic code, the host system remains safe. It does not matter if there is one or multiple virtual environments running on the same computer—all systems still run independently.

When virtualized environments run multiple operating systems side by side, the infrastructure requires the use of a software application called a hypervisor. A hypervisor allows for the management of many image instances to run concurrently, while a desktop or cloud compute environment employs a single operating system. The virtual environment presumably standardizes on a configuration that indicates a virtual hardware standard, including CPU, memory, hard drive storage, network interface, and other core capabilities that operate in lockstep with the operating system. Your virtual hardware maps to real hardware on a physical machine somehow, whether it is in the cloud or the computer on your desktop. Regardless, the main objective is to cut cost, expand the footprint capacity, and reduce the environmental impact through power consumption.

An Azure Virtual Machine is the deployable cloud solution to handling on-demand scalable computer resources in the Microsoft ecosystem. A user chooses the virtual machine environment they require when needing more control over compute capacity. Before creating a virtual machine in Microsoft Azure, a user should consider several factors, such as what tasks they will perform, the purpose of the application that will sit on the image instance, what ancillary applications will be needed to support the primary applications, and what a patching regimen may look like. Even though the virtual machine is not actually a real computer, you are still responsible for maintaining the instance as if it were a full-fledged operating environment. Table 3-1 describes the three scenarios where an Azure environment could be used.

Table 3-1 Azure Environment Types

Azure Virtual Machine Design Configuration

A good programmer does not just dive right in and start coding. They plan out all the elements that will be required to execute the code flawlessly. The same should be true for the cloud professional as they embark upon configuring a virtual machine instance in Microsoft Azure. You have options to consider when you are building out an infrastructure in Azure. Some are necessary; others are nice to have. Table 3-2 addresses some of these considerations.

Table 3-2 Virtual Machine Considerations

While this list is just a sampling of considerations you will need to address at the onset of virtual machine configuration, these are significant, nonetheless. Any time you decide to set up a virtual machine in Microsoft Azure, you will be asked to make numerous configuration decisions that will have an influence on performance and cost of services.

Configuring an Azure Virtual Machine

To create a new Azure Virtual Machine instance, you will need to log in to the Microsoft Azure Portal using your Azure account. The address you want to go to is https://portal.azure.com. There are two methods to create an Azure Virtual Machine. The first option is creating a virtual machine based on a preexisting application configuration from the Azure Marketplace. A second alternative is creating a bare image that you install an application onto using a preconfigured instance that is only provisioned with the necessary storage, networking, and operating system essentials. You will configure the latter instance in this section. In Figure 3.1, you will notice in the Azure Dashboard various options to choose from under Featured Services. Links to those services can also be found under the column on the left.

Figure 3-1 Azure Dashboard and navigation

1.   Click Virtual Machine (Figure 3-1).

2.   Select the Add Button, and choose Virtual Machine (Figure 3-2).

Figure 3-2 Select Add Virtual Machine.

3.   A page will load allowing you to begin configuring the virtual machine.

You have many options to select from, which include Basics, Disks, Networking, Management, Advanced, Networking, Tags, and Review + Create. For ease of ensuring that all steps are covered, follow the guided wizard. Start with completing all the steps under Basic in Figure 3-3. Then, configure the following items:

Figure 3-3 Basic virtual machine configuration interface

•   Subscription You may have one or more subscriptions (Enterprise Agreement, Pay-As-You-Go).

•   Resource Group Which bucket will all your objects be housed in for the purposes of billing?

•   Virtual Machine Name Enter the name of your virtual machine instance.

•   Region Select the geography/country where the virtual machine will be hosted.

•   Availability Select if you would like the image to be stored in an Availability Zone or Availability Set.

•   Spot Instance When you are looking to implement a development instance, you may choose to implement spot instances to support unused capacity for a particular region. Should there no longer be any availability for the VM, it becomes deallocated. Pricing is not fixed like a standard instance. It varies based on available capacity.

•   Size Based on two measures: vCPU and memory. The price increases based on higher vCPU and memory capacity. Memory tends to be the more expensive variable of the two.

•   Authentication Type Password (requires username and password) or SSH (requires username, SSH public key source, and key pair name).

•   Public Inbound Ports Either None or Allow Selected Ports (SSH, HTTP, HTTPS).

If your intention is to use a basic virtual machine configuration, click the Review + Configure button on the bottom-left area of the screen once you have completed the configuration of all the options listed. The one action that you will have the option to select at the end is the storage capacity.

Should you want to refine configuration options such as the disk type, the networking configuration, virtual machine operations (including boot diagnostics), host operations, and tags to the virtual machine, you will want to interact with each of the interfaces separately.

To configure the disk, click Next : Disks at the bottom of the Basics screen (Figure 3-3).

On the Disks screen (Figure 3-4), you will be asked to configure the following:

Figure 3-4 Disks interface setup for virtual machines

•   OS Disk Type Select from Standard HDD, Standard SSD, or Premium SSD.

•   Encryption Type Select from Encryption At Rest, Encryption At Rest With Customer-Managed Keys, or Double Encryption With Platform-Managed And Customer-Managed Keys

On the bottom of the Disks screen, if you select Advanced, you can choose the disk type: Managed or Ephemeral. Managed disks are ideal when you are looking for top-notch performance, reliability, scalability, and access control. Users should consider unmanaged disks when they intend to manage their own storage account or virtual hard drive (VHD). An ephemeral disk is created on a local virtual machine. So long as the storage is not used, you do not incur cost with this storage type. Upon completing the configuration of the disks, move onto the next screen by selecting Next: Networking.

Configuring the network interface (Figure 3-5) requires that one understand the necessary network configurations for public and private network connectivity consumption. Addressable areas that will be necessary to configure include

Figure 3-5 Network interface

•   Virtual Network

•   Subnet

•   Public IP

•   NIC Network Security Group

•   Public Inbound Ports

•   Select Inbound Ports (based on Public Inbound Ports)

•   Load Balancing

Upon selecting the appropriate items for the networking interface connectivity that enable either public or private connectivity, go to the bottom of the page and select Next: Management.

When you select this button, the next step in the configuration process under Management (Figure 3-6) requires you to set up Monitoring, Identity Auto-Shutdown, and Backup configurations. Configurations under this page include

Figure 3-6 Management interface setup for virtual machines

•   Boot Diagnostics

•   Enabling OS Guess Diagnostics

•   Setting System Assigned Managed Identity

•   Enabling Auto-Shutdown

•   Enabling Backup

Once management selections are chosen, you will click the Next: Advanced button on the bottom right. You are then presented with the Advanced interface (Figure 3-7). The purpose of this interface is to add configurations, agents, scripts, or applications via virtual machine extensions or cloud-init that are already not configured using standard parameters. Once you complete any ancillary configurations, click the button Next: Tags on the bottom right.

Figure 3-7 Advanced interface setup for virtual machines

Tagging, as seen in Figure 3-8, when creating an Azure Virtual Machine is designed to manage name/value pairs. More specifically, tagging enables a user to categorize resources and complete activities such as conduct billing management by applying a structure to resources. When you create a tag, any time a change is made to a resource setting, all changes made to other tags will automatically get updated. After all tagging is completed, select Next: Review + Create, which allows you to review a summary of all submitted configurations.

Figure 3-8 Tagging setup for virtual machines

On the Review + Create interface, a user can review a snapshot of virtual machine configuration, including a complete breakdown of costs for the services they will consume for their virtualized environment. If all configurations are acceptable, click the Create button on the bottom left side (Figure 3-9). The Create button will trigger the execution of a customized virtual environment. A screen will notify you that your deployment is in process (Figure 3-10). Once the deployment is complete, a new screen appears providing you with a confirmation of the subscription, resource group, and deployment details associated with the virtual machine environment (Figure 3-11).

Figure 3-9 Review Screen of your virtual machine configuration

Figure 3-10 Deployment in process interface

Figure 3-11 Deployment of virtual machine complete

Billing and Virtual Machines

Once you create a virtual machine, the billing clock starts that very second. You might be puzzled and ask why? You are probably thinking, “I am not consuming Azure compute utilization capacity.” You may not even be accessing the image more than once a month. This may all be true. However, if the virtual instance is powered up and you agree to pay for a large image at the onset of the configuration, you should be prepared to get a large invoice at the end of the billing cycle. So long as your instance is running and the default settings are configured, you will continue to pay perpetually.

To stop billing for a virtual machine, you must click the Stop button at the top of the toolbar, found in Figure 3-12. Azure will pause the virtual machine instance in its current state. Billing will cease. You will not be able to access the virtual machine while idle, but you also will save yourself from spending unnecessary funds. Even when you stop the operational state of the virtual machine, you still pay for the underlying storage. Therefore, you will still be billed for some form of infrastructure utilization, just not to the extent you would should your virtual machine instance be running.

Figure 3-12 Stopping a virtual machine

There are some important networking considerations to address when stopping a virtual machine instance. Assuming you configured the virtual machine with a static IP address, your instance will remain the same. However, if you selected a dynamic address, upon restarting the virtual machine, your address will change. Bear in mind that you may stop the virtual machine, but that does not mean that all resource costs are frozen. Since the IP address is still allocated to your instance, you will still incur a charge for the address, the managed disk, and other allocated resources. The only thing you are not paying for is the operating virtual instance being active.

Availability Options for Virtual Machines

Depending upon the capacity requirements needed across one or more virtual machines, workloads may require high throughput, performance, and redundancy to support virtual machine operations. There are numerous options in Microsoft Azure to achieve high availability, as described throughout this section.

The first option is Availability Zones. An Availability Zone expands virtual machine control to maintain the availability of applications and data on a virtual machine. Since an Availability Zone is a physically separate zone within an Azure region with distinct power sources, network, and cooling, the virtual machine environment in each zone can be replicated to best support the applications and data against loss. Assuming the virtual machine is replicated, if one zone is compromised, the replicated application and data in another zone are automatically made available in another zone.

A second alternative is a fault or update domain. Fault domains are logical groups of underlying hardware that share a common infrastructure such as power sources and network switches, similar to what you might find in an on-premises data center. Whenever the logical grouping requires maintenance, the domains can be updated taking the update domain approach by rebooting. Using this approach ensures that at least a single instance of an application remains operational in the Azure environment, even during a periodic maintenance event. It does not matter what the sequence of the maintenance is, but only one update domain can occur at a time. Figure 3-13 presents a fault and update domain residing in an availability set.

Figure 3-13 Availability set with two fault domains and three update domains

Availability sets are the third option when considering high availability. Representing another form of logical grouping that allows Azure to support application redundancy and availability with the potential of 99.95 percent SLA guarantees, an availability set requires two or more VMs to ensure operational reliability. There is no charge for maintaining the set itself. The only cost incurred is for maintaining each VM instance created. For example, a single virtual machine using a Premium SSD will incur a specific charge. In the availability set, the virtual machine is automatically distributed across the domains. Should there be potential physical hardware limitations and failures, there is limited impact to physical hardware disruption. It is important to remember that only virtual machine instances with managed disks can be created using managed availability sets. You must have at a minimum two or three managed disk fault domains per region to successfully operate in each region. If this is the case, an availability set will update across domains automatically.

Scale sets allow you to create and manage a load-balanced set of virtual machine instances. You can create or decrease the load in response to a defined schedule. Different from Availability Zones is the fact that scale sets can accommodate high availability through central configuration and update management across two or more virtual machines. For a scale set to work, it must have a minimum of two virtual machine instances, which also ensures 99.95 percent SLA terms. Like other high-availability architecture options, you only pay for the virtual machine instances created.

Azure App Service

Azure App Service provides PaaS options that support HTTP-based web application hosting, REST APIs, and mobile back-end support. If the end goal is to develop a standalone application in a native program language such as .NET, Java, PHP, or Python while also focusing on limited maintenance, App Service is ideal. You can run and scale an application within a Windows- or Linux-based virtual machine environment with strong security, load balancing, autoscaling, and automated management. Unlike with virtual machines, App Service offers DevOps capabilities, including continuous deployment, using Azure DevOps and GitHub. Staging environments, custom domains, and TLS/SSL certificates can also be applied to App Services for strong integration abilities. Like other Azure compute resources, you only pay for what you utilize based on the Azure App Service plan that you run your applications on.

Figure 3-14 illustrates the conceptual nature of an App Service architecture. The diagram simplifies how an App Service works whereby an Azure Load Balancer distributes traffic to a virtual machine housed within the App Service front end. An App Service front end enables the distribution of traffic to a specific web app. The virtual machine environments run inside an App Service plan, which is a logical container that houses one or more virtual machines running web apps.

Figure 3-14 High-level App Service architecture model

App Service Plans

When configuring an App Service plan (Figure 3-15), you must identify a combination of factors: region, number of virtual machine instances, size of instance, and pricing tier selected. The factor that influences features for App Service most is the pricing tier, as seen in Table 3-3.

Figure 3-15 App Service plan interface

Table 3-3 App Service Plan Tiers

Creating a Web App

Users have two options when they create a web app. The user can create a web app using an existing App Service plan or utilize a new plan for an app. Regardless of choice, web apps in an App Service plan run on a virtual machine. If you want to ensure reliability, consistency, and isolate your app from other system functions, a best practice is to contain a web app by creating a new App Service plan and containing the app within the virtual machine environment. You have a choice between creating a preconfigured virtual machine runtime stack or running an application using a dedicated container such as Docker. Should you choose to leverage a preconfigured stack, Microsoft Azure offers multiple versions of a given app service. Figure 3-16 illustrates how you can go about configuring a Web app. Additionally, Figure 3-17 provides you a sampling of some runtimes available for web apps.

Figure 3-16 Web app configuration interface

Figure 3-17 Runtime options for web apps

Benefits of Azure App Services

When determining what solution is best to build a custom application, you should take a few factors into consideration. An organization that wants to forego managing infrastructure, security patching, and scaling is best suited for using Azure App Service versus other alternatives. The benefits are as follows:

•   Programming Language, API, and Integration Options You can quickly deploy and scale an app using almost any programming language, integrate with most APIs, configure an app within any container, or contain an app inside a Windows- or Linux-based virtual machine.

•   Enterprise Grade Security Organizations mandated to meet rigorous security and compliance requirements need not worry about achieving this through self-management, as an Azure App Service environment is fully managed.

•   Connectivity Options Integration with a virtual network in either isolated or dedicated mode in conjunction with a rigorous security and compliance posture that covers Security Operations Center (SOC) and Payment Card Industry (PCI) Compliance is only available under App Service because it is a PaaS.

•   Scale and Availability Development options are available at a global scale, with high availability whether the organization requires a dedicated environment, DevOps optimization, connectivity to SaaS platforms, or a hybrid compute model.

App Service allows for more control over the operating system or security settings. If your organization is interested in implementing a microservice architecture, the Azure Spring Cloud Service or the Azure Service Fabric is more appropriate. The Azure Spring Cloud Service provides users with managed services that support full autonomy of running microservices on Azure using Spring-boot or Steeltoe, with minor code changes. On the other hand, if your application requires scaled distribution and the main objective is to package, deploy, and reliably manage microservices or containers, not just standalone App Service, using Azure Service Fabric will be more appropriate for your organization.

Azure Container Instances

When you are looking for a way to run event-driven applications in isolation with the support of a managed, serverless environment, your best compute choice is Azure Container Instances (ACI). With ACI, you can run Docker containers on-demand in a managed, serverless Azure environment. Azure Container Instances is PaaS-based.

The reason why containers are a solid option is their flexibility in allowing organizations to move applications between environments, especially in the cloud. Containers help alleviate the burden of transporting environments by creating an image of an application. The image includes all the components necessary to run the application in isolation, such as a database engine, a web server, security, and the operating system infrastructure. You can deploy the image to any environment that supports the use of containers. Once the image is moved to the new environment, it can be enabled so long as a container runtime is installed on the environment. Azure supports DC/OS, Docker, and Kubernetes runtimes.

Your organization should consider the use of containers when there is a need to enforce a strong security posture first and foremost. Since a container operates in an isolated environment with its own network backbone, storage, and operating system, other containers running in the same machine environment are not able to access any data on one system unless the image explicitly allows for interaction between both environments.

Creating an Azure Container Instance

One of the reasons you would consider using ACI is because it requires minimal configuration, being a serverless PaaS-based technology. To create a new container instance, go to the search bar at the top of the screen, enter Container Instances, and select Container Instances (Figure 3-18).

Figure 3-18 Searching for Container Instances

You will then create an Azure Container Instance following these instructions:

1.   Click the New button (Figure 3-19).

Figure 3-19 New Azure Container Instance button

2.   The Create A New Container Image screen appears, as shown in Figure 3-20, which requires a user to configure the following:

Figure 3-20 Azure Container Instance creation interface

•   Subscription Under the ACI, you are associating the Azure subscription with the container server. By selecting a subscription, you also associate how resource usage is reported and services are billed.

•   Resource Group Resource groups are buckets that allow a user to associate objects (resources) within the container under the same lifecycle, permission, and policy set to a named group.

•   Container Name A unique isolated instance to house the application in a managed, serverless setting, the Azure Container should be different from the image name.

•   Region What geography should the resource be deployed from?

•   Image Source If you create your own image, it must be stored in an Azure Container Registry. If you plan on using a pre-built image, follow the prompts with the QuickStart image by selecting an image pre-built by Microsoft under Image. Should you plan on utilizing Docker Hub or another registry, you must point to the location and select if the image is a public or private image.

•   Image Depending on what your image source is, you would select an option from this menu for the most appropriate image based on operating system (OS) type.

•   Size Containers require you to select a baseline configuration of CPU, memory, and GPU requirements. Depending on the region and technical requirements, availability varies.

Once you configure each of the fields, proceed to the next page by clicking Next: Networking on the bottom-right side. You must configure the Networking settings to ensure the container is available for either public or private consumption (Figure 3-21). Unless specific advanced settings are required, you can click the Review + Create button on the bottom of the Networking Configuration Interface page. On the following page, you will be asked to confirm the settings you have selected to create the ACI (Figure 3-22). Click Create once you have reviewed all options.

Figure 3-21 Network configuration settings for Azure Container Instances

Figure 3-22 Review ACI configuration pre-creation

While the use of Azure Container Instances may sound appealing, there are several things to consider. First, the architecture is intended for simple applications. ACI is not optimal when you intend to have heavy application usage, because scalability is limited. Instead, Azure Kubernetes Service (AKS) is better suited for enterprise-grade, transactional serverless applications.

Azure Kubernetes Service

When you or the organization you work for is looking to establish a more robust solution for managing containers, including orchestration management, Azure Kubernetes Service (AKS), is the best approach to take, since Microsoft handles the technical burden. AKS handles monitoring at all times, including when containers need to scale up or down. Given AKS is a PaaS platform, Kubernetes delivers containers using pods, which means all containers are grouped together because they are alike. Each container within a pod shares the resources with one another. If resource management is a concern, it should not be, because Kubernetes offloads any resource constraints through sharing restrictions seen in other types of multicontainer settings.

Resources in one pod container are not able to be shared within a container in another pod, though. Each Kubernetes pods runs in a node, also referred to as a worker. Each instance must have its own container runtime to operate. An example container runtime is Docker. To operate efficiently, nodes must also operate different services so that Kubernetes can manage the pods. In this case, there will be multiple nodes for a given Kubernetes instance under the control of a master node, also referred to as the Kubernetes master. The combination of all environment components, including the master and nodes, is called an Azure Kubernetes Cluster.

To create an Azure Kubernetes Service, locate the Kubernetes Service icon or search for Kubernetes Service. Then, once you have landed on the Kubernetes Service page, click the Add Kubernetes Cluster button (Figure 3-23). You will need to go through the Create Kubernetes Service interface (Figure 3-24) and enter the required fields across each of the tabs, including Basic, Node Pool, Authentication, Networking, Integrations, Tags, and Review + Create, to complete the AKS setup.

Figure 3-23 Add Kubernetes Cluster navigation screen

Windows Virtual Desktop

When your organization prefers to control desktop and app virtualization by hosting all services on the cloud, they can create virtualized desktop environments. For Azure users, this service is called Windows Virtual Desktop, a PaaS-based offering. What makes Windows Virtual Desktop on Azure so attractive is the ability to deploy and scale capabilities rapidly with ease.

In the past, organizations used to deploy Microsoft 365 business productivity or a homegrown application by licensing an application. Then, the organization would deploy the application on each machine, making it quite inefficient and highly insecure to support business operations. A business would need to deal with data sprawl, given no two systems were configured alike, partially because operational inconsistencies and a litany of security constraints exist. Maintenance would be difficult for even the best IT support professional. That is why many businesses have shifted their ability to manage their workforce’s compute capabilities to the cloud using desktop virtualization.

With desktop virtualization, a business can install an operating system, as well as the critical applications, on a centralized server. Using the desktop virtualization infrastructure features, the end user can access the full host of features from almost any form factor they desire, assuming it can connect to the Internet. Not a single application is downloaded to the end user’s desktop—everything is accessed via a web-based browser, even though the user experiences the virtual environment as if the software were local to their desktop.

It may sound easy to provision a Windows Virtual Desktop (WVD). However, the process can be quite complex at first, as it does require some advanced configurations initially. While Microsoft does support the entire infrastructure, given that WVD is PaaS-based, you are required to create a WVD tenant to operate. A WVD tenant consists of a collection of one or more host pools. A host pool is made up of one or more identical virtual machine instances within Windows Virtual Desktop environments. Each virtual machine instance is a dedicated Azure Virtual Machine instance that has been configured for Windows Virtual Desktop.

Upon completing a configured tenant, you can add users from the Azure Active Directory, where they can access all operating systems in each tenant and assignment permissions. Users have the option to access a WVD using several different client apps, including Windows, macOS, Apple iOS, Google Android OS, or through a web-based client browser.

An Introduction to Storage Resources

Numerous types of storage are available in Microsoft Azure. When you intend to use storage classes against code such as a REST API, offerings considered include blob, table, and queue storage. Such storage is commonly used with PaaS cloud instances. In a Platform as a Service environment, storage supports existing code-based frameworks, web, and mobile applications; microservices; and serverless applications. Likewise, when the need is specific to dedicated or shared storage, virtual machines, or networks running on Windows or Linux, disk or file offerings should be considered. IaaS is synonymous with VM and virtual desktop appliances. Table 3-4 provides an overview of these storage types.

Table 3-4 Types of Storage in Microsoft Azure

On the exam, when it comes to storage-specific resources, you are only required to know about container (blob) storage, disk storage, and file storage. The section on database resources covers all content specific to table storage. Queue resources are not covered on the AZ-900 examination but covered here for the purposes of awareness.

Azure Container Storage

You may hear the phrases “container storage” and “blob storage” used interchangeably in the context of Microsoft Azure. A container is the organization of blobs or objects in a collection. Think of a container like a directory or file system with objects. When you create a storage account in Microsoft Azure, an unlimited number of containers can be created inside a storage account. The container can also store an unlimited number of blobs. With Azure, blob storage is optimized to handle unstructured data, or data that does not adhere to a specific format, such as you would find in a spreadsheet or a relational database table. When architecting storage design, consider blob storage when your organization is looking to save objects such as

•   Images and documents

•   Standard business productivity files

•   Multimedia files

•   Log files

•   Backup, disaster recovery, and archiving

A user can access blobs in a storage container using either HTTP/HTTPS, the Azure REST API, Azure PowerShell, Azure CLI, or through an Azure Storage client library. Supported languages include .NET, Java, Node.js, Python, Go, PHP, and Ruby.

Container storage consists of three components: the storage account, the container, and blobs. A storage account is a unique namespace where a user may place data in Azure. Regardless of what is stored in Azure, every object has a unique address associated with the storage account name. Combining the account name and the storage blob endpoint results in the final address where a user can access items in storage. If you were to name a storage account cloudcostorageact, the endpoint for the blob that all users would access online would be http://clourcostorageact.blob.core.windows.net.

A container is a way of organizing a blob. There are three types of blobs: block, append, and page blobs. Table 3-5 explains the differences among the three blob types.

Table 3-5 Types of Blob Storage

Once a user creates a blob, there is no way to change its type. You can only commit operational actions such as write or append to the blob. Blob changes are committed immediately. Every time a change is made, a version identifier, called an eTag, is associated with the blob. The eTag acts as a form of version control for a blob. As for duplicating blob data in its entirety, it is possible to create a complete duplicate of all blob types, also known as a snapshot, for the purposes of historical integrity.

Azure Disk Storage

Virtual machines on Azure require managed disks. In Azure, managed disks are block-level storage volumes that are fully managed by Microsoft Azure and used by a virtual machine infrastructure. Like an on-premises server, managed disks are virtualized or cloud-based. When you are ready to provision disk storage, the configuration requirements are standard, requiring the type of disk and size of disk. A user can select from a variety of disk types: ultra-disk, premium solid-state drive (SSD), standard SSD, and standard hard disk drive (HDD). Each disk type is aimed at a specific customer use case, as seen in Table 3-6.

Table 3-6 Comparison of Disk Types

Managed disks support 99.999 percent availability. Every managed disk type provides users the option of replicating data, which includes high durability. Should one disk fail, the remaining replicas offer persistency of data and tolerance of data failures. Managed disks in Microsoft Azure offer many benefits unique to virtual machine instances. Features to consider include

•   At-Scale Virtual Machine Instances With managed disks, you can currently create up to 50,000 virtual machine disks of a given type in a subscription per region. Additional growth is possible using virtual machine scale sets.

•   Integration with Availability Sets Managed disks are integrated in an Availability Set so that the disks are isolated from one another, which ensures operational failures are mitigated across multiple disks.

•   Integration with Availability Zones High-availability requirements are also necessary in some instances for managed disks. In those cases, managed-disk Availability Zone support is available. Because Availability Zones are specific to physical Azure regions, the data centers will be equipped with their own end-to-end infrastructure, not being reliant on another region. When resiliency is important with mission-critical data, three separate zones should be active in an enabled region.

•   Granular Access Managed disks support Azure role-based access control (RBAC), assigning specific permissions to a managed disk to one or more users to only allow specific operational activities such as to read, write, delete, and retrieve a shared access signature (SAS) for a given managed disk. You control the full range of roles and responsibilities a person can have access to when setting disk access.

•   Disk-Based Roles There are three main disk roles in Azure: the data disk, the OS disk, and the temporary disk. These can either be persistent for data disks; temporary and local, meaning not persistent; or local, but custom defined.

•   Encryption Two types of encryption are available for managed disks: server side and Azure Disk Encryption. Server-side encryption offers encryption at rest so that you can meet your organization’s security and compliance mandates. By default, server-side encryption is enabled for all managed disks, snapshots, and images, assuming support is available within the region for the disks. Azure Disk Encryption is specifically designed for IaaS virtual machines running OS and data disks.

Azure File Storage

For the small- to medium-sized business, or even personal user, having a robust Microsoft Azure account may be a bit much if the sole need is to have an affordable, simple way to securely store data in the cloud versus on-premises. It is not uncommon for organizations to want to shift their data from a data center to the cloud. Azure Files offers a fully managed file share service in the cloud using either the Server Message Block (SMB) or Network File System (NFS) protocol. Like computer hard drives, depending on the protocols, mounting options vary. Azure Files SMB support is available for Windows, Linus, and macOS, whereas NFS file support is limited to Linux and macOS. A key differentiation, though, is that with the SMB protocol on Windows servers, one can utilize Azure File Sync. Azure File shares can be mounted by clients in Azure Virtual Machines or from on-premises workstations. Businesses who are looking to sync and cache their files between an on-premises Windows server while maintaining local access will find Azure Files to be their best storage alternative.

Storage Tiers

Azure blob storage is a three-tier system: hot, cool, and archive. Each tier supports a different stage in the data lifecycle, offering a different price point and appropriate use case where storage should be used. Across all three storage tiers, 99.9 percent availability is guaranteed for the hot and cool tiers. The archive tier does not commit to a 99.9 percent guarantee. Similarly, when it comes to acquiring data from the moment a request is made, the hot tier and cool tier will respond in milliseconds. Because the archive tier data needs to rehydrate (access the data), it takes hours before the first bit of data will transfer from one system to another. Should you choose archive storage, another option to consider is the hydration period. Does your organization want to consider high-priority rehydration, which comes with a premium price tag, or standard rehydration? Table 3-7 illustrates the differences among the three tiers.

Table 3-7 Storage Tiers

To select the appropriate storage account tier for you, there are a number of factors to consider over the long-term horizon: expected storage growth, data access costs, transactional activity, geo-replication data transfer needs, outbound data, and anticipated access tier changes.

An Introduction to Database Resources

All Microsoft Azure database resources are Platform as a Service. There was once a time that Microsoft offered a desktop database (Access) and an enterprise-class database (SQL Server) only. Those days are long gone. Today, Microsoft, through its Azure platform, offers customers a suite of offerings. Azure options include a fully managed relational option, NoSQL, and in-memory database. These options include proprietary and open source alternatives too. Microsoft recognized that its customers’ needs vary, as the modern application developer has infrastructure management needs that do not fit a single profile. Scalability, availability, and security needs vary on a case-by-case basis. Table 3-8 compares key features among the different databases you will need to know for the AZ-900 exam. Databases that will not be discussed directly include SQL Elastic Pools, Virtual Clusters, Elastic Job Agencies, SQL Managed Instances, Data Factories, SQL Server Stretch Databases, and Azure Database Migration Services. While you may see references to Azure Synapse Database (formerly SQL Data Warehouse), you do not need to be familiar with the details in the context of the database, as we will discuss this in a later chapter.

Table 3-8 Select Azure Database Options

Azure SQL Database

Azure SQL Database is a PaaS offering. For nearly two decades, Microsoft has been a leader in relational database management technology with its popular enterprise SQL Server product. Now, the product is available for cloud consumption, not just for on-premises consumption. By having Microsoft fully manage the platform, all that a user is responsible for is data itself, not the maintenance of the infrastructure.

SQL Server databases are relational databases, although Microsoft does support nonrelational database solutions in Azure. What is the difference? A relational database is one that maintains a structure where data is organized in tables. Each of these tables has a relationship with one another, sharing at least one dependency. Nonrelational databases are document oriented and have no meaningful structure.

Relational Database Design in Azure SQL Server

With relational databases, a schema contains data that always maps to an ID. The ID number may be associated with a name, date, phone number, and e-mail address. Each time a new record is added to a table, there is consistency in that the schema must adhere to a structure. If the format of the data does not comply with the field structure, the schema will not accept the entry. A SQL Server database will often contain many tables related to one another. Using queries, a user can make a request to find a specific piece of data from one or more of those tables by joining related tables together. In Figure 3-25, you see there are two tables: Customer Table and Invoice Table.

Figure 3-24 Create Kubernetes Service interface

Figure 3-25 Example Relational Database Table

Notice that each customer has a unique Customer ID in the Customer Table that is mapped to the Invoice Table. The combination of these two columns is the relationship that binds the two tables together, creating a join. By placing the Customer ID in both tables, a user can query the database and identify information from both tables. Some fields may contain duplicate data, though. That is perfectly OK and to be expected. So long as the unique fields, the Customer ID (also known as the primary key) and the matching key in the Invoice Table (the foreign key), are unique, the system maintains its integrity.

Azure offers three deployment options: Single Database, Elastic Pools, and Managed Instances. Table 3-9 explains the differences between Single Database and Elastic Pools instances. The next section will elaborate on Managed Instances.

Table 3-9 Difference Between Single and Elastic Pool Databases

Azure SQL Databases are cloud-native stable versions of the Microsoft SQL Server database engine. When Microsoft releases new features for SQL Server, it will first release capabilities for the SQL Database and then for Server, which means you as a user get the latest enhancements without having to deal with any infrastructure overhead across any of your databases.

Not every organization needs to procure a SQL Server database infrastructure at the same size and scale. There are three distinct purchasing models to choose from: vCore, DTU, and serverless. All three options offer fully managed services with built-in high availability, backups, and maintenance operations. However, the way resources are allocated varies.

•   The vCore pricing allows for users to select the number of vCores (CPU), memory, speed, and storage. Users are also able to select if they want to utilize Azure Hybrid Benefits to recognize costs savings should they decide to procure SQL Server for a long-term commitment. vCore is best suited for extensive workload capacity.

•   DTU pricing provides users a more affordable approach to the three Azure Service tiers: compute, memory, and I/O resources. Each tier provides a different mix of resources to best fit your technical profile needs. DTU is best suited for scalable database needs.

•   Serverless pricing is only appropriate under certain conditions. The serverless model will scale compute capability based on workload demand. You are billed only for compute capacity used per second. When the database is not in use and is paused—hence a state of inactivity—you are not charged. However, if any processes are running, even one, you will be charged. Consider the following, though: the serverless compute tier can automatically pause databases during periods when your storage is billed but the database is inactive. That means if the database is inactive but other forms of storage are being used, you will not be charged twice.

You may already notice that determining how pricing and availability for a database service is configured can be quite complex. One last element for Microsoft Azure SQL is service tiers. There are three tiers available that can greatly affect the pricing of your database deployment. The service tiers are

•   General Purpose/Standard Intended for common workloads. These are most appropriate for lightweight compute and storage needs where the specific focus is dev/test, not production-sensitive needs.

•   Business Critical/Premium Intended for online transactional processing (OLTP) applications with high-volume activities and low-latency input/output (I/O) rates. This service class offers high resilience by utilizing replica isolation.

•   Hyperscale Designed exclusively for massive OLTP database processing with autoscaling fluid storage and compute capacity. Hyperscale is not available for managed instances currently.

Azure SQL Database offers many other advanced features, which you are not required to know for this exam, such as extensive monitoring and alerting, availability support, built-in intelligence, automatic performance monitoring and tuning, advanced security and compliance, native threat protection, data encryption, auditing, advanced querying processing tools, and a bevy of integration tools. Should you want to explore further, consider evaluating the course curriculum for the DP-300 exam Administering Relational Databases on Microsoft Azure.

Azure SQL Database Managed Instances

With so many database vendors on the market today, it is not uncommon when an organization decides to move its workload to the cloud that it also requires a migration strategy for its database environments. For those customers that require a straightforward migration from an on-premises or third-party environment to Azure, they can select an Azure SQL Database managed instance. These are database instances that are fully compatible with SQL Server on-premises. Since the objective is to integrate with an isolated VNet, which also has a private IP address, your database server will be able to connect to the Azure VNet without much effort. Minimal configuration is required to lift and shift databases to Azure. As noted earlier, managed instances are only supported at the General Purpose and Business Critical service tiers.

Azure Database for MySQL

Azure Database for MySQL has adopted the relational database capabilities of the open source MySQL community offerings. Like other database services, Azure Database for MySQL is a PaaS-based offering. There are two Azure Database for MySQL offerings: Single Server or Flexible. The two offering types are described in Table 3-10.

Table 3-10 Azure Database for MySQL Offering Types

Both are fully managed Database as a Service offerings that can handle mission-critical workloads. Managed databases also offer predictable performance and dynamic scalability with key security and management control differences. Both offerings are currently based on the MySQL Community Edition (available under the GPLv2 License) database engine. Three different versions are available under the current community edition: 5.6, 5.7, and 8.0.

Azure Database for PostgreSQL

Azure Database for PostgreSQL is another Azure relational database PaaS-based option. The open source database system was originally available for those needing database support on Unix or Linux environments. However, given the combination of being able to implement the database using virtualization, as well as the growing open source community, platforms such as macOS, Linux, OpenBSD, and Windows can now take advantage of utilizing the relational database platform. PostgreSQL is an enterprise-class database solution, as it supports complex operations where many users are involved.

The most significant difference between standalone PostgreSQL and Azure Database for PostgreSQL is that Azure Database for PostgreSQL is managed. Azure manages the database for the user without them having to worry about the server, database security, and core administrative tasks. Azure Database for PostgreSQL supports high availability for strong scalability with 99.99 percent SLA support. Consistent with other Azure relational databases, you have the choice of single-zone or zone-redundant high availability to ensure performance optimization and advanced security. Pricing is in line with other relational database solutions in the Azure database portfolio. There are options for Basic, General Purpose, and Memory Optimize options, which means if you add CPU, memory, or storage capacity, your price will increase.

Azure Cosmos DB

Azure offers both relational and nonrelational database options. Azure Cosmos DB is a globally distributed, multimodal nonrelational (NoSQL) data alternative for data management and application development. Users can elastically scale an instance based on throughput and storage across one or more Azure regions worldwide. One of the features that make Azure Cosmos DB stand out is its fast single-digit-millisecond data access performance. The platform works across numerous popular APIs, such as MongoDB and Cassandra. Microsoft’s expansive service-level agreement, with a guaranteed 99.999 percent availability for Azure Cosmos DB, ensures an organization that throughput for latency, availability, and consistency affords automatic and instant scalability.

Unlike other database alternatives offered by Microsoft Azure, Cosmos DB supports schema-less data, because a NoSQL database does not require a relational database design. At the same time, you can build a highly responsive, always-available application to manage highly dynamic data that is stored in the database, which can be updated and maintained by one or more users anywhere around the world. Since Cosmos DB is distributed, data storage is possible across one or more regions.

When you deploy Azure Cosmos DB, you will be asked to configure parameters that will determine performance metrics such as speed, development readiness, service-level agreement terms, and your preferred deployment topology. In Table 3-11, specific parameters are identified.

Table 3-11 Azure Cosmos DB Features

An Introduction to Networking Resources

Azure core networking services offer numerous capabilities that can be utilized independently or concurrently. For the AZ-900 exam, Microsoft core network resources are limited to connectivity services, which consist of connecting Azure resources and on-premises resources to Azure features such as Virtual Network (VNet), VPN Gateway, Peering Services, and ExpressRoute. While there are other services in the Microsoft Azure connectivity catalog, those are not covered on the exam. In later chapters, you will learn about other areas of networking connectivity, such as application protection, application delivery, and network monitoring. Each of these areas play an integral role in securing, managing, and fortifying the IaaS and PaaS backbone for Microsoft Azure.

Azure Virtual Network

Azure Virtual Network, commonly referred to as VNet, is the building block to any private network in Microsoft Azure. A VNet enables many Azure resource types. Whether it is Azure Virtual Machines, which can communicate with one another, creating connections to the Internet, or supporting connections to on-premises networks for hybrid connectivity, VNet mirrors traditional network connectivity, which you would expect to operate in a data center environment. The only difference is that Microsoft handles operational maintenance activities such as scale and availability versus the organization being responsible for these tasks. Table 3-12 explores the different communication options a user has with Azure Virtual Network.

Table 3-12 Connectivity Options for Virtual Networks

To optimize network traffic, you may want to filter network traffic using specific virtual network options, such as network security groups or network virtual appliances. With network security groups, your security groups can contain multiple inbound and outbound security rules, allowing you to filter traffic to and from resources. Filtering occurs by source and destination IP address, port, or protocol. On the other hand, network virtual appliances are virtual machines that perform the network function itself, which may include a firewall.

VPN Gateways

At some point, you will need to connect your VNet to another network, whether it is in Azure or elsewhere. It could be on-premises or within an Azure cloud instance. Under any condition, you will need to have a mechanism that allows you to connect over the Internet. To ensure your data is secure, you and your organization should establish a virtual private network (VPN) connection.

Fundamentally, a VPN is a network technology that allows connectivity between a private network and a public network. For example, if you have ever connected to resources on your company’s private network from your home computer, you have likely used a VPN connection that allows your home network to connect to your company’s network.

Taking it one step further, a virtual network gateway consists of two or more virtual machines (VMs) deployed to a specific subnet. You connect the subnet to a gateway subnet. Each time you create a virtual network gateway, your instance will be associated with routing tables and run specific gateway services. By default, you are not able to configure a virtual machine that is part of a virtual network gateway.

You must configure a virtual network gateway to a specific type of virtual network. The gateway type determines how the gateway will be used and what actions will be taken. For example, you may have the type “VPN” for a virtual network. This can be distinguished from an ExpressRoute gateway, which uses a different gateway type.

Creating a virtual network gateway cannot be completed quickly, as it can take up to an hour to complete, depending on the compute resources associated with your instance configuration. Depending on the conditions you establish your virtual network gateway under, gateway virtual machine instances are deployable to a gateway subnet and will be configured with specific settings. Upon initiating the VPN gateway creation process, you will be able to create different tunnel types, including IPsec/IKE between the VPN gateway and another VPN gateway (such as VNET-to-VNET), or create a cross-premises IPsec/IKE VPN tunnel connection between the VPN gateway and your on-premises VPN devices, which are site to site. Other options may include creating a point-to-site VPN connection using Open VPN, IKEv2, or Secure Socket Tunneling Protocol (SSTP), which allows you to connect to a virtual network from any remote location.

Security and encryption are other critical aspects of VPN gateways that should be addressed. A virtual network gateway is used to send encrypted traffic to and from Azure networks and on-premises locations over the public Internet. You can also use a VPN gateway to send your encrypted traffic between Azure virtual networks over the Microsoft network. Each virtual network is limited to a single VPN gateway, although it is possible to create multiple connections to the same VPN gateway. A rule of thumb is that when creating multiple connections to the same VPN gateway, your VPN tunnels will need to share the available gateway bandwidth.

Virtual Network Peering

Another situation you may encounter is when you need to connect virtual networks with one another. Azure virtual network peering does just that. Once connected, the virtual networks appear as one connected network. Traffic between the two virtual machines is routed through Microsoft’s network infrastructure using a dedicated IP address. Virtual peering allows for connections across Azure regions, also known as global peering.

There are distinct benefits to using virtual network peering, either in a local or global configuration:

•   Peering offers low-latency, high-bandwidth connectivity between resources within different virtual networks.

•   You can use resources for one virtual network to communicate with resources in another virtual network.

•   You can transfer data between virtual networks across Azure subscriptions, including Azure Active Directory tenants, deployments models, and regions.

•   You can peer virtual networks using Azure Resource Manager.

•   You can peer a virtual network through Resource Manager to one using a deployment model.

•   You should not experience downtime with virtual networks when creating any peering resources, even after peering is created.

When traffic is between peered virtual network resources, it remains private. The traffic between the virtual private network will be kept on the Microsoft backbone network. Therefore, no public Internet gateway or encryption is necessary to communicate for any virtual network.

Configuring a Virtual Peering Network

To configure a virtual peering network, you must have a virtual network established already (Figure 3-26).

Figure 3-26 Virtual private network setup interface

You connect two VNets using the virtual network peering options by opening the Virtual Network interface. Then select Peerings (Figure 3-27) on the Azure menu panel. Once you select Peerings, the next page will ask you to click +Add on the right menu panel. Click +Add to add a virtual network peering connection (Figure 3-28).

Figure 3-27 Virtual network page with Peerings menu

Figure 3-28 Adding a Peerings menu option

You will fill in the necessary fields on the virtual network peering interface form on the Add Peering page to configure the VNet between the existing VNet and the new VNet you are about to create. Once all fields are filled in, click OK. You will be taken to a list of all available virtual peering network connections currently established (Figure 3-29).

Figure 3-29 Virtual peering networks listing

Azure ExpressRoute

Ever know of an organization to complain about connectivity between their on-premises network to their cloud service provider? This problem is all too common. Microsoft recognized this issue with many of its enterprise clients who maintain a hybrid footprint whereby they needed to extend the network connectivity from an on-premises network into the Microsoft cloud data centers using a private connection. The solution is called Azure ExpressRoute. Users can establish connections between Microsoft cloud services such as Azure and Microsoft 365 to the on-premises environments and gain tremendous performance enhancements.

With ExpressRoute, you can connect from any IP VPN network using a connectivity provider via colocation. Since ExpressRoute connections are not bound to the public Internet, they are more reliable, provide more consistent speed, have minimal latency, and provide a greater tendency for hardened security.

Edge connectivity is established between your on-premises network to a Microsoft Enterprise Edge router (MSEE) with ExpressRoute. In most instances, the connection within the organizational data center is also edge-bound within the on-premises data center.

ExpressRoute Direct

A bit different from ExpressRoute is Azure ExpressRoute Direct because customers are given the opportunity to connect directly to Microsoft’s global network using peering locations. Such locations are distributed worldwide. Users are provided with dual 100-Gbps connectivity, allowing for active-active connections. You would choose ExpressRoute Direct if you were looking for massive data ingest into services like data-related storage, require physical isolation for cloud services because of regulation (e.g., banking, government, health care, insurance), or must have granular control over circuit distribution within a business.

Of all the differentiators, the most significant between ExpressRoute and ExpressRoute Direct is the options associated with the acquisition and consumption of bandwidth. With both ExpressRoute products, you can purchase circuits ranging from 50 Mbps to 10 Gbps. Connectivity, however, is dependent on what your hosting provider can support. Circuit bandwidth can increase and decrease fluidly without having to re-engineer your network connection. Also, given the unpredictability of data transfer and activity in an organization, Microsoft offers two primary billing models: Unlimited data, where you are charged a monthly fee based on bandwidth. For that scenario, inbound/output data transfer costs are inclusive. A second option is metered data charges. For this use case, while inbound data transfer is free, outbound data charges accumulate per GB. Data rates vary by region.

Azure Marketplace

In Chapter 2, you were briefly introduced to Azure Marketplace. This section covers Marketplace from a compute resource point of view. The Microsoft Azure Marketplace is an online store containing thousands of IT software applications and services that are distributed from third-party cloud service providers and Microsoft. In the Marketplace, there are many free application offerings, while other times, there are offers to find, try, and buy. Regardless of whether the offer is free or requires a paid subscription, you will still need to pay for the underlying infrastructure, which includes the storage capacity to host the service offering found in the Marketplace. The Marketplace offerings are not just limited to SaaS-, IaaS-, and PaaS- based options that are industry and technical area specific; you can also establish consulting relationships with Microsoft Solution Partners.

To provision a service offering from the Azure Marketplace, whether it is free or requires a subscription, you must have an active Azure subscription tied to a payment method. Customers can either pay using their credit card (under the pay-as-you-go plan) or utilize an invoice with an existing Microsoft purchasing agreement.

Figure 3-30 presents you with a list of offerings when a user clicks the Web navigation option Web on the left-hand side. Azure Marketplace breaks down the various product categories for ease of searchability. Users can also use the search option where it says Search The Marketplace to find a product or service offering, should it be available in the Marketplace.

Figure 3-30 Reviewing all results under a category in the Azure Marketplace

Chapter Review

Chapter 3 covers the requisite knowledge to cap off topics pertaining to Azure compute resources. While not every compute capability is covered in the chapter per the Microsoft AZ-900 exam guidelines, the underlying infrastructure and networking specifics are quite robust. The chapter starts with an extended discussion on Azure Virtual Machines, an Infrastructure as a Service offering. Virtual machines (VMs) allow a user to manage the operating system configuration. Should a user need to protect their VM infrastructure, they have the option of utilizing Availability Sets with fault domains or update domains. Fault domains protect a virtual machine from a hardware failure, whereas an update domain provides protection from unexpected reboots. Should you need to expand the capacity of a virtual machine, consider using a scale set to autoscale a virtual machine instance horizontally.

Not every compute solution will require a user to manage the operating system and underlying infrastructure. For those looking to have Microsoft Azure manage the infrastructure on their behalf and simply host a web application, which is a Platform as a Service application, you would use Azure App Service. There are two options for running Azure App Service. You can have Service apps, which run inside an App Service plan. Based on the service plan, a specific number of virtual machines can operate following a set configuration. A second option is the use of containers. Containers allow one to create a virtual machine image of an application. The image would run inside the container as needed, resulting in a significantly lower operational cost compared to a virtual machine instance. When there is a need to manage several virtual machine instances without user intervention, Azure Kubernetes Service makes it easy to host a virtual machine cluster in the cloud. Another PaaS-based infrastructure option that Microsoft expects learners to know about covered in this chapter is Windows Virtual Desktop, which allows users to access all applications, including a complete operating system, using the Internet instead of a desktop from any device.

A common requirement for any infrastructure solution is storage. Azure has a variety of storage types. Key storage types covered include

•   Blob storage Ideal for unstructured data, including binary files.

•   Disk storage Appropriate if you are looking for a solution that acts as a replacement virtual disk.

•   File storage Allows you to have cloud-based storage for files you would likely have on your desktop otherwise.

Of all the storage types covered, the most prominent is blob, as it is heavily leveraged in PaaS applications, which include Frameworks web and mobile applications, microservices, and serverless applications. It can also be used as part of database application storage. There are three tiers of blob storage: hot, cool, and archive. Blob storage tiers are based on how long you intend to store and access the data.

Completing the discussion on storage options is an extensive review of database alternatives. While the exam does not require you to be familiar with every database alternative in the Azure platform, it does focus on key Microsoft, relational open source, and unstructured options. Microsoft has taken its flagship SQL Server product and enabled it for the cloud by creating Azure SQL Database and a managed instance version. Azure also introduced two popular open source database platforms as managed services: Azure Database for MySQL (based on the Community Edition of MySQL database) and Azure Database for PostgreSQL for hosting the PostgreSQL database. Microsoft has also placed significant emphasis on Azure Cosmos DB, its NoSQL database solution for unstructured data. All database solutions, unless hosted within a virtual machine environment, are considered Platform as a Service offerings in Azure.

The latter half of the chapter covers networking resources. The building blocks of Azure networking is Azure Virtual Network (VNet), which allows Azure to communicate with each other and the Internet. Users can add a public IP address to support inbound Internet connectivity, which can be useful if a website runs your VNet and you want users to access it publicly. When users require encrypted connections between Azure Virtual Network connections, be it between one another or on-premises, an Azure VPN gateway should be considered. Furthermore, if a user requires that the distribution of traffic be balanced across multiple virtual machine instances, one should use Azure Load Balancer. To configure two VNet connections to optimize communication, there are several options to consider. There is site-to-site, point-to-site, and VNet-to-VNet connectivity. When you are looking to connect two or more Azure VNets to each other without restricting bandwidth, the best option is to utilize virtual network peering. A final solution that is unique to those that require high-bandwidth connections to Azure of up to 10 Gbps using a Microsoft Enterprise edge (MSEE) router is ExpressRoute. ExpressRoute offers network connectivity to internal-facing traffic only.

The chapter concludes by reviewing the Azure Marketplace. Marketplace can help you find compute-based templates for creating infrastructure and networking resources. Users can access Marketplace using the Azure Portal or directly the from Azure Marketplace website over the Internet. Some of the templates available in the Marketplace are created by Microsoft, while others are created by third-party solution partners. Regardless of who creates the templates and whether the resource is free or not, all Marketplace resources require a user have an active account to provision any service functionality. As Azure becomes more pervasive and integrates more capabilities, both within the Microsoft suite of products and that of third-party tools, such interfaces and integrations may change.

Questions

1.   Review the following scenario and select the most appropriate response.

A virtual machine, which is a Platform as a Service offering, requires end-user maintenance and support for specific operating system features and functions.

A.   Infrastructure as a Service

B.   Platform as a Service

C.   Software as a Service

D.   No correction required

2.   Indicate if the following statements are true or false.

A.   True, False, False

B.   False, False, False

C.   True, True, False

D.   False, False, True

3.   Indicate if the following statements are true or false.

A.   False, False, True

B.   False, False, False

C.   True, False, False

D.   True, False, True

4.   Which of the following is a PaaS-based nonrelational Azure Database offering?

A.   Azure Database for PostgreSQL

B.   Azure Database for MySQL

C.   Azure Cosmos DB

D.   Azure SQL Server Managed Instances

5.   When you are looking to implement a development virtual machine instance with excess storage in a particular region at a significantly reduced rate, what would you need to select during the configuration process of your virtual machine instances?

A.   Snapshots

B.   Images

C.   Scale sets

D.   Spot instances

6.   You recently received an invoice from Microsoft indicating 720 hours of virtual machine usage. You were surprised, considering you only accessed the virtual machine twice the entire month. To avoid being charged for unnecessary usage, what must you do?

A.   Delete the VM each time you no longer need to use it.

B.   This must be an error. Request a refund.

C.   Stop the virtual machine instance.

D.   Select a different image from the Azure Marketplace.

7.   Which of the following describes a virtual machine that can be deployed across multiple update and fault domains to maximize availability, which also ensures resiliency due to data center outages and unplanned maintenance events.

A.   Availability Zone

B.   Scale sets

C.   Virtual networks

D.   Virtual network gateways

8.   Which of the following is not a configuration you must identify when setting up an app service plan?

A.   Region

B.   Number of virtual machines

C.   Size of instance

D.   SDK support

9.   Which of the following are open source relational database platforms that Microsoft Azure supports as managed service offerings? (Select two.)

A.   Azure Database for PostgreSQL

B.   Azure Cosmos DB

C.   Azure SQL DB

D.   Azure Database for MySQL

10.   Your organization requires a managed solution that can support its massive online transactional processing database solution. To ensure optimal performance, your team requires a solution that supports applications with high volume activities and low input/output rates. Autoscaling and fluid storage capacity are desired. Which service tier should you select?

A.   General

B.   Business Critical

C.   Hyperscale

D.   Free

11.   Review the following scenario and select the most appropriate response.

You must store data in storage for three years. Each year, you may need to access the data from cool storage from the previous year.

A.   No changes are necessary

B.   Hot storage

C.   Archive storage

D.   Database storage

12.   You have a website with light traffic. Which type of disk storage is appropriate?

A.   Ultra Disk

B.   Premium SSD

C.   Standard SSD

D.   Standard HDD

13.   There are three types of blobs, also referred to as containers. Which of the following is not one of those types?

A.   File blob

B.   Append blob

C.   Page blob

D.   Block blob

14.   What are the differences between virtual machines and Azure Container Instances? (Select two.)

A.   Cost

B.   Resource allocation

C.   Disk type

D.   Operating system

15.   You need to deploy an Azure virtual machine running Windows 2019. You need to ensure that the services running on the virtual machine are available if one of the assigned data centers fails. You deploy the virtual machines to two Availability Zones. Does that meet the goal?

A.   Yes

B.   No

Answers

1.   A. A virtual machine is an Infrastructure as a Service offering. End-user maintenance and system support are required to continue to provide end-user support.

2.   C. True. To utilize any Microsoft Azure Marketplace offering, even if it is free, you must install and configure the offering on an active account.

True. Even if a virtual machine provided by a Microsoft Solutions Partner is provided complimentary, you must pay for the underlying storage infrastructure the virtual machine instance runs on.

False. You can access the Azure Marketplace from the Azure Portal as well as from https://azuremarketplace.microsoft.com.

3.   A. False. Azure virtual network peering connects two Azure virtual networks together.

False. ExpressRoute Direct, not ExpressRoute, is best suited for customers looking for networking data connections that support massive data ingest into services like data-related storage and that require physical isolation for cloud services because of regulations.

True. As a type of virtual network, a point-to-site network (VPN) represents a connection between a virtual network and a single computer.

4.   C. Azure Cosmos DB is a NoSQL, nonrelational, PaaS-based Azure Database offering.

5.   D. An Azure spot instance allows you to run a cost-optimized virtual machine in Azure when excess capacity is available in a particular region. Once capacity is no longer available, the instance is deallocated.

6.   C. You will always pay for storage, as it is an underlying condition for managing a virtual infrastructure. That said, you kept the virtual infrastructure running, hence the excess operational costs.

7.   B. A scale set is a virtual machine that can be deployed across multiple update and fault domains to maximize availability, which also ensures resiliency due to data center outages and unplanned maintenance events.

8.   D. Except for SDK support, which is not a legitimate feature, all other choices are prerequisites for configuring an app service plan.

9.   A, D. Azure Database for PostgreSQL and Azure Database for MySQL are both open source relational databases that Microsoft has enabled as a Platform as a Service offering in Azure.

10.   B. Although you might expect the answer to be Hyperscale (C), based on the massive OLTP requirement, Hyperscale support does not align with managed instance support at this time. Business Critical/Premium Support does offer OLTP benefits for massive data processing.

11.   C. Archive is appropriate under these conditions because the storage access will be limited to yearly. This is the cheapest access, given that the user will not access the data for a minimum of 180 days to maintain pricing.

12.   C. While all storage types can be used for web storage, the most appropriate is Standard SSD. Standard SSD is appropriate for backup, recovery, and noncritical storage and is also useful for web servers, lightly used applications, and web-based applications.

13.   A. File blob is not an actual file type.

14.   A, B. By default, disk type and operating systems are two resource types that are allocatable. Therefore, cost and resource allocation are the correct answers.

15.   A. Yes. There is redundancy from one data center to the next, given system protection, should one data center fail. The use case presented provides ample assurances.