Gain in-depth knowledge for passing your exam with Exam-Labs AZ-303: Microsoft Azure Architect Technologies certification video training course. The most trusted and reliable name for studying and passing with VCE files which include Microsoft Azure Architect AZ-303 practice test questions and answers, study guide and exam practice test questions. Unlike any other AZ-303: Microsoft Azure Architect Technologies video training course for your certification exam.

Implement Azure Infrastructure

4. Virtual Machines Overview

In the previous few lectures, we looked at virtual networks. There's actually far more to virtual networks, but it's difficult to explain without having specific solutions in mind. Therefore, in the next set of lectures we'll examine other infrastructure components, and then once we've built some, we'll loop back around and examine some more advanced topics. First, let's look at virtual machines. Virtual machines are still used by many companies moving to the cloud. In fact, it's often the first step when companies want to begin their cloud adoption journey by taking a lift and shift approach. In addition, many legacy applications cannot simply be refactored to leverage more modern solutions such as SQL, Azure, or Web apps. Therefore, virtual machines provide the simplest and quickest way to start using Azure. They also provide many of the benefits. For example, by building them atop virtual networks, it's far easier to integrate them with on-premise solutions in hybrid scenarios. Now, all of this doesn't mean they have no additional benefits. VMs in Azure allow for easy management and monitoring, provide a whole range of available operating systems and versions of those operating systems, They can be built as scale sets and/or in availability sets to provide better resilience. The fact that configuring components, including VM, accounts for nearly half of a S 300 example shows how important this topic remains. So virtual machines are actually built from a number of separate components, and this is important to understand as it's what makes VMs so flexible. It's also important to understand that when you want to remove a virtual machine, it's not just a case of removing the virtual machine. You also need to delete all its components individually. So a virtual machine consists of the virtual machine itself. It will generally have one or more disks. So the first disc would have the operating system, and then you might have data discs attached, and you might have one or more virtual network interface cards. Each interface is connected to a VNet, and therefore it gets an internal IP address on that VNet. You can also add a public IP, which provides external connectivity outside of that VNet. The public IP address is optional, and you wouldn't use it in a hybrid scenario where you want to limit connectivity to an internal IE on-premises network via VPN for security reasons. Finally, VMs also get a network security group by default. Now, network security groups are very important. They allow you to define specific network security rules and firewall rules to allow specific inbound and outbound traffic to specific sources and destinations on set ports. So for example, you might want to limit certain inbound traffic to a specific network, such as your internal corporate network, i.e., so that you can RDP in to or remotely control your virtual machine from an internal network but not from the public Internet. but on that same virtual machine. You might want to allow HTTP traffic out to the Internet so that that virtual machine can actually browse the web. For example, let's look at discs in a little bit more detail. So when you create a virtual machine, you create one or more disks, and discs can be managed disks. So Managed Disks handles the Azure Storage account creation and management in the background for you. So you never actually see that underlying storage account. But this ensures you don't have to worry about the scalability limits of that storage account. When you create a virtual machine, you specify the disc size and performance. Tier Premium and Azure Creation manage that disc for you. As you add discs or scale the VM up and down, you don't have to worry about which storage is being used. The available types of discs are ultra disks, premium solid state disks, or SSDs, standard SSDs, and standard hard drives, or HDDs. This table provides a comparison of the different types of discs you can have. But, in brief, auto discs tend to be for the biggest and fastest workloads that you can have. Premium discs are again for very fast applications and provide discs up to 32GB. And then we start going down through the tier, and as you can see, you start getting slower performance and slower throughput. Of course, you start with the standard HDD. They are obviously far cheaper than an Ultra disc. So when you're designing your virtual machines, you have to balance the performance requirements with the cost. So all managed discs are highly durable and available. This means they are designed for 99.99%, which is 59% availability. Managed discs achieve this by providing you with three replicas of your data, allowing for high durability if one or even two of the replicas experience issues. The remaining replicas help to ensure the persistence of your data and provide high tolerance against failures. Manage Disks: In a subscription per region, you can create up to 500 discs of a type. This allows you to create thousands of VMs with a single subscription. They're also integrated with availability sets, which we'll look at shortly. Managed Disks are integrated with Availability Sets to ensure that the discs of the VM in an availability set are sufficiently isolated from each other to avoid a single point of failure. They're also integrated with availability zones, and again, we'll look at availability zones shortly. Finally, to protect against regional disasters, Azure Backup can be used to create a backup job with time-based backups and backup retention policies. And you can implement RBAC or Azure role-based access control to assign specific permissions for a managed disc to one or more users. Before we move off of disks, it's important to talk about encryption. Manage Disks offers two kinds of encryption. The first is server-side encryption, which is performed by that storage service. And the second is Azure Disk Encryption, which you can enable on the OS and the discs for your VMs. So server-side encryption provides encryption at rest and safeguards your data to meet organisational security and compliance commitments. Servicide encryption is enabled by default on all managed disks. You can either allow Azure to manage the keys for you or you can actually provide the keys yourself. Azure Disconnection allows you to encrypt the OS and the data used by a virtual machine. This encryption includes managing disks. For Windows, the drives are encrypted using BitLocker. For Linux. The discs are encrypted using D encrypt.The encryption process is integrated with the Azure Key Vault to allow you to control and manage those encryption keys. And again, we will cover those in more detail later on. So we mentioned earlier about availability sets and scale sets, so let's talk about those. So first we have the concept of something called fault domains. Fault domains are used to control where VMs are built. A fault domain is essentially a set of servers that share the same power and network switches within the data center. Therefore, if two virtual machines run in the same fault domain, an issue occurring at that switch or power source could affect both of your virtual machines. Update domains are used to control when the underlying hardware that Microsoft manages is patched and rebooted. As Microsoft performs maintenance on the underlying hardware for you, there are times when that hardware might need to be rebooted, and sometimes the updates might require the virtual machine itself to be rebooted and an update domain-defined when these events occur. So all servers in the same update domain would get rebooted or affected at the same time. So, to get around this issue, we have Availability Sets. By default, Microsoft automatically manages the placement of your virtual machines. Therefore, two virtual machines could be running in the same fault and update domains. By creating an availability set and assigning virtual machines to that availability set, you're informing Microsoft to distribute those VMs across fault and update domains. Therefore, in the event of a downtime from either failure or maintenance, it would affect only those VMs in that domain. And because the others are distributed, they would not be affected. Using this, you can build applications that span multiple virtual machines and then put them in an AV set. Therefore, your application would not be affected if one of those updates or fault domains went down, as the other two virtual machines would carry on running, providing services. Next we have scale sets. So if your virtual machines let you create and manage groups of identical load balance VMs, the number of VM instances can automatically increase or decrease in response to demand or on a defined schedule. Skill sets provide high availability to your applications and allow you to centrally manage, configure, and update a large number of VMs at a time. So skill sets are built on virtual machines. So with scale sets, the management and automation layers are provided to run and scale your applications. Of course, we could just build our own VMs manually ourselves, as we saw in the previous example with availability sets. However, using a virtual machine skill set has a number of advantages. as we can see in the following table. The main benefit of scale sets is that they are automatically created from a central configuration, where you build one virtual machine and the Azure platform will automatically replicate that virtual machine into those scale sets. You can automatically create and integrate them with an Azure load balancer or an application gateway, and they are automatically distributed across availability zones. Finally, with virtual machine skill sets, you can set auto scaling, which means you define a minimum and a maximum number of VMs in that scale set and set certain limits when it needs to spin up or spin down those virtual machines. Or you could do it on a schedule. So for example, you could set additional virtual machines to be spun up within Set if the CPU threshold for them reaches 8%. Or you could set it to automatically spin up additional virtual machines at certain times of the day or the month, for example. Month end.

