Exam AWS DevOps Engineer Professional topic 1 question 46 discussion

B - https://www.examtopics.com/discussions/amazon/view/8544-exam-aws-devops-engineer-professional-topic-1-question-129/

c is correct Benefits of the Lambda Approach: Fully managed, serverless processing. Scales automatically with incoming data. Reduces operational overhead and simplifies management. Provides a robust solution for real-time data processing.

C - Lambda is more operationally efficient and it out scales. It runs in parallel (multi-thread) to process Kinesis records, which would resolve the issue of the consumer falling behind.

Ans is C , key here is "MOST operational efficiency" , when compare EC2 vs Lambda , Lambda are more operationally efficient, with EC2 you need to operationally manage it like patching etc etc. though B will also fit , but Operationally efficient would be C with regard to application falling behind it can be achieved by lambda ParallelizationFactor , see AWS Documentation when you set ParallelizationFactor to 2, you can have 200 concurrent Lambda invocations at maximum to process 100 Kinesis data shards (though in practice, you may see a different values for the ConcurrentExecutions metric). This helps scale up the processing throughput when the data volume is volatile and the IteratorAge is high. https://docs.aws.amazon.com/lambda/latest/dg/with-kinesis.html

more efficient than b

B is the correct one.

I think the answer is B.

I changed my mind to B. The throughput problem is not from Kinesis Data Streams, but from the EC2 hosting Kinesis Data Streams. So we need to scale up the EC2 instances.

We need to use the in-built auto-scaling mechanism in Kinesis Data Streams to solve the problem.

Answer is B. We need to scale the Kinesis consumer application horizontally based on the CloudWatch metric. Answer cannot be C because replacing the Kinesis Consumer app with Lambda does not make the solution operationally efficient. Lambda could also throttle as the data is streamed faster into Kinesis Data Stream. Answer is not D because just my increasing the shards will not result in efficient processing on the consumer side. We also need to increase the no of instances and therefore KCL workers to propose the data from additional shards.

B. They are asking for operational efficiency. Converting the application to lambda may not be possible and is not efficient.

Why not D? D. Increase the number of shards in the Kinesis Data Streams to increase the overall throughput so that the consumer application can process the data faster. Increasing the number of shards in the Kinesis Data Streams is the most operationally efficient solution because it allows the consumer application to process the data faster by increasing the overall throughput of the data stream. This will allow the consumer application to keep up with sudden increases in data and prevent records from being dropped. It also does not require any changes to the consumer application itself, which can be more operationally efficient than modifying the application or converting it to a Lambda function. Additionally, increasing the number of shards does not require the use of additional resources such as EC2 instances or EMR clusters, which can be more expensive and complex to manage.

I go with C. Most efficient (C: because of the sudden spikes) vs fastest approach (B)

Refer to ohcn's comment.

Go with B

kinesis stream + lambda is better solution

1. https://docs.aws.amazon.com/streams/latest/dev/lambda-consumer.html 2. https://docs.aws.amazon.com/lambda/latest/dg/with-kinesis.html