If you would like to follow along with the examples in this chapter, you will require the following (later chapters will have these requirements as well):

• A Microsoft Azure subscription: If you don’t already have a subscription to use, you can set up an account for free here: https://azure.microsoft.com/free/
• The Az PowerShell module: Instructions can be found here: https://docs.microsoft.com/powershell/azure/install-az-ps
• The Azure CLI: Instructions can be found here: https://docs.microsoft.com/cli/azure/install-azure-cli
• A Windows, macOS, or Linux device with the latest version of PowerShell installed: Installation information can be found here: https://docs.microsoft.com/powershell/scripting/install/installing-powershell
• A supported web browser: Supported browsers can be found here: https://docs.microsoft.com/azure/azure-portal/azure-portal-supported-browsers-devices

Code in Action videos for this chapter: https://bit.ly/3qOiMgC

Important Note

Whether you intend to use an Azure account with free Azure credit or not, you are responsible for monitoring and managing your account. If you are going to follow along with the hands-on exercises throughout this book, you need to understand potential costs and monitor your usage and budget responsibly. Consumption models are great, but if you create resources and leave them running 24/7, for example, the costs will soon start adding up – make sure you keep on top of any costs you may incur from following the exercises in this book.

Before cloud computing became an option, companies would have physical network components and server hardware to host roles that would allow them to manage identity, storage, databases, and web applications, among others. Each of these would need skills and cost to install, configure, maintain, patch, and eventually upgrade.

If there was a sudden rise in web requests to one of your web servers, for example, you may have had a drop in service availability because your hardware lacks the resources required. If you predicted the sudden rise, perhaps due to seasonal patterns, you may have gone through a capital expenditure (CapEx) process. Once (if) approvals are obtained and everything gets set up, if the actual traffic isn’t what was forecast, or once the traffic drops again, you might be stuck with expensive hardware that isn’t being fully utilized, while still having ongoing running and maintenance costs (as well as potentially grumpy financial controllers!). This alone presented a problem, and we’re not even touching on disaster recovery or high availability requirements.

Enter cloud computing…

Perhaps the most noticeable change when a company moves to a cloud-based infrastructure is that the requirement to have many physical components is greatly reduced. Identity management can be achieved without a single physical server for you to manage – just log in to a web portal and do everything from there. Users no longer need to be connected directly to your internal network for secure connectivity.

Depending on the service-level agreement (SLA) you have with your cloud provider, even when something goes wrong, the cloud infrastructure can help keep your applications highly available with no noticeable downtime. With the previous scenario of a sudden rise in web requests, you may have decided to scale your application vertically (also known as scaling up/down), providing it with more resources, but that often results in some downtime while the application is upgraded.

You could have configured automatic horizontal scaling (also known as scaling in/out) – if your application hits a certain metric, more instances of your application could be automatically created to handle the spike, and the number of instances could be scaled back down automatically once demand reduces again – preventing any downtime while being cost-effective.

To demonstrate this, I created a web app in Microsoft Azure that only took 30 seconds to create and be up and running, and then configured auto-scaling. When monitoring the instances of my web app, there was a spike in the number of requests (the lower line) over a period, the instances (the upper line) increased to 2, and once that spike subsided, the instances were reduced to 1:

Figure 1.1 – Auto scaled instances during a requests spike

Due to the elasticity that cloud computing brings, my application had the resources it needed without any downtime and scaled the resources back down when they were no longer needed. I mentioned that I was able to provision my web app and have it accessible to the internet in just 30 seconds – no CapEx, no hardware, no delays, and no complications. I had the option to deploy the app to one of many locations around the world, thanks to the global distribution of my cloud provider’s data centers.

With cloud computing, you not only have all the benefits mentioned here and more, but because cloud services are typically consumption-based, you only pay for the resources you use. No upfront costs, just operational expenditure (OpEx) costs, depending on what you use. To some, one of the biggest benefits of cloud computing is that you no longer need to deal with quite as much of an Ethernet jungle as before. As this chapter is intended to recap these fundamentals, we won’t delve any deeper at this time.

With the benefits just covered and many others, it’s no surprise that the number of workloads being migrated to the cloud is increasing exponentially. When thinking about moving workloads to the cloud, it’s important to understand the hosting options available to you, the most common of which we will cover in the next section.