5. Virtual Machine Types

When creating virtual machines in Azure, you can use a variety of different types rather than each individual size, type, and cost for the exam. You do need to remember all the different types that you can use, known as the "series of VMs." The first few sets of VMs are fairly straightforward. The servers are basically just balanced entry-level servers. So these will generally be used fordev test and proof of concepts. There are scenarios where you might havelow traffic or small to medium servers. Next we have the BS series. These are a very specific type of VM. They are inexpensive, but they are burstable, which means that as they require more power, they can automatically have more power assigned to them at that time. Again, the use cases tend to be fairly small development and testing concepts, but they're also quite well suited to Mac services. Next we have D series or the General purpose servers. These have an optimal CPU-to-memory ratio and are more suited for most normal use cases. The DSN Das also support premium SSDs whereasthe standard DCE also support standard SSDs. Again, these would generally be used for enterprise applications, smaller relational databases, caching, and analytics. As we move up the series, we start to get more specialised use cases. So the next one is the DC Series. These have special CPU processing protection using something Secure Enclaves," and they're ideal for customers who are quite worried about the sharing of data or the leaking of data in shared environments. So, for example, this port allows confidential querying of databases, consortium networks, and secure multiparty machine learning. E-series machines are the first where we start to optimise either memory or computer storage. As a result, the E series is memory optimized. This means there's a high memory to vCPU core ratio, which makes them well suited to applications that require lots of in-memory processing, such as certain styles of databases, particularly SAP, Hana, SQL, Hexton, and other large-memory in-memory workloads. The almost-opposite D series is the F series, which is compute optimized.These have a higher CPU to memory ratio and are designed for compute-intensive operations that need to be able to store lots in memory while doing that. So think batch processing, Webservers, analytics, and gaming. GSeries is a bit of a combination; it's memory and storage optimized. So these are enhanced general-purpose systems like the D-series ones, but they've got twice as much memory and up to four times more local SSDs that you can use. Again, good use case for these tend to be largescaleand no SQL databases, ERP, SAP and so on. So think standard DCV but with more power. Again, in line with that, get the high-performance performance compute.So these are good for specialist highperformance that requires specifically high bandwidth. So these tend to be quite specialist use cases, particularly in the mathematical and scientific world where you might want to have use cases such as fluid dynamics, finite element analysis, and seismic processing. Next, we get storage optimized. So this isn't just necessarily about having large disks, but it's about having high throughput and low latency on those disks. Again, this tends to be well suited for particular types of databases, namely no sequel databases such as Cassandra, MongoDB, and Readers. The final two series are again becoming more and more specialized. So the M and MV Two series are like the ECWs in that they are memory optimized. However, they support far more vCPUs. So for example, with the MCU, you can have up to 128 vCPUs on a single server, whereas the MV2 supports up to 416 vCPUs on a single server. And finally, we have the NCS. So these servers have our GPU enabled using Nvidia chipsets, and they're ideal for intensive graphic workloads or other workloads that use that type of computational processing, such as machine learning. So again, the typical workload might include simulations, deep learning, graphics processing, video editing, even gaming and remote visualization. So for the exam, you need to understand the different use cases for the different series. That's enough theory for now. In the next lecture, we'll get going and start building some virtual machines.

