High and won't come back.
So let's continue our scaling you know Ruby's practice questions.
Adventure
evil although Skilling launch configuration is created via the command line interface which easy to
monitoring will be enabled.
To the other scanning launch configuration is created via a command line interface.
Not it obvious console which easy to monitoring will be enabled.
A detailed basic C monitoring will not be any level of command line interface was used to create the
launch configuration the interface does not support creating launch configurations using command line
interface.
So this one is definitely wrong and this one is definitely wrong.
So another question is command line interface used to create launch configuration for the scaling.
Is that going to be detailed or basic what's the default.
Basically So we know if it was a console that would have been.
Yes that would have been the basic or every five minutes in the command line interface.
The details will be the default.
So this one is wrong and this is the correct answer
so is correct because the command line enable detailed monitoring.
White House counsel enables basic monitoring by default be incorrect because the basic is the default
for it console created launch configurations seems incorrect because monitoring will or can be enabled
if command line interface can is used.
Andy is incorrect because it does support that so it can allow you to configure the notion of relation
from the command line and the correct answer is.
A quick refresher when you create launch configurations for auto scaling groups using command line interface.
You have the detailed monitoring enabled by default whereas if you do that from the console then basic
manhunting are every five minutes is the default.
Keep that in mind when deciding the oldest killing policy for argument's killing.
Alarm frequency configuration.
It needs to match that of two instances in the launch configuration.
So now if you are given a question that says that the launch configuration was created by command line
interface what would be AWOS recommended setting for the cloud watch alarm.
Then immediately you know it is 60 seconds not 300 seconds not 10 minutes and not one hour.
So because the detailed monitoring will be enabled for the launch configuration that is configured using
the command line interface.
So instead of telling you all that they will only tell you that the command line interface was used
to create the launch configuration expecting that you know this is detailed monitoring and not the basic
monitoring next question.
You are the new architect and you can do it to incorporate that.
You have been assigned a task to design a highly available so high available fault tolerant it has architecture
for a web layer of a three tier application in an NWS region.
OK so you want highly available fault tolerant web tier of a three tier application in an either region.
It is required that the affiliate of an availability zone.
So now we're talking about the full tolerance and the high availability.
So if one of these is on feels would not affect the food high availability the full available of the
application under normal load the web requires 12 easy to optimize instances.
So this is very tricky now.
It is required that a failure of believe is if you lose one availability is on the failure of that system
would not affect the full availability of the application.
What is the full weight of the addiction that means the high availability of the application as well.
How would you think could be the solution keeping cost effectiveness in mind so you may have multiple
solutions you need to look at cost as well.
So you need to ensure that a figure of fun is on will not impact the high availability of the solution
or that we have.
And also the solution must be cost effective so if you have multiple options choose the one that will
cost less.
Lets look at the options.
A single region architecture fine single region is fine.
Use one or two Skilling group in two availabilities zones.
So what are the Skilling group Multi of celebrities on or just getting group into aggregate into these
loans with a minimum desired capacity of 24 compute easy to instances and use an elastic load balancer
that whoever it is owns to load balance between these two instances too.
Let's think about it now.
Is it commanding to launch a too easy otos killing.
So I have an auto scaling group that will have a design capacity of 24 is two instances computer optimized.
So that means it will try always strive to launch 12 and 12 to make it even and balanced between the
two it is on and define an elastic load balancer under the killing group that will look after load balancing
between the 24 instances and they will be will be also defined into availability zones.
Looks wonderful but what happens if you lose one of availabilities abilities on the other one has enough
instances to run the application right.
They said we have 12 normal load requires 12 two instances but would this have an impact on the full
high availability or the full availability of the application.
Yes.
So here I would expect for this even if I lose one of these on the solution will still although that
it will still be highly available means what.
Means more than one available it is on will be left even if I lose one.
So what's the minimum to give me that is 1 to 3 every bit is on.
So it is not the right one despite the fact it would be a single region architecture use one or two
scaling group in three availabilities on so that are just getting group in this case will extend across
three.
Not to have elevated zones with a minimum design capacity of 18 easy to optimized instances.
So 18 if the capacity is available in the free what will happen six will be launched here six will be
launched here six will be launched here.
Right.
So that is 18 use and ill be in the three of them it is on.
So define your be to the focus group and have it look after the three availabilities in this case to
load balance between the two instances.
Now lets see if this one is correct or wrong.
If I lose one I believe it is what happens.
I would have six here in six years that is 12 and that will give me high availability because we have
two availabilities zones left so the 6 plus 6 is 12 that is fine.
Hi everybody is not impacted and it is more cost effective than number one.
Why then.
Why.
Because this is only 18 were as this was 24.
So these have three checkmarks.
Its going to give me that well is two instances it will remain highly available and its going to be
cost effective See use route 53 and launch your web application across for availability zones into different
regions and use elastic load balancer and auto Schelling group in each region with the desired minimum
capacity of 8 easy to instances in each region.
So here this is saying that you have two regions and you will have two availability zones in each region
and use the route 53 as well.
So route 53 will be outside and redrafted 3 will look at the Albee's and they always have the oldest
getting groups in each region.
So I have an ill be here with auto scaling.
Ill be here with all the skin.
Now this let's see if I lose one of these and what happens it is the two instances in each other's getting
groups so this will be eight and this will be a total of 16 if I was one of them it is on I will have
four remaining.
No actually not four because if I lose one I get is on the other screening will kick in and try to launch
it all the 8 here if I have eight design capacity.
So I have an end to that 16 more than 12 but so this is 16 easy two instances and two others killing
groups.
Other groups dont cost money to help because they cost money.
Route 53 costs money.
So this is not cost effective.
Thats why I will rule it out.
You can't guarantee full availability in case of an easy failure and this is wrong.
You can't.
We just proved by B is that you can so the one that takes all the check all the all the boxes is B and
that's why this is the correct answer.
So is wrong.
Why.
Because it will work will not guarantee full age ain't an easy failure scenario only when everything
is on will be up.
If I lose one of the two B is correct because if one is the fails the other two would already have 12
easy two instances up and running.
And I believe it will be there as well.
C is wrong because it's more costly plus route 53 cost and to Elby cost and took 16 easy to instances
under normal operation and not a not 12 D is incorrect because you can guarantee full availability.
So the correct answer is exactly b the fresher option a would have met the requirement if it was not
for the maintain full high availability in the event of everybody's failure which indicates that the
architecture must be over a minimum of two every bit as.
Even in case of an easy failure.
So that implies the availability zone's solution.
Also the two entities on solution needs 24 is two instances as opposed to 18 in theory everybody is
on solutions.
This is why the three of them it is an option is preferred over the to everybody's own solution.
That's why we have Big B and not a next question.
You are the new architect.
You can do it too.
This is a tweak or at worst off the previous question.
So I think it's going to be faster than the other one you have been assigned the task to design high
available highly available faltering.
It is architecture for a web layer of a three tier web application.
In any ws region OK it is required that the failure of a very bit is on would not affect the full high
availability of the web application.
Two comments here before I continue here.
They said would not affect what if the question was would affect.
So that means to every bit is on is fine under normal load that requires 12 easy to instances.
How would you Arctic the solution keeping cost effective itness in mind using single availabilities
on auto scaling groups so here they are telling you the other groups should not span across it on each
of his own will have its own skill killing a single region architecture used to single every bit is
on auto scaling grouped into ISS with a minimum reserve capacity of 12 compute to instances in each.
So the total is 24 hour news and it'll be in the 2 availability zones to load balance between the two
instances.
So this is exactly similar like in the previous scenario or the previous previous question.
Except for the fact that we are using a single availabilities on auto scaling groups and not one or
just getting group mapping across what differences give me I have here desired 12 years or 12 but if
I lose one I lose the high availability so that's why I WILL NOT GO WITH be a single Reijer architecture
use every single Asie all these killing groups in three of these zones with a minimum design capacity
of 6 in each use an elastic lock balancer in three of elevated zones to load balance between the two
instances in three phases.
So that's exactly like the previous B in the previous question.
I have 6 6 and 6.
The difference is the artist and group were not spent across the three.
I will have an audio skinning group for the first one or this killing you for the second one of getting
them for the third one and then I haven't E-L be defined under these or just getting groups and they'll
be able to look after the instances in each of their energies on losing one.
I still have high availability and I have 12 which I need to be.
Is a correct answer unless if I have a better answer.
See yuzuru 53 and launch your web application across for Easy's into different regions.
We know that this one is more costly and you can not guarantee yes you can so be.
Again is the correct answer.
But here I'm just showing you that if they play with a single easy Monte easy or just getting grooves
should not cause you to freak out and find out OK what do you mean by this.
Just think about it.
Killing killing.
If it is in one of its own it will function when everybody is on.
If it is configured across is.
It will do its magic across the previous ones.
That's how easy it is.
Same thing Puriel be.
If it is defined in one if one if it isn't into the tracing you will be you have only one subnet defined
for the iel be one public subnet in and everybody's own will be will only load balance to two instances
in that it is.
You wanted to function in another area it is on.
Define another public subnet to that you be in that debate is on.
That's how it works.
So multi is the single azy should not freak you out as long as you understand that this is a region
confined service but it can be across.
It is not automatic to not deliberately stretch to cover other these zones.
That's a manual thing you need to do unless you are able to mention tools but still someone would have
clicked to stretch that or just getting group between Or just decide on its own.
So again B is the correct answer here.
The fact that you have now the full range even in case of an easy failure in this question and single
event zone auto scaling groups the added number of total easy two instances.
Two hundred and fifty or forty you need during normal load.
That's why when we went through 3 is easy and we set the desired in 86 6.
This is actually 150 percent of what we need.
What we need is actually 12.
Here I have 50 percent more.
This means if one of these on fails you retain 100 percent of what is needed and that's why we said
or the impact it should not impact your availability or high availability that means the same number
of required is two instances should be there.
What happens if you lost 2 to 80 zones and you have only 6 so normal operation requires 12.
Now you have only 6.
Does that impact your availability.
Yes it does.
Does it impact your response time.
Yes it does does impact how your auto scaling would function because the desired desired is 6.
It will not get any more launch any more is two instances.
Except if there was an on demand scaling policy configured that says for instance when they reach 75
percent you have to knock out.
You have to launch into two instances.
All right so let's take a break now and we'll come back to more auto scaling fun.
I'll see you then.