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

A company is hosting a monolithic REST-based API for a mobile app on five Amazon EC2 instances in public subnets of a VPC. Mobile clients connect to the API by using a domain name that is hosted on Amazon Route 53. The company has created a Route 53 multivalue answer routing policy with the IP addresses of all the EC2 instances. Recently, the app has been overwhelmed by large and sudden increases to traffic. The app has not been able to keep up with the traffic.

A solutions architect needs to implement a solution so that the app can handle the new and varying load.

Which solution will meet these requirements with the LEAST operational overhead?

    Correct Answer: D

    To handle the new and varying load on the REST-based API with the least operational overhead, it is most effective to create an Application Load Balancer (ALB) in front of the EC2 instances. This approach allows effective distribution of incoming traffic across multiple instances, ensuring that no single instance gets overwhelmed. Additionally, moving the EC2 instances to private subnets enhances security while the ALB takes care of managing the traffic. This solution requires minimal changes to the current setup and does not involve significant developmental refactoring or the need to manage container orchestration frameworks, making it the option with the least operational overhead.

Discussion
EricZhangOption: A

Serverless requires least operational effort.

lkyixoayffasdrlaqd

How can this be the answer ?? It says: Separate the API into individual AWS Lambda functions. Can you calculate the operational overhead to do that?

scuzzy2010

Separating would be development overhead, but once done, the operational overheard (operational = ongoing day-to-day) will be the least.

24Gel

disagree, ASG in Option D, after set up, operational is not overheat as well

24Gel

i mean Option C not D

24Gel

never mind, A is simpler than C

Jay_2pt0_1

From any type of real-world perspective, this just can't be the answer IMHO. Surely AWS takes "real world" into account.

dqwsmwwvtgxwkvgcvc

I guess multivalue answer routing in Route53 is not proper load balancing so replacing multivalue answer routing with ALB would proper balance the load (with minimal effort)

joonccoOption: C

