*NEW* Design Governance

1. *NEW* Azure Policy

So we've been talking about identity and security in this last set of sections. And one thing we should talk about is risk. The risk of things happening when it comes to identity What can happen? How do you mitigate against it? How bad would it be? Let's start off with a general definition of risk. And I looked around the web here and thought, okay, how would you define risk in the simplest terms when it comes to business? Anything that could potentially have a negative effect on the business is a risk. The fact that interest rates could rise could be a risk. The fact that it could rain for the next 30 straight days could be a risk. The fact that this winter is going to be better or worse than normal could be a risk. Employees' quitting could be a risk. If you sat down and listed all of the things that could negatively impact your business,you're going to use up several sheets of paper. There are just tonnes of risks out there. But over time, people have decided that you can't just treat every single potential risk equally. You would just do nothing but worry all day, do nothing but defend against risk. And you wouldn't be making progress in your business.

You wouldn't be selling to customers. You wouldn't be producing products. And so you need to basically combat everything that could go wrong with these two questions. How likely is it to happen and how bad would it be if it did happen? And so you could basically plot that along a graph and you could say, well, the risks that I really, really should really mitigate against, the priority risks, if you will, are the ones that are most likely to happen and the ones that are worst together. So if the person qualifies under both those categories, that's a pretty big risk. So we look at these four statements. These four statements are basically part of this quadrant. If it's very likely to happen or if it's got really severe consequences, it could bankrupt your business or it could end your business. That is something that you should prioritize, and it requires immediate action. If it's only likely to happen, but not very likely to happen, and it's serious but not life-threatening, if you will, that is still a risk, but it's not something that you can't go past today without addressing.

If something is just possible and if it happens,it's not that bad, that becomes an acceptable risk. And if something is not likely to happen, and if it does happen, you're not going to blink too much. Well, then that's sort of a low risk. You can just about ignore it. You can acknowledge it exists, but ignore it. So when we're looking at these risks, don't get offended. Don't go down the list and just go get worried. We're going to have to basically mitigate the important risk, the unacceptable risk, the immediate action risk. And then if something is a risk but not that serious, then we can basically accept those risks. I believe it is now impossible to have no risk. So first of all, the whole benefit of being in business is that you're taking a risk and you're getting a reward. If there was absolutely no risk to it, the reward would be so small as to not be worth it, first of all. Second of all, there's just so much that can happen and a lot of it is out of our control, right? If a competitor opens up in our retail business, if a competitor opens up immediately next door, and our business is cut in half overnight, well,that is something we can't control. Unless you can go to your next-door landlord and say, "Send me a contract that you promised never to have a competitor next to me, they're going to open up across the street." So you can't have no risk when it comes to business. And so that's why we're trying to classify these risks, accept risks that are acceptable, and mitigate risks that are unacceptable.

So what are the things that could happen when it comes to identity? Now, we're talking specifically, in this case, about your identity risk. And identity risk is essentially your user ID and passwords getting hacked. Somebody is able to get access to your system that is not the person who they say they are, or they get access to a level of authentication authorization that they don't know. Even if they are who they say they are, they're able to elevate their privileges. So those are the two types of risks we're talking about. So if your user ID and passwords get hacked and people are able to get into your system that you don't know, you could suffer financial costs. Right? I mean, we're looking at different Bitcoin exchanges that have gotten hacked, or banks, or, you know, there's an actual financial cost to getting hacked. You can pay financial penalties. You could end up having to refund your customers,you could lose customers, lots of different things.

There's also the data loss. So not only did you actually lose actual dollars, but if your database gets out on the Internet, a lot of people consider their data to be a financial asset, and that should be their competitive advantage. And so if a list of all your customers' names and email addresses made it online, well, your competitors would be contacting them and saying, "I can do better." I can beat that price. I can do this. So you've got not only financial losses, but data losses are a risk. Hackers can also wreck havoc on your system and bring it down. We have people who are encrypting systems and demanding a ransom from certain cities. I believe it's the city of Baltimore that had their systems hacked and they're being forced to pay a ransom in order to get their access back. And so certainly, that's a huge risk as well. You've got companies who've had to actually go out into the public and do a male culprit and the CEO resigns or people get arrested.

