We'll come back with more.
Or just killing your best practice questions.
And here is another one.
You are the best team lead and you can do it too incorporated a member of your team wants to troubleshoot
a problem on an easy to instance launched by an older killing group.
So you have one of the two instances launched by your group and one of that and one of your team members.
He wants to troubleshoot this easy to instance for a specific problem.
So what's the problem.
The problem is causing auto scaling group to launch new instances based on a dynamic scaling policy
what's known as calling top policy that's the on demand that's even based.
You want to make sure that all killing will not continue to launch additional instances because of this
or due to some troubleshooting planned activities.
How can you carry out the required troubleshooting while ensuring it's getting will not trigger alarms
and launch new instances and you have to choose two possible ways to do that.
Eg move the instance into standby mode and carry out the troubleshooting.
And you know this one is correct because usually under the skin in Group A healthy instance is yes it's
in service.
If you take it to stand by you what happens it will still be under the umbrella of the orders killing
groups a lot of killing is still encompassing these.
But it will be doing your health status on health checks on the inservice ones and not on the stand
by which means you can stop it restart it installs things stock applications do whatever you like without
the auto scanning determining that this one is unhealthy.
We have to terminate it and launch a new one.
You cannot insure that.
And this is wrong.
See.
Otis King will continue to launch two instances once you start your troubleshooting activities.
Well it depends on how you do it.
So this is too generic of a statement.
You can suspend all the screening process temporarily and this is also correct.
This is a fact that you can suspend doctors can process them temporarily just analysis.
You can do this for any.
You can move the instance into standby carry out the troubleshooting and then put it back once done
B is incorrect.
You can insure that C is incorrect because you can stop all the scaling from considering that you're
easy to instances that you are troubleshooting is unhealthy and launching new instances and D is correct
because you can do that you can suspend all this killing group.
And the correct answers are A and B moving an instance from inservice to stung by state keeps it managed
by the authors getting process.
But it does not count towards the active instances or just getting process will stop cheeking for the
health of the instances that are in standby and that allows you to troubleshoot stop start do whatever
you want.
And this is important getting troubleshooting or making changes to your easy to instances without having
to scan and consider them as unhealthy because of trigger events or alarms.
You can also suspend the auto screening process for some time if you have or need to but you need to
keep in mind that it no longer can scale out or skill and so the longer that period you are suspending
it means you are jeopardizing or putting your workload and production environment at risk because it
cannot scale out what's killing scale out means it can impact the availability of your services skill
and if it cannot screen that means you have more to insist that you don't need to be physically more
cost.
Another question your administrator not just that one of the instances launched by auto scaling process
is showing a status of impaired.
So one of the instances under your auto screening group that was launched on the largest killing group
is shown a status of impaired.
What does that mean.
That means it has detected a hardware or software problem on the physical host where the easy to instance
exists and is willing to terminate or stop the instance depending on the type of the bookstore that
you have.
And there is a status check process will report this to auto scaling process.
So it is impaired.
And what will happen next when it is time for the easy to status easy to service to send to a status
check to go to scaling.
It will inform it.
That is no longer an issue.
It is impaired What action would all descaling take one's status checks report the instance status as
impaired to what would auto Skilling take once they're easy to.
So once that is reported to auto scaling What is the action taken by auto scaling it will launch a new
instance immediately then work the impaired one for replacement B it will mark the instance for termination
terminated then launch a replacement.
See it will do not do much the existing instances under that water skiing group can take the hit of
losing one instance the easy to statistics do not count towards the health of the Skilling launched
instances.
Of course this is wrong because that's the mean or default mechanism for getting to know about the health
of the outer getting group instances.
It will not do much.
This is also wrong because auto scaling is all about taking care of two instances increasing decreasing
scaling out getting in based on the need.
It will mark the instance for them and so now that the answer is between any here it says it will launch
in your instance immediately then mark the impaired for replacement.
Besides it will more of instance for termination terminated then launch a replacement and B is the correct
one.
Why.
Because you need to get rid of the bad apples first and been replaced with a good apple.
That's how it works.
But Apple is not helping you because it will not be serving your production traffic and then you get
a new one.
If it was rebalancing that's another story because you have all good apples.
I can take one from you until I give you one and then I take the one I want.
Right.
So B is the correct answer.
And the differential for this question by default or just getting use easy to status checks to determine
the status of its launched etc. and since that's the default.
What else can I have the Albee's if I choose to combine easy two plus Elby or Elby depending on how
many I define and there that are just getting grouped any status for the two instances reported by the
easy to status checks other than running.
Will it mean that other scaling will mark the instance for replacement terminated and then launch a
new one.
If areas determines a hardware or software problem or on a host it will mark all instances with a status
impaired and schedule them for termination.
Or can we stop them.
So the ones that have abs backed data stores.
Right.
So next one you have designed a highly available A.W. solution for a two tier web application across
two availabilities zones.
So you have a two tiered web application across to every meeting on of all of these on one every bit
is on two and a half here.
Web slush up and a have here with slush and then what do I have else in there.
It is on a database and it the debates and that's what we call a two tier web app in one layer and it
in another layer using that group and then he'll be to balance the front end with zero.
So there is also an auto scaling group and just getting loop has a load balancer defined to load balance
among the Web or the player when deployed.
Administrators noticed that one is he does not have any easy two instances your administrator noticed
that there are no easy to instances whatsoever in one area.
It is only to say easy one launched by the oldest killing group checking the instances health checking
the instance health.
He could not find any issues with easy instances in the Skilling group or he will be so all descaling
or he'll be both are showing the registered instances as healthy.
So now why I do not have two instances here.
What would be your next step towards finding out the root cause why I dont have the scaling initiated
is it two instances in these really beautiful a chick that the plastic look balancer has a public subnet
defined in each of the cities on this one is wrong.
Why have you think about it for two or three seconds.
This is saying check that the elastic like balancer has a public subnet defined in each of them it is
on to find out whether this one is relevant or not what is the problem.
The problem is I dont have any easy to instances in these I believe it is on.
So why should I care if they will be.
So now why should I now care if they will be a public servant here or not.
I dont have any sequences.
If the question was you have easy to incenses it is on one but they are not receiving any traffic.
Then I would think about a good balancer but I dont have easy two instances so I should worry about
having two instances.
Then I monitor traffic and see if they will be sending them traffic or not.
So thats why this one is wrong.
We check that the auto scanning group is defined in each availabilities.
So this one is suggesting maybe you did not define subnets in these availabilities on under the old
Terschelling group and this is a potential correct answer.
See the other two See create a new launch configuration with detailed monitoring on in-situ instances.
Again this has nothing to do with monitoring.
I dont have two instances in everybodys on one at all.
So its not about monitoring.
Thats why this is wrong.
The you cannot use you will be with auto scaling.
They are not compatible services so you can't use plastic load balancer with auto scaling.
I can use the albuterol skinning group and that's what we have been talking about for hours and hours
so be is your correct answer is incorrect because the problem is not with ill be covering both.
Is it is that no instance in one of the two limit is.
B is correct because all this killing is a service responsible for launching or tell me anything instances
see is incorrect because this has nothing to do with details versus basic monitoring and these incorrect
because they can be used together.
Ill be.
And or just get in group and the correct answer is B quick refresher or just getting groups are specific
to adhesion and killing Skilling group can be defined in multiple availability zones but you have to
select manually or if you have automation tools you have to define subnets in that available zone one
or more in order to define what the Skilling group in that it is on and skin can kill out or in in those
I believe it is on.
All right.
So let's take a break and I will see you in the next lecture.
And still with all the in group scenario based practice questions I will see them.