6. Creating a VM with the Portal Walkthrough

You. So, that's the theory out of the way. Let's go ahead and actually create a couple of virtual machines. First, we'll create a Windows virtual Machineand we'll do it using the portal. From the portal, either click the "New Resource" button on the main homepage, or, if that isn't visible or you've changed your home page, go to the menu up here and select "Create a Resource." By default, it comes up with a few options here. So, for example, we could go straight for the Windows Server 2016 Data Center Edition. But what I want to do is actually go for the latest version, which is the 2019 edition. So I'm going to search for Windows Server, and it will bring up the Windows Server by Microsoft. And now we get to select the different options that we can build. I'm going to go for the Windows Server 2019 data centre and then click Create. It's going to ask for some basic information. The first is that you select "Subscription." Next, we select a resource group for it to go to. Now we don't have a resource group at the moment that I want to use for this virtual machine. So what I'm going to do is create a new resource group, which I'm going to call Win Servers. Next, we need to give it a name. I'll simply refer to this cloud guru as win 19. Tell it where you want it to build. Here we can set availability options. So, for example, we can set it to availability zones or skill sets. or availability sets And this is what we were talking about earlier with the various different options. As this is just a demo, no infrastructure redundancy is required; in the real world, you'd want to set a Tartar to set the availability zone created as an availability set or possibly even a scale set. Next, as we can see again, we've got the Windows 2019 Data Center image. Again, if we wanted, we could actually go through and choose a different image here. And actually, as you can see now, we can change to Linux, but we're going to stick with the DataCenter. A relatively new option is this Azure Spot instance. We're not going to use this, but basically, Azure Spot Instance uses it to get cheaper virtual machines at discounted rates. These won't be fault tolerant.Essentially, what happens is if there is spare capacity in the Azure Data Center, it will spin up and use this VM using that spare capacitor. If, however, that capacity gets low, Azure reserves the right to just shut down your virtual machine. As a result, unless you're doing batch processing and don't need a virtual machine on all the time or it's not a critical machine, you shouldn't use it for production workloads. Next, we select the size. By default, it usually goes to the standard DS 1 vs. 2. If we want to change that, we click "change size," and then we get a whole range of options for what we can go for. I'm actually going to go for a really small virtual machine just for the purposes of this demonstration. So I'm going to go for a B one S.As you can see, that's only going to be around £8 a month. And then finally, we need to give it a username. Put in your username and password. The next option is that we can select the inbound ports. So by default, it's going to allow RDP 3389, and this will allow us to remote control the machine. Now we can use that or click here to see other options. So for example, if you knew this was going to be a web server, you might want to open HTTP and HTTPS. For now, I'm just going to leave it with RDP, and the final option on this page is that we can use something called Azure Hybrid Benefit. Now some larger companies get certain Windows licences that allow them to block purchases of large numbers of licenses, or volume licensing. This is something called software assurance. If you have Software Assurance, you may be eligible for this discounted licensing. Basically what it means is that when you normally buy a virtual machine, or at least a Windows virtual machine, in July, part of what you're paying for is the licence fees. If, however, you've already got enough licences from your existing software insurance program, we can select that option and it will save that portion of the fees. Either way, there are licence fees. I'm just going to say no because I've not got software assurance, and we'll go on to configure the disks. So it's going to default to a premium SSD again as we get better discs. Premium SSDs are more expensive than standard SSDs or standard HDDs. Again, because this is just a demonstration, I'm going to go for the lowest tier. In a production environment, you would most likely want to go for a premium SSD. I'm just going to go for that. Again, as I say, that's just to keep the cost down. We could create additional data discs here. So the first disc is based on just the operating system. But if you're going to have data disks, you can create and attach them here. I'm not going to do that just yet. We'll add additional discs later on. So next, click Next to go to networking configuration. So now we define where we want that virtual machine to go. So, by default, it's going to try and create a new virtual network. And as you can see here, it's going to create one called Wind Service VNet. However, I want to actually select the virtual machine, the virtual network, that I selected earlier. And in particular, I want the Windows VNET. So we'll go down and choose that one. Again, it's going to want to know what subnet to put it on. Again, we created a couple of subnets when we created a VNet, and I'm just going to select that first VNet, that first subnet. The next option is whether we want a public IP or not. So as we were looking through, when we were goingthrough the configuration of the servers, you can either havea server either is purely internal, you can only accessit on that address, which means you'd have to VPNinto Azure in order to access it, or we cangive it to public IP. So the public IP will enable me to access this virtual machine over the Internet in a production environment. If you're in a hybrid scenario, if this isbasically an extension of your existing data centre andyou've got a VPN set up or an expressroute, then you wouldn't want a public IP. For this demonstration, we are going to use a public IP because without that, we wouldn't be able to connect to it. We can set network security groups, and again, it allows us to again select ports. I'm going to take the standard network security group, and again, we only want RDP. The smaller site does not offer accelerated networking. If you go for some of the highest sizes, you can select this option, which will allow you to get higher throughput for your interfaces. Finally, if this was in a load balancingsolution, we can through here start configuring that. But again, we're going to do that manually later. So for now, we're just going to say no to that and then click management. So now we have a few options. The first is that we can set up something called boot diagnostics and OS diagnostics. When your virtual machine is booting up or when it's running, it will emit certain diagnostic information. This is helpful if, for whatever reason, your virtual machine doesn't boot up properly. I'm going to set this off for now. The main reason being that when you set it up, these two on it need somewhere to actually store that diagnostic information, which means we need a storage account because we've not gone through the setting up and various options with storage accounts just yet. I'm going to set that off and we'll look at them later. This auto-shutdown option is a very useful option is this auto shutdown.Again, a lot depends on how you will use the virtual machine. But because this is a demonstration virtual machine that I'm only going to want to use as and when I need it, what I want to do is use this auto-shutdown feature. So this allows me to set a time when the virtual machine will automatically shut down. Because costs are calculated for both compute and storage, we can save a lot of money by simply switching off a running virtual machine by simply switching it off.So by setting the auto shutdown to, say, 06:00 every night, it means if I forget to shut it down when I'm not using it, that will automatically happen again in a production environment where you might want your server on all the time. You may not want to enable this, but again, for demonstration and testing purposes, I want to make sure I don't leave it on inadvertently and incur costs. We can tell it to email me before it sends it, and we'll leave that there. And then again, the final option here is that we can enable backups. Again, I'm going to send that off for now because we will cover backups in more detail later on. Simply click "next advanced." This is where we can install extensions. Extensions allow us to install things like antivirus software, encrypt disks, and other things like that. Again, we'll go into more detail on this later on. For now, I'm just going to leave that blank, and I'm simply going to leave all these as the defaults, in particular, the virtual machine generation, which I'm going to leave as "Gen One," and then I'm going to click next to Tags. Here we can tag resources. Again, we'll go into tags in more detail, but very quickly, it allows you to select certain elements and to put tag values on them. So in a production environment, you might want to be able to tackle your resources to a particular department, or perhaps if you're an IT function and you want to recoup costs from the various users of the platform, you might want to assign billing codes, users, or various different things. These are basically free text fields that you can use just to assign meta information. We'll cover these again in more detail later, so for now I'm going to leave them blank and then just click Review and Create. It will run a final validation and everything just to make sure everything's correct, and again, it will just show you all the options that you've selected so you can double check them here in case you want to go back and change anything, but if you're happy, simply go ahead and click the Create button, and that will set off and initialise the deployment. It'll take a few minutes for that, so while we're waiting for it, we'll go ahead and start looking at creating a Linux virtual machine in the next lecture. However, this time we're going to do it from the command prompt.