Your reputation in the marketplace can suffer if a particular hack is performed against you. So, if you work for a company that relies on your goodwill and trust, if the hack becomes public, you lose that trust. And if you try to cover it up and it gets out eventually anyway, you lose even more trust, right? So those are the things that can happen. If you get hacked, then obviously your customers get affected as well. And so is my data safe? Did I get hacked? Even if you get some sort of minor hack, but you end up having to force people to change their passwords, that causes some kind of customer confusion in the marketplace. Company executives have been known to be pulled in front of Congress. You get governments and police forces and other people that are interested now. So suddenly you're going to be talking to people you may not want to be talking to. There are laws in various places, like the GDPR in Europe, where if data gets breached, you have to follow certain standards.

You have 48 hours to report this to the customers, you have to report it to the authorities, and now you've got additional compliance costs. That's another consequence. Now, there's a lot more than that. And that might sound large and scary as well, but that sort of drives home the importance of protecting your systems, right? So, aside from the identity risk, there are other ways to hack you as well. But if you do not want your systems to be hacked using an identity-related hack, why would someone be able to get access to this? Well, if you've got users in your system who no longer work for you, like employees that have left and those users were neverdisabled, that's the source of this risk, right? So that's one way that you can have that. Or if you have employees who have authorizations that exceed their needs. You've got people who are admin users or super users or things like that for a job they no longer perform or you were in a rush to.

You sort of granted them admin rights because they needed something done that day and you couldn't figure out exactly what rights to give them. And then you forget about it. So, having too high permissions on users and even service principles is another reason. Another risk that leads to getting hacked If your systems can be accessed physically, if somebody has their computer unlocked and they walk away from their desks, somebody's able to get access to whatever they're logged into simply because they have physical access to their devices. And there's no screen saver that locks after two minutes, or they don't lock their computer. Your server room, obviously, you're going to want that to be behind a locked door as well. And you don't want a regular employee with a regular security pass to swipe their card and get into the back-end systems as well. So secure the physical.

2. *NEW* Assign a Policy

Hopefully I didn't scare you too much in the last video talking about all of the things that can go wrong, including your bankruptcy of your business if you get hacked and if your identity protection is not secure. So in this video, we're going to talk about how to prevent those risks from happening in your identity system. The first section is about risk assessment strategy. Now there's a reporting feature within Azure Active Directory called Access Reviews. Access Reviews can basically force people who are responsible for the security of a group to review the contents of that group on a regular basis. And so you can set up a policy within AzureActive Directory that says every 30 days, the group owner must review all of the members of the group. And the Access Review will not only remind them,it will basically nag them, and they will have to go into the system and review the membership of the group that they control. So let's say a particular group like the marketing group has access to the marketing application and you log into your Access Review.

You force the group owner to review access every 30 days. And you see that there's a bunch of people who have not logged into the marketing application in the past month. Well, that's a bit of a red flag. Why is it that certain people can't log into the marketing application? It could be that they've moved jobs. They used to work in marketing. Now that they've moved over into more of a management role, they don't need access to the marketing application. That would be a perfect time to say,you know what, we still love you, but we're going to be removing access to that old application because you don't use it anymore. And the more people you have access to have access to an application, there's a list of a little bit higher risk with each additional person. And so, removing the number of people who have access is one mitigation factor.

So, implementing Access Reviews to your groups is one way you're going to ensure that the members of the group all need access and are at the right level. Another thing you can do is establish a company policy for access to certain things and use the Azure policy engine to enforce that policy. Now this isn't so much for applications themselves as it is for access within the portal. And so if you have a marketing resource group and your policy is no, if you're a marketing employee, you can only create resources in the marketing resource group. You are unable to create resources in any other group. Well, instead of just having that as a written policy, you could and should implement an Azure policy that says people who are members of the marketing group can only create policies in this resource group. And in that way, you've got a system that's enforcing the policy as opposed to just it being something that you sent an email on and people are forgetting it. You can also use policy not only to prevent this from happening but to report on how incompliant people are. So if you have a policy to add tags to your resources so that you can do billing, you can either prevent them from doing that or you can just report who's notusing tags and then you can deal with that offline. Another policy you can implement in your company is around physical access. We talked about people walking away from their computers, not logged out, that they go for a snack or a break, and someone can go and sit down to a computer and start using the applications that they have access to.

