All Microsoft Azure AZ-900 certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the AZ-900 Microsoft Azure Fundamentals practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

NEW AZ-900 Course for 2021 - Cloud Models and Cloud Types

1. Overview of Cloud Models

Perhaps the most common and easiest to explain type of cloud service is called "infrastructure as a service." It's also commonly abbreviated as IaaS or I. This is when you're basically getting a virtual machine like Windows or Linux that you can do what you want with it. So if you take what you are running on a local physical machine and transfer that to the cloud without much change, that is a Windows or Linux machine in the cloud, that's a virtual machine, and that is infrastructure as a service. This also includes things like networking services, load balancers, firewalls, and anything that you have a physical representation of in your own network but are using a virtual representation of in the cloud.

It's sort of a one-to-one match, then, and that could be basically considered infrastructure as a service. Now, this isn't going to include software services like databases and things like that, but in terms of pieces of hardware that you have in your network that you are virtualizing to run in the cloud, thus infrastructure as a service. I think it's fairly fundamental to this exam and the whole concept of cloud computing that you understand what services fall under what bucket, because you're going to find yourself later on having to make decisions, especially on the exam, about whether you're going to do this as an infrastructure model or whether you're going to use one of the other abstractions. So infrastructure is the most basic foundational one.

You're just moving what you currently have from your own network and moving it into the cloud, and it's a pretty one-to-one mapping. You've got a network here; you create a network there. You've got a machine here; you create a machine there. Now we're starting to get into what I'm calling "levels of abstraction." so particularly with Microsoft. But of course, all the cloud providers provide other ways of running code and services in the cloud that they're now more involved in. So the first level above infrastructure is called "platform as a service." So you can envision this environment where all you're doing is just compiling your code or taking your code, compiling it, putting it into a zip file, and uploading it to the cloud. And the cloud provider then just runs that code. So in essence, you're not picking out specific pieces of hardware, you're not setting up networks, and you're not doing any of those infrastructure pieces.

You're just giving them the code and saying, "Hey, here's my program; please run it." And that could be considered a platform-as-a-service model in Microsoft Azure; those are called web apps or app services. But we'll talk about Azure specifically in a couple of sections from now. So all we need to know is that any time you don't have choices over the hardware, you typically have tiers, or you're basically choosing payment levels. So do you want to run this as Basic, Standard, or Premium? You're going to choose tiers, but you don't have to choose RAM and CPUs and manage disc space and things like that. The next level of abstraction above platform would be more of a "software as a service." Now, or this is abbreviated as SAS, SaaS. You may have heard this outside of the context of cloud computing. There are many famous SAS companies that you may interact with every day. For instance, anything like Dropbox, where you're putting your files in the cloud, is a SAS.

Any of your backup services, like Backblaze, which is a SaaS provider providing backup services to the cloud, Any of your Google Drive, Google Docs, Microsoft Office365, or anywhere else you use a web browser to access a service that is typically a SAS service, You're not running the software on your own machines; it's running in the cloud. And believe it or not, there are SAS products within cloud providers. We talked about how Office 365 runs on Azure, for instance. But you could have other products. Even Active Directory is a product that runs in the cloud as a service. So really, you're just configuring an existing product.

You have no access to the code. You're not uploading code to run. You're basically using a product that's being provided to you. So those are the three levels between "infrastructure as a service," "platform as a service," and "software as a service." Now, there are others, and we're going to talk about that in a second, but we do have an important point, and this is on the exam called the "Shared Responsibility Model" for security.

And this is going to differentiate between software as a service, platform as a service, infrastructure as a service, and running the servers on-premises, which is the on-premises model, where you're hosting the machines and the networks on your own hardware. This diagram is sort of the latest representation of the differences between those four models and the three cloud models, and you're running it in your own environment. So we can see the columns representing Saspass, IAS, and On Prem. And at the bottom of the diagram, the cloud provider has complete responsibility. So for Saspass and IAS, the cloud provider has complete responsibility for physical security. They secure the data centers—the door locks, the fingerprint readers—and the fences around them.

