Exam SAP-C02 All QuestionsBrowse all questions from this exam
Go to Exam
Question 347

A company has used infrastructure as code (IaC) to provision a set of two Amazon EC2 instances. The instances have remained the same for several years.

The company's business has grown rapidly in the past few months. In response, the company’s operations team has implemented an Auto Scaling group to manage the sudden increases in traffic. Company policy requires a monthly installation of security updates on all operating systems that are running.

The most recent security update required a reboot. As a result, the Auto Scaling group terminated the instances and replaced them with new, unpatched instances.

Which combination of steps should a solutions architect recommend to avoid a recurrence of this issue? (Choose two.)

    Correct Answer: A, D

    The issue arises because the Auto Scaling group replaces instances after a security update that requires a reboot, resulting in new, unpatched instances being created. To avoid this, actions must ensure instances are up-to-date and not unnecessarily replaced. Modifying the Auto Scaling group to target the oldest launch configuration for replacement ensures that the oldest, and potentially least secure, instances are replaced first, which can help maintain a more updated and secure environment. Creating automation scripts to patch an AMI, update the launch configuration, and invoke an Auto Scaling instance refresh ensures that new instances launched by the Auto Scaling group will be up-to-date with the latest security patches, thereby solving the root cause of the issue. This approach aligns with maintaining security compliance and operational efficiency.

Discussion
LazyAutonomyOptions: AD

Terrible, terrible question. All answers are technically wrong. But the answer they want is A & D. C & E - There is nothing in the question to suggest any requirement that warrants the introduction of a load balancer of any kind. Is there any inbound traffic? Maybe, maybe not. Even if the traffic is inbound, what if they've implemented DNS-round-robin "load balancing" directly to the EC2 public/private IPs (ie no need for ELB)? There's also nothing to suggest that the "traffic" is consistently the same 24x7, which means they may want the ASG to periodically scale-in and scale-out instances dynamically e.g. in response to EC2 CPU usage. Enabling termination protection will also prevent the ASG from replacing genuinely unhealthy instances, defeating the purpose of having an ASG in the first place. So that leaves us with A, B & D.

LazyAutonomy

But why is ASG terminates those instances? What's happening is that ansible/puppet/chef/whatever IaC processes are causing OS updates to be applied long after the default 300s health check grace period ends, which means new kernel, new glibc, etc packages are installed, requiring a reboot for the change to take effect. During these reboots, EC2 ASG thinks the instances are unhealthy (EC2 ping health checks will fail) and replaces them with new instances instantiated from an old unpatched AMI. If you still have lingering doubts about eliminating C and E, then consider the fact that deploying an ELB and turning on ELB health checks in the ASG wont make a difference. A rebooting instance will still get terminated by ASG because EC2 + ELB health checks will fail during the reboot. The instances will probably die faster. So the problem isn't the reboot. The problem is ASG killing rebooting servers and replacing them with unpatched servers.

LazyAutonomy

The simplest solution would be to just increase the health check grace period to something large, like 1 hour, and make sure IaC patches & reboots new instances within the grace period. That will buy you a month before the next senseless EC2 massacre. But nothing resembling that option is being offered here. The next simplest option is to protect individual EC2 instances from scale-in while they're being rebooted. But nothing resembling that option is being offered here either. So we're left with somehow updating the kernel/glibc/etc that's baked into the AMI itself, thus altogether avoiding the need for new instances to reboot in the first place (let's just ignore livepatch methods for the moment). Yes, we all know that launch configs can't technically be updated in place (and AMIs can't be "patched" either), but if we eliminate D for that reason then we're left A & B, neither of which mention new AMIs or launch configs at all.

LazyAutonomy

Can we eliminate B? Yes. I can safely assume the intention of B is to create a new ASG with the same old launch config + existing AMI. The behaviour of new ASG will match the old ASG. Any instance rebooted after the health check grace period ends will get terminated, even during a "maintenance window" (which is not a thing). Option A wants to modify the termination policy of the existing ASG to "Oldest launch configuration". That's unnecessary but harmless. The default termination policy will do this anyway, and AZ re-balancing always takes precedence even when using a non-default termination policy. https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-termination-policies.html "Amazon EC2 Auto Scaling always balances instances across Availability Zones first, regardless of which termination policy is used"

LazyAutonomy

So where does that leave us? A - does nothing meaningful at all, but at least it's harmless. B - working instances will all die on reboot during the "maintenance window" (all at the same time? lol) C - working instances will die faster when rebooted D - perfect, except it technically isn't possible to "update" launch configs or "patch" AMIs in place. Bummer. E - broken instances will never get replaced, defeating the purpose of ASGs. I think it's safe to conclude the author of this question was just really sloppy with how they worded option D. To avoid a re-occurrence of this issue, I am compelled by common sense to adopt a more relaxed interpretation of D. If I infer that the intent of D is New AMI + New launch config + Invoke ASG refresh, then I don't actually need to do anything else. D will be enough to prevent re-occurrence. But I have to pair it with a second option. So I'll pair it with A, which sounds good but actually does nothing and is harmless.

LazyAutonomy

Answer: A + D. Terrible, terrible, terrible question.

yuliaqwerty

A and C. D is wrong launch config can't be updated https://docs.aws.amazon.com/autoscaling/ec2/userguide/change-launch-config.html

blackgamerOptions: AC

The answer is A and D.

ishpalOptions: CD

https://www.examtopics.com/discussions/amazon/view/68855-exam-aws-certified-solutions-architect-professional-topic-1/

AtownOptions: CD

CD Answer is worded a bit poorly but this is correct.

cypkirOptions: CD

Answer: C D

DgixOptions: AD

Sometimes I really hate the AWS exam writers. This questions is on a level to which even they shouldn't plumb. All of the alternatives are wrong in some way. So you have to guess. Whoever wrote this should be fired. D, since it addresses the AMI (though "update" is not what you do with an AMI). And then A, for the reasons LazyAutonomy gives. But wow do I sometimes hate the exam writers. It's one thing to force us to focus on minute details; it's quite another to subject us to their own sloppiness.

career360guruOptions: CD

Option C and D

awsamarOptions: AC

D is out AC then

awsamar

Option D is out because it says to "update launch configuration" AWS Auto Scaling launch configurations cannot be updated directly. Once a launch configuration is created, it cannot be modified; instead, a new one must be created to reflect any changes

J0n102Options: CD

Answer: CD

053081fOptions: AD

While options A and D are considered the most suitable (and safest) answers to the question's requirements, they may not completely solve the problem. For example, if there are 10 instances in an Auto Scaling group (No.1, No.2, No.3 ... No.10), and two of them are unpatched, the Oldest Launch setting would prioritize replacing the older unpatched instances. However, there's a possibility that only No.10 might be scaled in, leaving No.9 still unpatched and active in the group.

seetptOptions: CD

CD i think

titi_rOptions: AC

A and C.

adelynllllllllll

Answer: A, C https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-tutorial-update-patch-windows-ami-autoscaling.html

JMAN1Options: DE

A and C does not prevent EC2 to be terminated by security patch. B is very burdened(create new group each time?). D is poorly worded as it says 'update configuration'. But I will go with D E.

JMAN1

Sorry. E does not prevent terminating from patch.Let me go with C D.