Well, that's a security risk. And so this is a policy that you can put in place to say, "All servers must be behind locked doors." The people who have access to those servers must be a limited set. Not everyone in the company All employees must lock their computers. The screen saver must be a very short timer. I once knew someone who worked in a bank, and the policy was that if they were away from their desk,they had to be locked off the computer. And someone walked by their desk and saw a logged in version of Windows, and they're not sitting in that seat. They could actually get in trouble for that. That's a disciplinary action. And so your company can have a policy around the physical access aspects of your accounts. Another thing that you can do is use Azure and Connect Health. So we're talking about security and basically preventing the risks within your identity system. Well, AdConnect is one of the key elements of your identity system.

It could be if you have an on-premises Active Directory and you have Azure Active Directory in the cloud, and you're using Azure Ad Connect to synchronise between them, you're going to want to know that it's operating correctly, that the roles that are being assigned to people within the on-premises ad are being synchronised into the cloud. This way, let's say somebody was to leave your company. You were to go into the onpremises ad and disable their access. If your Ad Connect is not working and isthrowing errors, well, then they're not going to disable access within Azure Ad and that person couldpotentially still log into their applications even after you've disabled them on premises. So a functioning AdConnect is one of the keys to a good secure system. And you want to use Ad ConnectHealth to ensure that that part of your security apparatus has been functioning correctly. So those are the policy elements. Those are things that you can, as a company,say, "This is what we want to do." But when we're talking about things within Azure, things within our technology, within our groups, within our applications, what can we do to mitigate some of these risks? So one thing you can do is to decide that you are going to follow certain standards. There are quality standards, ISO 9001, there are lots of standards out there. And so if you're going to be in non-compliance with those standards, that could be one way to take away risk from your systems. So if you're going to say the standard is our entire website is Https and there's going to be no pages that are not Https, that could be something that you just enforce as a standard that you're going to follow. Another thing you can do is have a strong testing group. You can have a person who does tests dedicated.

You can instil this value into your development team as well. You can do automated tests. So certainly, making sure that when a person comes with a particular privilege, they can't get access to section X is an important element. So it's one thing to say we can define a user, we can define a group, and we can assign them a role. But if your application is not honouring that's a whole, strong testing system, making sure you're testing individual locks on the doors of your hotel, so to speak,is one way to mitigate risk as well. Another general rule within security is don't reinvent the wheel, and so don't roll your own security. You don't even really need to have your own user ID and password system if you use something like Azure ad. So basically, don't resist the urge to come up with your own unique method of doing something. When there's a standard that exists, when there's an industry standard, when there's proven software that's been through hundreds of thousands of eyes, have looked over it and made sure that all the holes have been closed.

Fishing has always been a problem from the very early days. I can remember hearing people calling into customer service and saying hi, I'm John Doe, can I reset my password? And the customer service is just doing it. So teach all of your employees not to be so easily phished, not to click on links in an email, not to basically believe people who they say they are over the phone. Hi, This is Bob from IT Support. I need your password because I'm trying to do something. Oh yeah, Bob, here's my password. That will be a powerful way to ensure that people do not gain unauthorized access to systems. Security is best done in layers. So instead of having a single fence around your application and then absolutely no security whatsoever, havingyour not only username and password, multifactor authentication rule-based, security network, and security groups, makes sure that your security is basically End-to-end and does sort of full coverage. So https encryption, data encryption, ensure your columns are encrypted, perhaps use the always encrypted within SQL data clients, and so on. So, the more security you can implement, the stronger your application becomes incrementally.

Because even if someone figured out a username and password that they couldn't do anything with, that there was no way to elevate their permissions, that there was no way to jump to other systems, your layers are what will save you. You don't have to do it for every single user, but if you use the conditional access as being one where somebody's logging in from outside of your office using a new device from a far-off location, some of these suspicious actions can enable MFA or just deny the service entirely. Privileged identity management is also a relatively new feature of Azure Ad. And so it is that people who have administrator and super user type permissions are the ones that are forced to go through MFA. But regular users who have the low-level read-only contributor access permissions don't. So that's a smart idea is to only force the administrative levels to go through the additional identity. And there's a feature we haven't talked about called Advanced Threat Protection, which is more of an intelligent active protection against your account and it can actually detect that there's a hack going on in real time. Somebody is trying to brute force the guest pass password. We've got suspicious activity coming in. It looks like a system that's logging in using a person's user ID and password and enabling ATP. There's obviously a cost for some of these things, but the more that you're able to do, the less likelihood that we have some of those.