They secure the physical networking—the switches and the wires—and how they connect to the Internet through their own Internet provider. They secure the computers, the racks, and the people who have access to those devices. Physically, that's a huge responsibility because all of your hacking protections mean nothing if the hacker can grab the machine and just take it. So the physical security for those three models is provided by Azure. Obviously, if you're running it in your own environment, well, then that's on your shoulders.

You need to have physical security in place. You need to restrict who has access to those machines. And so that your hacker doesn't end up coercing an employee to go and do something for them. I'm going to switch to the top of the model in terms of where everything is always your own responsibility. So the information that you pass into Azure and the data that you fill into your database are the code that you upload. That's your own code. That's always going to be your responsibility. Any kind of connectivity that you set up—for your workstations, your mobile access, and things like that—is always going to be your responsibility. And these things are often surrounded by accounts.

You're going to have an Azure account, you're going to have user accounts, and you're going to set up RBAC permissions. We'll talk about that. So when you're setting up accounts, those user IDs and passwords, and how you do multifactor authentication, that's always going to be your responsibility. If you have a storage account that has an access key and you somehow leave that access key on If you post a note and that gets leaked, someone's going to steal your data, and that would be entirely irresponsible. Now the middle layer, where it says it varies by service type, that's really the finer details of this, right? So in a SaaS model, like in the Office 365 or Azure Active Directory cases, there's a shared responsibility. Microsoft has the responsibility to make sure that your accounts cannot be hacked into to some degree. But then, of course, you still have your own responsibilities for not letting someone into your account. Any kind of application that you upload in a SaaS model—well, that's their responsibility. They coded it.

You're not even doing any coding in a SaaS model, but in the infrastructure model, it's entirely your responsibility, which you then pass somewhere in between. So I would take a moment to look at this diagram and just really try to understand whose responsibility it is to provide security among those four models whose responsibility is security. And that's one of the determinations of how you're going to make a decision in terms of which model you're going to follow when you're using the cloud. We'll come back and we'll continue to talk about the different models.

2. The Serverless Model

So we're still talking about the types of cloud services that there are, and infrastructure as a service, platform as a service, and software as a service are not the only three models for running code in the cloud. So in this lesson, we're going to talk about the other models. Now. The most prominent of the other models is now being called the serverless model. The name is a little misleading because there are still servers. It's just even more abstracted from you.

So you just have less access to the servers running a serverless model. And oftentimes you don't even know how many servers or how many processes are running your code. So at least in the platform as a service model, you do have some concept of how many instances there are and what your performance expectations are. But in the serverless model, it's just even less. So you don't have as much access to control and performance in the platform as a service model. One of the foundational elements in Azure is the App Service Plan, and we're going to talk about that later in the course. But in the platform as a service model, you're choosing a tier; you're choosing the basic tier, the standard tier, and the premium tier.

And you're also choosing plan levels within those. So standard one, standard two, and standard three And so you're going to get double the performance, like S Two is double the performance of S One, and S Three is double the performance of S Two. And the features are pretty much the same between them except for the performance. So in a past model, you did have control over how much horsepower was running your apps. In the serverless model, you're just handing it over and paying on a different level. Also with the past model, the concept of scaling is your responsibility.

So if you want your application to pay attention to CPU utilization and then add instances when the CPU starts to get hot, that would be the past model. In the server less model, the cloud provider takes on that responsibility. So you give them the code, and they will add servers as they need to. Okay? So you're basically trusting them with not only the hardware but also the scaling issue. So there is a sort of benefit to serverless, which is that you don't even have to worry about choosing the right plan when you're sitting in front of the computer and you're trying to set this up and you're like, "Oh, do I need the S-2 or should I go for the S-3 just in case?"