There are three main types of cloud deployment models available from cloud providers: public cloud, private cloud, and hybrid cloud (other cloud models exist, such as Community Cloud, but we won’t discuss those other models here). Here is a summary of these models:

• Public cloud:
  • This is the most common model and where services and resources are offered over the public internet to anybody that wishes to purchase them. All cloud resources are owned and maintained by a cloud provider, so it’s more like renting resources than purchasing them.
  • Pay only for what you use with a consumption-based model.
  • The cloud provider handles maintaining and updating the hardware.
• Private cloud:
  • Unlike the public model, services and resources are available exclusively for one organization. Often, this model is chosen when strict security controls and isolation are required.
  • Hardware, software, configuration, maintenance, updates, and security are all managed by the organization exclusively using the available resources.
  • Hardware needs to be purchased and all running costs fall to the organization if the hardware is running, even if resources aren’t being used.
• Hybrid cloud:
  • You can compose public and private cloud models, taking advantage of the benefits of each.
  • Flexibility to store sensitive information on private resources, while allowing interconnection to an application on the public cloud, for example.
  • Ability to decide where to host workloads, depending on the requirements.

It’s important to note that although a private cloud may be required to meet certain regulatory standards, public clouds are often more than secure enough for most scenarios. The physical data centers hosting cloud hardware follow strict security controls that comply with many external regulations, as well as bring the benefits of availability and redundancy.

The security features available from cloud providers are comprehensive, industry-leading, and often offer better protection, monitoring, alerting, and remediation than most organizations achieve when they manage their resources. Unless otherwise stated, this book will be assuming that the public cloud is the chosen model (which is the most common by far).

Now that we understand the main cloud deployment models, of which the public cloud is the most common, we should discuss the service models available. You will encounter the models we are about to cover numerous times if you haven’t already, and every service you deploy in Azure will come under one of these models.

No cloud computing discussion would be complete without mentioning Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). Although other cloud service models exist, these are the most common cloud models offered by cloud providers and are the standard models per the National Institute of Standards and Technology (NIST). Let’s briefly recap these models before we get into Azure specifics:

• Infrastructure as a Service (IaaS):
  • As the name suggests, with this model, the cloud provider manages the underlying infrastructure. One of the most common examples of this implementation is cloud-based virtual machines – you can request virtual machines with certain specifications and the cloud provider has automation take care of provisioning them for you. You don’t need to worry about the underlying host or infrastructure. You will manage the virtual machine, including installing software, updates, and more.
  • This is the closest model to managing physical machines, without needing to manage any hardware. Provisioning virtual machines is much faster than having to procure and set up physical machines – as is scaling and removing them. You get the most flexibility and control with this model.
  • With the consumption-based model, you only pay for the resources you use (OpEx). For example, if you have a virtual machine and enable daily auto-shutdown, automation will take care of shutting the machine down each day at the desired time, allowing the machine to be stopped and deallocated, at which point the virtual machine itself no longer incurs any costs until it’s started again (other resources attached to the virtual machine may still incur separate costs).
• Platform as a Service (PaaS):
  • From a developer’s perspective, this is becoming the most popular model. With this model, developers can deploy their applications to a managed hosting environment.
  • The cloud provider manages all the underlying hardware and infrastructure as with IaaS, but with PaaS, they also manage any virtual machines, the operating systems, patching, and more. You, as a developer, just manage the application, along with the data and access to it.
  • The consumption-based model makes this a cost-effective model. Being able to provision an environment where you can host your application quickly, deploy and test your application, then potentially remove the environment (an Azure App Service, for example) without needing to worry about any of the details of the machines on which this environment is hosted greatly improves developer agility.
• Software as a Service (SaaS):
  • With this model, the cloud provider provides you with the software. You just manage who can use the software and which features.
  • One of the most common Microsoft-hosted examples of SaaS is Microsoft 365, which includes applications from what was previously called Office 365 – you are provided with the software; you just need to define who can access what features. The cloud provider handles everything else.
  • Typically, this is a pay-as-you-go model – monthly or annually, regardless of how much the software is used. The software is provided as-is. Because you don’t manage the software, if features of the software have limitations, you don’t have control over these features, unlike if you were managing the software itself.

The following diagram shows the service models compared to on-premises, showing which aspects you manage in each. There are many similar illustrations of this all over the internet, so you will have likely come across something similar at some point:

