domain six was all about the management plain and business continuity.
Let's underscore some of the key points in this model. The management playing itself is important. You need to make sure you secure it.
Strong authentication using multi factor authentication and token expiration are techniques to do this. Make sure you apply the principle of least privileges and leverage role based access control capabilities that your cloud provider will give you.
Business continuity is different in the cloud. You have to assume failure and take a risk based approach to appropriately mitigate those failures. This could mean taking advantage of a cloud providers capabilities to fail across zones or geographic regions. It's also important that you consider
fail over only in the most critical cases
to manage your costs and effort.
Question what is meant by data lock in the term lock in lock. It applies when you are contractually unable to export your data.
Exporting data out of a provider would require significant effort. Data exported can be used on Lea in the original provider services
or D. All of the above. The answer is only one of these, and the answer is D's. So lock in essentially means you are locked into using that provider could be contractually unable to get the data. It could be that the format of the data is only useful from a providers perspective or require a lot of efforts, such as the case with
cross provider Fail Over.
And we talked about the extreme costs and establishing cross provider fail over because each cloud provider does things in a slightly different way. And so you need to maintain an ability to produce your infrastructure and build in your applications across multiple different providers paradigms at the same time.
Which of the following must a cloud customer include in their business? Continuity planning?
Determine out a guarantee availability in the disaster recovery region by discussing your d our plans with the vendor. Determine how the I s provider will fix any availability issues in your application. Use contracts to ensure the disaster recovery does not result in a different jurisdiction to store and process data
or implement chaos. Engineering.
This is another one of those questions where there could be right answers. It's all about choosing the best answer in this case. We're really focused on the word must. A cloud provider include in their business continuity, planning
and the answer would be a You need to determine how to guarantee availability and disaster recovery region by discussing your disaster recovery plans with the vendor. And it's very important that the disaster recovery region that you're targeting
has the capacity to support the work clothes that you're going to be moving into that region in the event that a disaster takes place. The cloud provider will not determine how to fix your application availability issues, especially in an I S model that's on you to figure out
they could help you figure out why is the network not working? Maybe the virtual machines not coming up,
but your application specific things is something that you're going to own
using contracts to ensure disaster recovery does not result in different jurisdictions. And this consideration is really important when you have a SAS model where you don't have direct control over the jurisdictions for disaster recovery, and it is also going to be important when you have 1/3 party managing a private cloud or a community cloud.
But again, the key word here is must a cloud provider, including their continuity, planning
and that's not something people must do. There's only certain situations where an individual is going to do that. Finally, implementing chaos. Engineering can be a great idea in certain circumstances, but the reality is at this point in the cloud maturity spectrum that we're at as an industry chaos engineering is used few and far between,
and that wraps up our domain. Six topics.
I hope you're enjoying what you're learning, especially as we start getting into more the technical aspects of cloud. I look forward to seeing you in the next module.