3. *NEW* Azure Blueprint

So we've seen with Role Based Access Control,or RBAC, you're able to restrict the permissionsgranted to certain roles and those users who are assigned to those roles. And in this way, you're able to enforce your company policy on who does or does not have access to resources on Azure. Now that's RBAC. Now, there are other more sophisticated ways of implementing governance on Azure. One is called Azure Policy, and we can see it on screen. We can also search for the word "Policy" and you'll be given the Policy Service. Now, the concept of Azure policy is that you can either choose from hundreds of predefined policies or even create your own. And we'll do that in a second. But we can see here that we gounder definitions that you can scroll down. You'll be able to scroll down for days. There are literally hundreds of predefined policies. Now, what are these policies? You can see policies relating to almost all of the Azure Services. So let's say we want to restrict who has access to SQL Server. I'm going to pull this out so we can read it.

So I just entered SQL Server in search,and we can see that one of the policies is to deploy threat detection on SQL Servers. Deploy advanced data security on SQL servers. So you can implement a policy that states that all SQL Servers in the subscription must have threat detection enabled. So if I click on it, I can see that it is a JSON definition and similar to an Arm template. This is a predefined format and is kind of readable. We can see if the type equals MicrosoftSQL Servers deploy, if not, Security AlertPolicy and make sure it's enabled. And that's what the rule definition is here. We can see the deployment template. The Arm template is embedded as well in terms of deploying a Security Alert policy. So it's an ARM template wrapped within almost an if then statement, as we can see here.

So, if your interests are in virtual machines, you can basically have a rule that says all SQL Servers must have this, and not only make that a rule, but you can enforce that rule. For instance, you can type in Virtual Machine and you can say Enable Azure Monitor for VM scalesets. Azure Backup should be enabled for virtual machines. As a result, these are simply built-in policies that you can choose from and either enforce or audit. Auditing it would just make it show up on a reportand then you can take manual action to determine if, in this case, a virtual machine is even qualified to have encryption and what you're going to do about it. So sometimes you just want to audit a policy and not enforce it. But that's not all. You can create your own policy. So if this is not quite right, let's say one of these built-in policies is just a little bit off of what you want, you can create a policy definition of your own. So basically, Azure policy is pretty cool. This enables you to impose these extremely creative and complex rules on your Azure account.

Design for Risk Prevention for identity

1. What is Risk?

So in this video we're going to take one of these many predefined policies and we're going to assign it to our account. So, first, the policy I'm going to choose is called the allowed virtual machine size SCOOZ. I type the letters SKU into the search and I can see there are three options and one of them is the one that I want. Now, I'm going to scroll into the JSON here and we can see that the policy rule is here. We're going to try to read it. It says if all of the resource types are equal to Microsoft Compute Virtualmachines and the virtualmachine name is not in the predefined list of allowed SKUs, then deny. So this policy is basically going to stop any arm deployment, even through the portal or any API, if the list of SKUs is not matching. So I'm going to say it appears on the top. Now, luckily there is a wizard type interface, so we can drag and drop and click our way through this. The first question we have is the scope. Now there are several scopes, right?

This subscription that I'm in is part of what's called a management group. And so I could do a management group scope, but I could also assign the scope to the specific subscription. So I could, at this point, say select. And this policy would then apply across the entire subscription. I can also be more granular and pick a specific resource group called the AZ Test Group that I created previously. As a result, this policy would now only apply to the Aztest group. I can also specifically exclude resources from this assignment, so I can apply to the entire subscription except for a particular resource group. So we're going to leave all these policies enabled. This is me that's creating this. Now, we do have to go into what are called parameters. Remember, the policy is going to look up a list of acceptable skews, loud SKUs from the A list. And this is the list. So if I click on the drop down, I will see all of the instance sizes that are available. And so let's say I don't want any basic SKUs. I will allow a one, a two, a three, a four, and then the DS. I won't allow the B's to D. Of course, this is going to be very restricting. The whole purpose of this is to restrict the people who are going to be affected by this policy to only selecting SKUs that I allow because some of these SKUs are quite expensive. I'm not sure how much a D-48 server costs, but if you told me it's $10 per hour, I wouldn't be surprised, would you? Some of these servers can be quite expensive. So I chose 31, which are the A series one to four and the D series one to four. I can say review.