Suppose there are a 100 REST APIs (Since this application is monolithic, it's quite common). Are you still going to copy and paste all those API codes into lambda? What if business logic changes? This is not MINIMAL. I would go with C.

scuzzy2010

It says "a monolithic REST-based API " - hence only 1 API. Initially I thought C, but I'll go with A as it says least operation overhead (not least implementation effort). Lambda has virtually no operation overhead compared to EC2.

Jay_2pt0_1

A monolithic REST api likely has a gazillion individual APIs. This refactor would not be a small one.

aviathor

Answer A says "Separate the API into individual AWS Lambda functions." Makes me think there may be many APIs. However, we are looking to minimize operational effort, not development effort...

chathur

"Create an AWS Lambda function that reacts to Auto Scaling group changes and updates the Route 53 record. " This does not make any sense, why do you need to change R53 records using a Lambda?

Vesla

Because if you have 4 ec2 in your ASG you need to have 4 records in domain name if ASG scale up to 6 for example you need 2 add 2 records more in domain name

liquen14

Too contrived in my opinion, and what about DNS caches in the clients?. You coul get stuck for a while with the previous list of servers. I think it's has to be A (but it would involve a considerable development effort) or D which is extremely easy to implement but and the same time it sounds a little bit fishy because they don't mention anything about ASG or scaling I hate this kind of questions and I don't understand what kind of useful insight they provide unless they want us to become masters of the art of dealing with ambiguity

cnethers

Agree that D does not scale to meet demand, it's just a better way to load balance which was being done at R53 before so the scaling issue has not been resolved. Also agree A requires more dev effort and less ops effort, so I would have to lean to A... Answer selection is poor IMO

jainparag1

Dealing with business logic change is applicable to existing solution or any solution based on the complexity. Rather it's easier to deal when these are microservices. You shouldn't hesitate to refactor your application by putting one time effort (dev overhead) to save significant operational overhead on daily basis. AWS is pushing for serverless only for this.

www_Certifiedumps_comOption: D

The least operational overhead solution is: D. Create an Application Load Balancer (ALB) in front of the API. Move the EC2 instances to private subnets. Add the instances as targets for the ALB. Update the Route 53 record to point to the ALB.

cnethers

D does not scale to meet demand, it's just a better way to load balance which was being done at R53 before so the scaling issue has not been resolved. A requires more dev effort (not a consideration in the question) and less ops effort, so I would have to lean to A... Answer selection is poor IMO for this question ..

red_pandaOption: C

For me it's C. Answer A it's impossible. Can you imagine how much time do we need to refactor the application into n API/functions? Answer B and C make no sense. The only one is C, for me.

Helpnosense

Agree. Answer A is to turn monolithic application to micro service. The time spend on this work vs the time to creating ASG + Lambda code retrieving ec2 ip and update R53. Obviously answer C is least effort. D is wrong because just ALB without asg will not make any change to the load processing.

nkv_3762Option: C

C should be the answer A - IMO, it's not feasible given the entire application is a monolithic, so we can't just refactor to separate into Lambda functions. D - Since there is no mention of ASG, this is ruled out. This does nothing to address the high volume requests.

lasithasilva709Option: C

I choose C. A,B may need significant development effort to refactor D doesn’t address the major issue which is scaling

zolthar_zOption: D

Keep it simple, we can't assume if the API is a large/small application, the idea is make the least operational overhead and that is only add a ALB, We don't know the effort to move the application to a lambda, Answer is D

MoghiteOption: D

Response is D A- Requires significant refactoring of the application B- solution complex and requires containerizing application. C- The multi-value answer routings less flexible compared to using an ALB for load balancing.

subbupro

D is a perfect, least operation effort. C needs to write lamda func which is over head.

ahhatemOption: A

The questions requires least operational effort... Nothing mentions the dev work to refactor!

ahhatem

In addition, a monolithic REST-API does not necessarily require huge work to work effectively on lambda.... It depends on how it is written, might be very easy or very complicated!

higashikumiOption: D

To handle the monolithic REST-based API being overwhelmed by traffic with minimal operational overhead, the best solution involves placing an Application Load Balancer (ALB) in front of the EC2 instances and moving these instances to private subnets within the VPC. The ALB effectively distributes incoming traffic across multiple instances, preventing any single instance from being overloaded. Additionally, integrating Auto Scaling with the ALB ensures that the number of EC2 instances dynamically adjusts based on traffic load, maintaining performance and availability. This approach avoids the extensive development and refactoring efforts required by other solutions, providing a scalable and reliable setup with minimal changes to the existing infrastructure.

Malcnorth59

I am going to select D. If you look at what has been implemented, it effectively tries to do what an ALB + ASG does. Option A is attractive but I believe it is not the one with LEAST operational overhead. It requires a complete re-architecting and redevelopment of the solution whereas D can be done with minimal change by an operations team

qaz12wsxOption: D

I go with D

mifune

That solution would be ideal, except that the question asks for how to resolve the increasement of requests. An ALB does not scales, so C is the correct anwser.

SmartOption: A

There is a difference between development burden of refactoring and operational burden.

43c89f4

A. partial correct - because monolithic application, if EC2 are not handle i dont think Lamda can handle the traffic. i can go for D. - because of Multi-value, ALB, TG,ASG

VerRiOption: D

A will work, but not the least operational overhead.

mav3r1ckOption: D

Choosing option A — separating the API into individual AWS Lambda functions and configuring an Amazon API Gateway REST API with Lambda integration — does present a modern, highly scalable solution that could theoretically handle new and varying loads with potentially lower operational overhead once implemented.

mav3r1ck

There are several reasons why it might not be considered the best option with the "least" operational overhead in this specific scenario: Refactoring Effort: Transforming a monolithic application into a set of microservices or serverless functions can be a significant undertaking. It requires a thorough analysis of the existing application architecture, identifying logical separations between different parts of the application, and then implementing those separations. This process can be time-consuming and requires careful planning to ensure that the application continues to function correctly as a set of more granular services.

mav3r1ck

Development and Deployment Overhead: Initially, moving to AWS Lambda and API Gateway involves a different approach to application development, deployment, and monitoring. Teams may need to familiarize themselves with serverless architectures, adapt deployment pipelines, and implement new monitoring and logging solutions suitable for serverless environments. This learning curve and setup can introduce additional overhead before the benefits of reduced operational management are realized.

mav3r1ck

Testing and Debugging Challenges: Serverless applications, due to their distributed nature, can present unique challenges for testing and debugging. Ensuring that the application behaves correctly as a collection of independently deployed functions requires comprehensive integration testing. Debugging issues can also be more complex compared to a monolithic architecture, where the application components are more tightly coupled.

mav3r1ck

In contrast, option D — creating an Application Load Balancer (ALB) in front of the API and updating the infrastructure to better manage traffic through scaling and health checks — offers a balance between reducing operational overhead and implementing the solution with minimal changes to the existing application architecture. It provides an immediate solution to the problem of handling varying loads without the significant upfront investment in refactoring the application or the learning curve associated with adopting serverless technologies.