So serverless uses are even closer to that ideal of leaving things in the cloud and only paying for what you need. You're not worrying about scaling; you're not trying to set up the right rules in terms of: is it 70% CPU or 75%? When do you scale back? Another benefit to the serverless model is that there's also a chance of paying nothing. So if you load a website into a serverless app and no one ever visits it, your bill might come back literally as $0 because you're only paying for execution and you're not paying for the reservation of that. So in an app service or platform as a service, you're paying by the hour. And if no one ever visits your website, you're still paying.

The serverless model means you're basically paying not by the visit but by the CPU utilisation and even by the data utilization. So if we look at Microsoft Azure more specifically, there are different serverless offerings. Now, this isn't the Azure part of the course, but I will mention you can get Azure functions. There is a serverless Kubernetes offering, which is the container service. There are database serverless options and even a Cosmos DB server less. I think that's also out of preview now too. So you've got different database and compute serverless offerings that you can go to, which again can drive your bills very low. But then you also could have an unexpected bill because you're not picking a plan; it's taking over for you.

3. Cloud Types

Clouds are just one thing, right? When you say, "I'm going to run this in the cloud," okay, the cloud is just a single entity. But in actuality, there are many different types of clouds. The cloud that we often think about—and maybe is most relevant to anyone watching this course—is the public cloud. And that means that anyone can go there and sign up for it. Basically, if you have a credit card, you go to Azure at Microsoft.com, sign up for an account, give them your credit card, and you can start using cloud services almost immediately.

So that's the public cloud. It's just open to the public. Now to be clear again, Azure is the vendor. They own the hardware; they own the wires, the cables, the buildings, and everything like that. It's their network and their infrastructure. And what you're doing is leasing or renting services. You're not leasing or renting hardware; you're releasing or renting services there. But there's also this concept of the private cloud. There's something that's not often talked about, but you can actually set up a cloud environment using your own hardware. And so if you are a government, a bank, or a large enterprise, you might say, "Hey, we don't want to use Microsoft's hardware." We have our own data center, and we are happy to pay for that large upfront capital expenditure. But we do love the cloud for its flexibility, agility, scalability, and elasticity.

We want some of those benefits. So that's called a private cloud. The customer owns hardware, leases it, or has exclusive access to it. So you may work with a company like IBMor other companies to have a private cloud like it's not just walk in with a credit card and be using it within 20 minutes. You have to establish that relationship. Again, typically, you're purchasing hardware up front, which requires long-term commitments, etc., etc. Microsoft has products you may have heard of called AzureStack, which is software that you can license, install on your own hardware, and then you can use a portal to create VMs and other stuff just like you do with the public cloud. So Azure Stack is the product that's used; we're talking about private clouds with Azure, but other companies have private clouds. The third type of cloud computing is called hybrid. And Microsoft is really bigger on this than either Google or Amazon when it comes to the cloud. And hybrid, as the name implies, is a combination of public cloud and your private hardware, which doesn't have to be Azure Stack running in your own environment.

You could just have typical Windows or Linux installations, and you're just installing agents on those machines in order for the cloud to connect to the public cloud. But you're basically extending your diskspace into the public cloud. You're extending your databases that are existing primarily on your private cloud into the public cloud, working with servers that run some of them in the public cloud and some of them on your own cloud, things like that. So any kind of combination is called a hybrid model, and you see that word used in the Azure world in different contexts, not just when it comes to the cloud.

So let's compare and contrast the differences between public, private, and hybrid, and I think hopefully it is pretty straightforward. But in the public cloud, Microsoft owns the hardware and you're just temporarily using it, and again, you could set it up. There are things called reservations, and you can put yourself in a one-year or a three-year contract. So there are some longer-term and cost-saving elements to the public cloud. Private cloud. It is your hardware, or at least you have an exclusive contract with someone to lease it, more like a traditional on-premises or hosting arrangement.

But you're using the services of the public cloud, and maybe you get some of the benefits of its agility. Flexibility and things like that But you have the hardware, but you don't get the cost savings of being able to just stop paying for something. And finally, hybrid means a mix of some things that are public and some that are private. And again, you don't even have to be running a full-on private cloud; just your own hardware, your own network, your corporate network versus the Azure network, VPNs and Connections Express routes, things like that. So that's the difference between the three models.