Now, you can see on the remediation screen that it says this assignment will only take effect on newly created resources. Existing resources are not going to be affected unless I run this policy as a remediation task. So basically we'd have to go back to this and then audit and check my existing VMs that don't work,so let's say review and create, and we'll say create. So the creation of the policy assignment succeeded. If I go under policies again and under assignments, I can see that the allowedvirtual machine SKUs is a policy. There's only one policy associated with it,and it's in the compute category. Now, to show you the effect of this, if we were to then this policy is active, right? If we were to go into creating a virtual machine, we're going to choose the test group that we put the policy against, give it a name, and the image doesn't matter. This doesn't matter. What does matter is the list of sizes. So I'm going to say CL sizes.

Now we do not allow the B series virtual machines. So if I select B two S or B four Ms, then we know that that is not on the allowed list of SKUs. So I'm going to just skip through here, disable diagnostics. And if I get to the review screen,the validation is going to pass because I selected all of the correct requirements. When I click Create, when it does go to deploy the virtual machine, we would expect an error. We expect that it has a policy violation, and I'm going to create that and test that. All right, so we got a pop up saying the resource was disallowed by policy, and it tells me the policy assignment is the allowed virtual machine skew. So even the error message tells me that this is not allowed. And we can see it listed as forbidden in the deployment details. So this is working exactly as expected. Azure policy has basically forbidden me from choosing a size because it's not allowed by my company policy. But you can see that you can be quite creative with Azure, your policy. You can create your own custom policies, modify existing ones, or use some of the hundreds and hundreds of predefined ones that can enforce your company's governance policies on your subscription or even on specific resource groups.

2. Mitigating Risks with Identity

Now it's quite easy to imagine that over time you'll come up with a standard list of company policies. You have custom ones or the ones that are built in that you want to be enforced. You're also going to have a standard set of roles within our back. You're also going to have access to armtemplates within the template directory. All of these things can be packaged together into what's called an Azure Blueprint. As a result, Azure Blueprints aid in the creation of new environments and subscriptions. So if you're working in a multi-subscription environment where each major team, each major business unit has its own subscription, you can set up a standard company subscription that you spend a lot of time and effort creating, all of those things that are required in terms of roles, policies, templates, groups. And then it's just a matter of copying and pasting to get to each new subscription you need to create. So these are called blueprints. Now if we go into the Azure portal and we search for blueprints, you can search for the word blue and blueprints come up. We can see that Azure Blueprints is a service. So, once again, blueprints are a collection of artefacts that allow you to quickly create subscriptions that adhere to company policy. So you start off by creating a blueprint.

So this is where you can upload your Arm templates. You can upload your custom policies. You can assign your policies. Do your custom role stuff and all these resourcegroups. Let's say you have development, staging, production, and resource groups all set up and ready to go. And of course, then once you've got that template, you can apply the blueprint to one or more subscriptions, get them up to the company standard, and then you can see which subscriptions are using which blueprints. So let's create a blueprint. I click the "create" button. Now we can start with a blank blueprint and that would probably be most appropriate for a lot of companies, or there are some sample blueprints. So we can see that Azure has a security benchmark.

There are Australian government blueprints, Canadian federal blueprints, US government blueprints, FedRAMP, HIPAA for health industry compliance, and some ISO ones. So, if any of these apply to you, you can read this and see if thesePCI policies and role definitions are appropriate for you. So, for instance, we can go into the United Kingdom official, give it a test name, and we have to choose where the blueprint is deployed. Again, the blueprint would be deployed at the top level if you want the management group or you can deploy it to a single subscription. But this limits where you can deploy it further. So the management group is going to be where you're likely going to want to put that. But if we look at the artefacts of UK policy, the UK Blueprint, we can see the interesting ones are the locations. So they predefined UK South and UK West as the only two locations allowed for both resources and resource groups. So quite clearly, for a UK official blueprint, there is going to be one policy that is going to be enforced, which is that the resources have to be within the geographical boundaries of the United Kingdom. There's also transparent data encryption, threat detection, antimalware extension, etc.