Figure 1.2 – Illustration of the different cloud service models and management responsibility

Increasing numbers of applications are being redesigned for hosting on PaaS services, allowing developers to focus on developing and have the infrastructure details not be a concern, greatly improving developer velocity. Whether that is the design decision or not, it’s important to understand the different options available. Now that we’ve had a recap of some cloud fundamentals, it’s time to start delving into Azure specifics.

Microsoft Azure is Microsoft’s globally distributed cloud platform and provides over 200 products and services, covering all the service models previously discussed – from virtual machines to cognitive services. Managing all your services and subscriptions can be done through the Azure portal, which can be accessed via https://portal.azure.com. The portal isn’t the only option – Azure also offers a comprehensive API and CLI, both of which will be explored throughout this book. There is also a marketplace where Microsoft partners, independent software vendors (ISVs), and startups can offer their solutions and services that have been optimized to run on Azure.

Azure’s giant of an identity platform is known as Azure Active Directory (AAD), which will be referred to throughout this book many times. At no point will we be covering all aspects of AAD in depth – only the areas that are relevant to this exam. Subscriptions provide you with access to Azure products and services. Companies can have multiple subscriptions, allowing for a separation of billing and access control, as well as management groups that group together multiple subscriptions. Within those subscriptions, you can create your resources, grouped into resource groups (discussed shortly).

Regions and availability zones

When you create a resource in Azure, you often need to specify the region in which to create the resource. As potentially heartbreaking as “there is no cloud, it’s just someone else’s computer” might be, this phrase and others similar have become popular in recent years, and we covered the meaning behind it previously. With Azure consisting of a global network of data centers around the world, you have the flexibility to select the region in which the data center hardware that will host your service is located.

So, what is an Azure region? A region is a geographical area within which one or more (usually more) Azure data centers reside, connected through a dedicated regional low-latency network. With data centers being grouped within a latency-defined perimeter (of less than 2 milliseconds), Azure ensures that workloads are balanced between them appropriately. Note that some services are only available in certain Azure regions. Regions allow you to create your resources as close as possible to you or your users, as well as cater to data residency requirements you might have. There are special Azure regions that have been created for certain government bodies, keeping them isolated from the public infrastructure.

Availability zones consist of one or more physically separate data centers within the same Azure region, connected through high-speed fiber-optic networks, with independent power, cooling, and networking. If one availability zone goes down, the other continues to operate. There are a minimum of three zones within a single region. Depending on the region and service, you may be able to select whether your data is replicated across the same zone, other zones within the same region, or another region entirely. There is plenty of documentation available out there, should you wish to read more on this topic. For this recap, we have gone into enough detail for now.

When it comes to the deployment and management of Azure resources, a topic you must understand is Azure Resource Manager.

Azure Resource Manager

Before Azure Resource Manager (ARM) was introduced in 2014, resources were deployed and managed using Azure Service Manager (ASM). With ASM, all resources were deployed and managed individually – if you wanted to manage resources together according to your application life cycle, for example, you would need to create scripts to do so.

In 2014, Microsoft introduced ARM, adding the concept of a resource group. Resource groups are units of management for your logically related resources. With ARM, all resources must be a member of a resource group, and only one, although supported resources can be moved between resource groups.

Resource groups provide a logical grouping of resources, so you can organize resources that share the same life cycle into a resource group. When the time comes to remove said resources, you can remove the resource group, which will remove all those related resources. Resource groups can also be used as a scope for applying role-based access control (RBAC) – so accounts that need access to resources within a resource group can be provided with access at the resource group level, without needing permissions to all other resources/resource groups, or at a higher level, such as the subscription level.

One organizational concept I’ll mention here is tags. While resource groups are great for organizing and grouping resources, their organizational usefulness has limits, especially when a resource can only be a member of one resource group at a time. Tags can be added to resources for additional organization and categorization.

Tags work as name-value pairs and can be used however you see fit – perhaps for a cost center, an environment, department, classification, or any other purpose (see the Recommended content section of the Cloud Adoption Framework guide, which contains guides on tagging decisions). At the time of writing, supported resources can have as many as 50 tags, with tag names limited to 512 characters (storage account tag names are an exception, where the limit is 128 characters) and tag values limited to 256 characters.