7. Creating a VM with Powershell Walkthrough

Hello and welcome back! In this lecture, we'll create another virtual machine, but this time it'll be a Linux virtual machine, and we'll do it using PowerShell commands rather than directly through the portal. Because we'll be using PowerShell commands, we'll have to do it in stages. supply the varied information and create the various resources the first thing we need to do is actually create a resource group for it to be contained within, so we'll do that. We'll call this one RSG Linux VMs to stay consistent with our Windows resource group, and we're going to set the location to UK South. It'll take a few seconds for it just to appear in the portal, and I'm going to open that resource group up just so that we can see what happens in it as we issue the various commands doing this via the command prompt One of the things we'll have to pass into the virtual machine are log-in credentials, which we do in two stages. The first thing we need to do is create a secure password, so we'll create a variable object called Secure password. We'll use a command called "Convert to secure string" and pass in a password, and then we just need the as plaintext and force switches once that's done. Once that's done, we can actually create our credentials again; we'll store them in an object, and we'll use a specific namespace that contains the command that we want, which is "System dot management." dot automation and its PSC credential, and into that we pass in a username and the secure password that we've just created. We can double check what that looks like by simply typing hashtag cred, and then we see the details that we passthrough Finally, we can go ahead and create our Azure virtual machine itself. We're going to use the new AZ VM command. We're going to pass in some basic parameters that it needs, and everything else will use defaults The first thing we need to do is tell it the resource group name that we're passing building this into, so that will be the resource group we've just created. We'll then give it a name type that we want, which in this case will be "linux." Now we're going to give it the virtual network name, which in this case is going to be the name of the virtual network we created earlier, and also give it a subnet name, which again will be the subnet name of the one we created earlier. We want this to be accessible via the internet, so we're going to tell it to use a public IP address, and we do that by giving it a public IP address name, and then we're going to pass in the credentials that we just generated, and finally I want to open port 22 so that we can connect to it remotely once it's built. Once that's typed in, go ahead and hit Return, and that will spin up the virtual machine. So we misspelt the actual image and the image name; it's ubuntu, not unbuntu. Let's just go ahead and change that, and as that goes through and starts deploying that virtual machine, the various resources will start to appear within it. Once that's complete, you'll see the virtual machine and all its details. Here, however, we have got a slight issue, and that's that it created our VNet Linux in the resource group itself. In other words, if we go to virtual networks, we'll see that it's actually created a new virtual network rather than using the virtual network that we originally wanted and that we originally created. Now, in some scenarios, that's fine, and the reason why it's done this way is because by default everything gets created within that local resource group. If you do want to be able to specify a virtual network in a different resource group, then we have to do it in a slightly different way. Essentially, we have to manually create the network interface card and apply all the various network security groups and rules to it, and then pass that into the details of the VM itself when building it. This is a lot more complicated, however, or at least there are a lot more steps, but it's not too difficult to do. So what I'm going to do now is go back to my resource group and delete the virtual machine I've just created and all its related details, and then we're going to do it again Only this time we'll do it the long way so that we can tell it which actual virtual network we want it to use. Okay? Once all those resources have been cleaned up, we can go ahead and recreate our virtual machine. We've already created the resource group, so we don't need to do that again, and we've also got our credentials, so again, we don't need to create those. Sometimes things can clear themselves out just to ensure that the credentials still exist. Okay, so dollar credits, yes, we've still got those, and we can go ahead and start configuring things. The first thing we need to do is actually get hold of our actual network, because ultimately we need to get the ID of the subnet that we want to connect to. The first thing we'll do is create a variable called VNET. We're going to get the actual VNET that holds the subnet that we want to attach our virtual machine to. We can confirm that we've got the details by typing dollar VNET, and that's the correct VNET in our correct resource group. Next thing we need to do is get the subnet again; we'll create a variable called subnet. We'll use the command get AZ virtual network subnet with the name subnet and tell it that that subnet is within the virtual network that we've just grabbed. Again, if you want to make sure that everything's correct, let's just check the variable to make sure that we've got what we're looking for. So the next thing we need to do is create a manual and create the public IP. Again, we're going to do all this using objects and variables, and when we start creating these, we tell them where we want to create them. So, everything except the VNet should be placed in the Linux resource group. And then finally, we just tell it that we want this IP to be dynamically assigned. Let's just have a look. So once we've got our public IP, what we now need to do is create a set of network security group rules. These are kind of like the ports that will open to allow traffic through. And we're going to need to do this because we want to be able to SSH onto the virtual machine once it's built. So, once again, we'll make another object to hold it. You pass through the details of what we want. So the protocol is going to be TCP. We often need to specify the direction, which in this case will be inbound, and we'll be going through network security groups in a later chapter. But for now, we'll just enter these as per best practices. So we establish priorities, which determine the order in which rules are signed in. We tell it where the traffic will come from, which is everywhere. Again, we tell it what port it might come from, which is any port destination port range of 22 because that's what SSH uses, and then we tell it to allow access. Sorry, I got that command slightly wrong. It should be new hyphenaz network securityRule config not security Group Rule config. With our network security group rule in place, we can then go and create our actual network security group, assign that role to that group, select what resource group to put it in, tell it the location, and then we pass in our security rule that we've just created. Once the security group is created, we can now actually go ahead and create our actual network interface card. And this is now where we pass in the subnet ID, and this is why we need to get the V net and then its subnet earlier. So now we pass in the subnetsubnet object and specifically obtain its ID. We also pass in the public IP address that we've just created, and again we pass in the object and in particular the object ID. And finally, we pass in the network security group by again referencing the object and its ID. So if we go ahead and look in our resource group now, you'll see that we have our NSG rule and we have our public IP address and our network interface card. So the final step is to create the virtual machine itself and pass in the details of the nick and some other configuration information. So because there's quite a lot more configuration we still need to pass through for the virtual machine itself, we're going to do it again via an object. So we're going to create an object first of all called "Vmconfig" that is going to be a new AZ VM configuration object. First of all, pass some basic information, such as the VM name, and tell it the size of the VM we want. Next we're going to set the operating system name, and this is slightly different because we've already got the object. We're going to use some set commands and apply those set commands to that new VM config object. We're also going to pass it on using the credentials that we created earlier. Then finally, we take the actual VM we're doing this on, which is the dollar VM configuration with the operating system set. Now we need to set the actual image name that we want to use. We can be more specific about the image we want to use here, as well as which version we want to use, because many publishers have multiple versions found that, once again, we tend to access via the configuration object. The final step is that we need to attach the network interface card that we created earlier. We pass in the ID of the nick we created, and again, we type it at the VM configuration, and hopefully, we will see the name. We've got a hardware profile, a network profile, an OS profile, and a storage profile. The final step is to go ahead and issue the new VM command as we did earlier, tell it which resource group to use, the location we want to build this in, and finally pass the VM configuration object. Once that's completed, we should now see if we can refresh our virtual machine within our resource group. And if we go into the virtual machine, the virtual network should be on the Venet Linux subnet, which is in the resource group that we created earlier when we were creating it. We also created a specific network security group that allowed SSH on port 22 from any to any, and to test that out, we can go ahead and try to SSH onto that server, so get the public IP. So we saw two examples of how we can create a virtual machine: a simple way and a complex way. Obviously, the simple way is the easiest and best way to get up and running quickly with the new virtual machine. The more detailed method, on the other hand, gives you far more control over the configuration elements that you may need to settle.

Pay a fraction of the cost to study with Exam-Labs AZ-303: Microsoft Azure Architect Technologies certification video training course. Passing the certification exams have never been easier. With the complete self-paced exam prep solution including AZ-303: Microsoft Azure Architect Technologies certification video training course, practice test questions and answers, exam practice test questions and study guide, you have nothing to worry about for your next certification exam.

Hide