I'm going to discard this and go back into creating. Most companies will probably start with a blank blueprint. I'm going to call this the first blueprint. And this can be sort of some policies.And we said that this has the scope of a scope to a Blueprint.And so we'll put this in the measure group level. Now we have sort of a blank slate where we can go and add again, roles, groups, policies, arms, templates, so I can say add artifact, choose from the list. So the policy assignment that I want,I'm going to want the SKU one. I can choose, just as we just did, the allowed virtual machine SKUs. And then we can choose to pre-populate it or we can say when the person is assigning the blueprint,they can choose which SKUs are to be populated. And I'll just add a resource group as an example here. So put your name up there. So let's call this a production group resource group name. This can be prodded and location-specified at the time of assignment. And we can even have resource tags in here. So you can see, it's very easy to sort of set up your template and at that point, enforce your company defaults on your subscriptions that you're going to be creating for other parts of your organization.

3. NEW Azure Blueprint

Now it's quite easy to imagine that over time you'll come up with a standard list of company policies. You have custom ones or the ones that are built in that you want to be enforced. You're also going to have a standard set of roles within our back. You're also going to have access to ARMTEMPLATES within the template directory. All of these things can be packaged together into what's called an "Azure Blueprint. As a result, Azure Blueprints aid in the creation of new environments and subscriptions. So if you're working in a multi-subscription environment where each major team, each major business unit has its own subscription, you can set up a standard company subscription that you spend a lot of time and effort creating, all of those things that are required in terms of roles, policies, templates, groups. And then it's just a matter of copying and pasting to get to each new subscription you need to create. So these are called blueprints.

Now if we go into the Azure portal and we search for blueprints, you can search for the word blue and blueprints come up. We can see that Azure Blueprints is a service. So, once again, blueprints are a collection of artefacts that allow you to quickly create subscriptions that adhere to company policy. So you start off by creating a blueprint. So this is where you can upload your ARM templates. You can upload your custom policies. You can assign your policies. Do your custom role stuff and all this resourcegroupstuff. Let's say you have development, staging, production, and resource groups all set up and ready to go. And of course, once you've got that template, you can apply the blueprint to one or more subscriptions, get them up to the company standard, and then you can see which subscriptions are using which blueprints. So let's create a blueprint. When I click the "create" button, Now we can start with a blank blueprint and that would probably be most appropriate for a lot of companies, or there are some sample blueprints.

So we can see that Azure has a security benchmark. There are Australian government blueprints, Canadian federal blueprints, US government blueprints, FedRAMP, HIPAA for health industry compliance, and some ISO ones. So, if any of these apply to you, you can read this and see if these PCI policies and role definitions are appropriate for you. So, for instance, we can go into the United Kingdom officially, give it a test name, and we have to choose where the blueprint is deployed. Again, the blueprint would be deployed at the top level if you want the management group, or you can deploy it to a single subscription. But this limits where you can deploy it further. So the management group is going to be where you're likely going to want to put that. But if we look at the artefacts of UK policy, the UK Blueprint, we can see the interesting ones are the locations. So they predefined UK South and UK West as the only two locations allowed for both resources and resource groups. So quite clearly, for a UK official blueprint, there is going to be one policy that is going to be enforced, which is that the resources have to be within the geographical boundaries of the United Kingdom.

There's also transparent data encryption, threat detection, antimalware extension, etc. I'm going to discard this and go back into creating. Most companies will probably start with a blank blueprint. I'm going to call this the first blueprint. And this can be sort of some policies. And we said that this has the scope of a scope to a Blueprint. And so we'll put this at the measure group level. Now we have sort of a blank slate where we can go and add again, roles, groups, policies, arms, templates, so I can say add artifact, choose from the list. So the policy assignment that I want, I’m going to want the SKU one. I can choose, just as we just did, the allowed virtual machine SKUs. And then we can choose to pre-populate it or we can say when the person is assigning the blueprint, they can choose which SKUs are to be populated. And I'll just add a resource group as an example here. So put your name up there. So let's call this a production group resource group name. This can be prodded and location-specified at the time of assignment. And we can even have resource tags in here. So you can see, it's very easy to sort of set up your template and, at that point, enforce your company defaults on your subscriptions that you're going to be creating for other parts of your organization.

Study with ExamSnap to prepare for Microsoft Certified: Azure Solutions Architect Expert Practice Test Questions and Answers, Study Guide, and a comprehensive Video Training Course. Powered by the popular VCE format, Microsoft Certified: Azure Solutions Architect Expert Certification Exam Dumps compiled by the industry experts to make sure that you get verified answers. Our Product team ensures that our exams provide Microsoft Certified: Azure Solutions Architect Expert Practice Test Questions & Exam Dumps that are up-to-date.