Any request – be it from the Azure portal, Azure PowerShell, the Azure CLI, SDKs, or REST clients – is received by ARM, which will then authenticate and authorize the request before sending the request to the Azure service. All methods, including via the portal, make use of the same ARM REST APIs – you just can’t interact with the APIs directly. Some example services can be seen in the following diagram:

Figure 1.3 – Illustration of the role ARM plays in handling Azure requests

In addition to being able to manage, secure, and monitor resources as a group with resource groups, ARM also introduced Azure Resource Manager templates (ARM templates) – a JSON file that defines one or more resources as a declarative template. You define what resources you want to deploy and any dependencies, and ARM will handle the orchestration. ARM templates allow you to repeatedly and consistently deploy resources, defined in code – Azure’s native Infrastructure-as-Code (IaC) solution.

IaC will be explored in more depth later in this book; for now, just know that if your infrastructure is defined in code, you can programmatically deploy your infrastructure consistently and rapidly, reducing the risk of human error, as well as being able to remove resources from a resource group that haven’t been defined in an ARM template, should you wish. You can even take an existing resource or resource group and export them to an ARM template for future automation.

Another benefit of ARM is idempotence – by default, redeploying an ARM template to a resource group that already contains resources that match those in the ARM template won’t affect those resources. This means that you can deploy the ARM template to reduce environment drift, without risking impacting those resources that match the specification in the template. If resources are missing from the resource group that are present in the ARM template, those resources will be deployed, bringing the environment aligned with the desired setup.

ARM templates

We just touched on ARM templates being a great way of deploying resources in a consistent, repeatable way, using a declarative template. Here’s a very simple example of an ARM template, which I will use to deploy a storage account to my resource group:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "storageAccountName": {
        "type": "string",
        "defaultValue": "stdemoaz204"
        },
        "purpose": {
        "type": "string"
        }
    },
    "resources": [{
        "name": "[parameters('storageAccountName')]",
        "type": "Microsoft.Storage/storageAccounts",
        "apiVersion": "2021-04-01",
        "tags": {
            "purpose": "[parameters('purpose')]"
        },
        "location": "[resourceGroup().location]",
        "kind": "StorageV2",
        "sku": {
            "name": "Premium_LRS",
            "tier": "Premium"
        }
    }]
}

This template was created with relative ease using the Azure Resource Manager (ARM) Tools for Visual Studio Code extension for Visual Studio Code.

As you can see, the template specifies the schema and content version, followed by the storageAccountName and purpose parameters, the former having a default value set. The last part of the template specifies the resource I would like to deploy via this template. The name pulls the value from the storageAccountName parameter. Skip down a few lines, and you can see I’m setting a tag on the resource called purpose and that a value is getting pulled from the purpose parameter. On the next line, we specify that the location (region) this resource will be created in is going to be the same one as the resource group where I will deploy this template. The last few lines are specific to storage accounts and specify the kind of storage account, tier, and replication settings (yes, I know we skipped type and apiVersion; bear with me).

With this file saved as deploy.json (the name doesn’t matter, although the extension needs to be .json), let’s look at the commands for creating the resource group and deploying the resource using the Az PowerShell module (more on that shortly). The Azure CLI or portal could have also been used:

• New-AzResourceGroup -Name "<group name>" -Location "<desired location>", substituting <group name> with the desired name of the resource group, and <desired location> with the relevant Azure region (which will also be used as the region for the storage account).

To avoid any confusion, my example verbatim is New-AzResourceGroup -Name "rg-az-204" -Location "uksouth".

• After receiving confirmation that the resource group was created, the New-AzResourceGroupDeployment -Name "<deploymentName>" -ResourceGroupName "<group name>" -TemplateFile "<ARM template path>" -storageAccountName "<storage account name>" -purpose "<purpose tag value>" command creates the deployment and specifies the parameters. Substitute <deploymentName> with a deployment name without whitespaces (it’s a good idea to make this unique per resource group for accurate deployment monitoring), <group name> with your resource group name, <ARM template path> with the relevant path to your ARM template, <storage account name> with the desired storage account name (numbers and lowercase letters only), and <purpose tag value> with whatever purpose value you want for the tag. Strictly speaking, not all these need to be surrounded by quotes – it’s more of a habit. I’d rather use them and not need them than need them and not use them!