NEW AZ-900 Course for 2021 - Core Azure Architectural Components

1. Overview of Core Azure Architectural Components

900 exam, which says it describes core Azure services and is worth 15 to the exam. For the first time in this course and in the exam, we're going to be talking about the actual Azure services that exist. And so, your goal with this section is to learn about these services, understand their meaning, and therefore be able to answer questions about what they are, what they're good for, and what they're not good for. You can see on the screen the two major subsections of this. One has to do with core Azure architectural components, and the other has to do with core resources. So the first section is the elements of a set of architectural diagrams, which could be regions, subscriptions, and resource managers.

And then the second half of this is the actual resources that are used to build us a solution. So let's talk about that first section. First, the core Azure architectural components The first and one of the most important concepts that you have to understand is the concept of Azure regions. So what Microsoft has done is they've broken up the map, broken up the world into now over 60 regions. So when you want to deploy a resource—let's say you want to deploy a virtual machine—you have to choose a region. And so these are the geographical locations in which those servers exist. Let's take a look at the map. And this map might even be out of date by the time that you're seeing it. But here's basically a snapshot in time of the 60 plus regions of the world.

Now I should say that every region is available to everyone. Okay, so we talked in the last section of the course about the public cloud and the private cloud. We haven't yet talked about government services. Those are versions of private clouds. But we can see here that we've got Canada, lots of them in the United States, there's one region in Brazil, and the Western European regions have been blossoming. I can just remember a few years ago when there were only two or four. And now there are, it looks like, at least a dozen regions in Western Europe. We've got South Africa coming on board, the UAE, the Middle East, India, and Israel, a new region that's been announced, as well as a lot of Asian regions.

Now the reason why, when you go into Azure, you're not going to have 60 regions to choose from is that some of these regions do have certain restrictions on them. So, for instance, you can't just create a resource in China because the Chinese version of Azure is run by a Chinese company; you need to have a specific agreement with them. And so China is its own region; even though it's on the map, it's not available to the general public without a specific agreement. Then you're going to have regions such as the Department of Defense and the US. Government regions in the United States Obviously, you're not an employee of the US government, or if you're not an employee of the US government, you're not going to have access to that. Conversely, if you are an employee of the US government, you only have access to the US government-approved regions. And so there are lots of these little rules here and there.

I believe in India, you can only deploy certain regions if you are registered in India, things like that. So as you'll see, this map is changing. Every few months, they introduce a new one. The next related concept to regions is the concept that regions have pairs. So it's not just a flat map where you have 60 regions and they're all identical to each other. What Microsoft has done is take two regions and treat them as a pair. And so if you have some data that exists in one region, the paired region makes the most sense in terms of the backup. It's got the fastest, lowest latency data connection between the paired regions. Microsoft keeps that in mind when they're doing their deployments. They'll deploy to one region but not the other, and make sure that the pair isn't as affected. And in the worst-case scenario where multiple regions go down, they're going to pick one of the regions to bring up first.

And there are certain priorities that go into it. So you can go online and find out all the pairs if you're into creating actual resources and you need to know all the pairs. You can go and find the full list. But here's just a sampling of the list, where obviously the two regions in Canada, the Central and Eastern, are a pair. So if you deploy to Canada Central, the most logical place for you to put your backups would be in Canada East because that's the location with the highest speed and lowest latency in terms of bringing them back online.

North Europe and West Europe, east and west USA region. We should point out that Brazil only had one region. And so Brazil is one of those unique places where there is no other Brazilian region. So it's paired with the South Central United States. which means that the North Central US is also paired with the South Central US. So South Central US has two paired relationships. You don't have to memories the pairs for the exam, but you do need to understand why it is beneficial to put your backups in the paired region compared to another region.

Microsoft Azure AZ-900 practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass AZ-900 Microsoft Azure Fundamentals certification exam dumps & practice test questions and answers are to help students.