To avoid any confusion, my example verbatim is New-AzResourceGroupDeployment -Name "StorageDeployment_1" -ResourceGroupName "rg-az-204" -TemplateFile ".\ARM templates\deploy.json" -storageAccountName "strfirstarm" -purpose 'AZ-204 book".

Once completed, I could run the last command again the same as I did previously, but because the resource declared in the template already exists with the same configuration as in the template, the resource wouldn’t be touched. I could also just change the resource name and ARM would deploy another resource with a different name but with the same configuration – the beauty of IaC.

Although we’re discussing ARM templates as Microsoft’s first-party IaC solution, there are plenty of third-party solutions available that can also deploy and configure Azure resources. Microsoft also has another tool called Bicep that provides a more developer-friendly experience and greater functionality. At the time of writing, Bicep is not part of the exam, so we won’t go into further detail here. However, you can find a link to its documentation in the Further reading section.

Back to the template and the two properties we didn’t talk about – type and apiVersion – they both relate to resource providers and types. We’ll cover these in the next section.

Resource providers and resource types

Now that we have introduced ARM, it’s worthwhile going one level deeper and discussing Azure resource providers. ARM relies on a variety of resource providers to manage distinct types of resources. For example, when deploying a resource, the request will come to ARM, which will then use the appropriate resource provider for that resource type. Resource providers are identified by a resource provider namespace – some common examples of resource providers are Microsoft.Compute, Microsoft.Storage, and Microsoft.Web. Each resource provider has one or more resource types. If we take the example of a virtual machine – ignoring all the additional resources that can be deployed alongside it for the moment (network resources, for example) – ARM will use the Microsoft.Compute/virtualMachines resource type, which – as you can see – falls under the Microsoft.Compute resource provider.

Why am I telling you this? For a couple of reasons:

• If you try to deploy a resource and the relevant resource provider hasn’t been registered within your subscription, you may not be able to deploy that resource, depending on the permissions for registering resource providers in the subscription.
• When you start looking at deployments via ARM templates or even within the Azure portal, you will see a reference to resource providers and resource types, so it makes sense to introduce them beforehand (look back at the previous ARM template and you will see).

Here’s an example deployment from the Azure portal. I deployed a virtual machine and the required additional resources. You can see the resource type (comprised of the resource provider namespace and resource type) in the Type column:

Figure 1.4 – Resource providers and resource types in the Azure portal

Resource providers provide extensibility, allowing new resource providers to be added in a consistent way when new services are added to Azure. You can also write a resource provider for managing custom resource types. The availability of resource providers and resource types (and specific API versions) vary, depending on the Azure region. There is also a tool within the Azure portal called Resource Explorer that allows you to explore the various resource providers and types that are available. Every resource type will have one or more API versions available. More on that later.

Resource definitions

One last topic before we move on is resource definitions. Although certain properties will be present in some resources and not others, all resources managed by ARM have the following properties in their definition:

• Name
• ResourceGroupName
• ResourceType
• Location
• ResourceId
• Tags (optional)

It’s useful to become familiar with what a typical resource definition looks like as you will likely encounter them often, in various forms. Most of these have been discussed already (location is the same as a region in this context), except for ResourceId. Resource IDs are globally unique identifiers for a specific resource, in the /subscription/<subscription ID>/resourceGroups/<resource group name>/providers/<resource provider>/<resource type>/<resource name> format. Here is an example of a virtual machine with a single tag name and value:

Figure 1.5 – Example resource definition including a tag

How did I get that information? Using Azure PowerShell. In the next section, we’ll look at how to use the Azure CLI and Azure PowerShell.

Azure CLI and Azure PowerShell

As this chapter is intended to be a recap, we won’t be going into too much depth here. If you have installed the Az PowerShell module and haven’t already signed in with it, you can use the Connect-AzAccount cmdlet. If you have installed the Azure CLI and haven’t already signed in with it, you can use the az login command. For this chapter, I will be using Azure Cloud Shell from within my browser. If you would like to do the same, you can find instructions here: https://docs.microsoft.com/azure/cloud-shell/overview. Let’s explore a few basic commands that touch on some of the topics we’ve discussed so far. We will go through examples for both PowerShell and the Azure CLI.

Az PowerShell module

Here are a few basic commands you can run within your PowerShell session (whether locally or via the PowerShell Azure Cloud Shell):

• List all Azure locations available to your current subscription with Get-AzLocation. Notice that Location is slightly different from DisplayName.
• List the resource providers available to your current subscription with Get-AzLocation | Select -ExpandProperty Providers | sort.
• List some of the locations in which the Microsoft.Compute/virtualMachines resource type is available and which API versions are available with (Get-AzResourceProvider -ProviderNamespace Microsoft.Compute).ResourceTypes | where ResourceTypeName -eq "virtualMachines".
• If you already have a resource deployed, you can list the resource details as in my previous PowerShell screenshot with Get-AzResource | Where Name -eq "<resource name>", substituting <resource name> with the name of your resource.

Azure CLI

Here are a few basic commands you can run within your CLI session (whether locally or via the Bash Azure Cloud Shell):

• List all Azure locations available to your current subscription with az account list-locations. Notice that although you can immediately see additional information, displayName and name are reflective of what we saw with PowerShell. To filter out the noise and just list the names, use az account list-locations --query [].name -o tsv.
• List the resource providers available to your current subscription with az provider list --query [].namespace -o tsv.
• List the locations in which the Microsoft.Compute/virtualMachines resource type are available and which API versions are available with az provider show --namespace Microsoft.Compute --query "resourceTypes[?resourceType == 'virtualMachines'].{Locations:locations[], apiVersions:apiVersions[]}".
• If you already have a resource deployed, you can list the resource details with az resource list --name "<resource name>", substituting <resource name> with the name of your resource.

These were just a few basic examples of using the Az PowerShell module and the Azure CLI to get information from Azure. There will be many examples throughout this book, so having an introduction to them early on – if you weren’t already familiar with them – can be beneficial.

In this chapter, we had a recap of some generic facts and benefits of cloud computing while discussing the most common deployment and service models. Then, we went into some Azure specifics – starting with high-level information about Azure, subscriptions, Azure Active Directory, and resources. From there, we touched on regions and availability groups before looking at ARM – what it is, how it works at a high level, and resource groups and tags, and then looked at how to use ARM templates to deploy in a programmatic, consistent way while making use of ARM’s idempotence.

We continued looking at ARM by covering resource providers, resource types, and resource definitions. We then brought some of these topics together using the Az PowerShell module and the Azure CLI to get information from Azure. If you are taking the AZ-204 exam, it’s likely you already knew a lot – if not all – of the topics we have covered. If not, then this fundamental starting point should serve you well throughout the rest of this book.

In Chapter 2, Implementing IaaS Solutions, we will build on some of the topics discussed in this chapter, specifically around IaaS and ARM. We will look at provisioning virtual machines in more detail, including programmatic deployment, before looking at containers and their associated Azure services.

Answer the following questions to test your knowledge of this chapter:

1. What is the difference between scaling vertically (that is, scaling up/down) and scaling horizontally (that is, scaling in/out)?
2. What is the resource provider for virtual machines?
3. With SaaS, you, as the consumer, manage data, access, and the operating system running the software. True or false?
4. Azure virtual machines are an example of which cloud service model?
5. What is the maximum number of resource groups an Azure resource can be a member of?

To learn more about the topics that were covered in this chapter, take a look at the following resources:

• You can read more about Azure regions and availability zones here: https://docs.microsoft.com/azure/availability-zones/az-overview
• You can read more about Azure Resource Manager here: https://docs.microsoft.com/azure/azure-resource-manager/management/overview
• You can read more about ARM templates here: https://docs.microsoft.com/azure/azure-resource-manager/templates
• Documentation on Bicep can be found here: https://docs.microsoft.com/azure/azure-resource-manager/bicep/
• You can read more about role-based access control (RBAC) here: https://docs.microsoft.com/azure/role-based-access-control/overview
• You can find several design decision guides from the Cloud Adoption Framework here: https://docs.microsoft.com/azure/cloud-adoption-framework/decision-guides
• You can read more about queries with the Azure CLI here: https://docs.microsoft.com/cli/azure/query-azure-cli
• To learn more about the Azure CLI and PowerShell, check out the Microsoft learning path here: https://docs.microsoft.com/en-us/learn/modules/automate-azure-tasks-with-powershell/
• For further information on the fundamentals of Azure, check out the Azure Fundamentals learning path from Microsoft here: https://docs.microsoft.com/learn/paths/az-900-describe-cloud-concepts/