Exam AWS Certified DevOps Engineer - Professional DOP-C02 topic 1 question 100 discussion

The answer is B because: A few hours ago, I just finished the DOP-C02 exam. My score is 1000 points. This question has come up, I choose B.

why not C? because we just replace ONE ec2 with ONE lambda here. And no mention of aws lambda reserved concurrency or provisioned concurrency. In the question were are asked for 'MOST operational efficiency'. that's my two cents. Ciao

I think most people are missing the part where the question focuses on MOST operational efficiency. Lambda fits this purpose, as ww are not managing instances and Lambda can scale to meet throughput demands.

A, sounds a lot effort towards a different architecture solution. B, I don't think the insufficient kinesis throughput has can be resolved. C, adding lambda is a big change, no mention about the concurrency limit isn't clear mentioned in the question.

Answer is C. B - This solution improves the consumer application’s ability to handle increased throughput, but it still requires manual scaling of EC2 instances, which can involve some complexity and operational overhead. C - Using Lambda is obviously more Operational Efficient.

I think B makes more sence, because "the Kinesis data streams drop records before the records can be processed". It's not an intake throughput issue that needs more shards, but an outtake throughput issue. "Consumer Record Processing Falling Behind" "After you identify how far behind your consumers are reading, look at the most common reasons why consumers fall behind. Start with the GetRecords.IteratorAgeMilliseconds metric, which tracks the read position across all shards and consumers in the stream. Note that if an iterator's age passes 50% of the retention period (by default, 24 hours...), there is risk for data loss due to record expiration." "A quick stopgap solution is to increase the retention period." [...] "An alternative approach is to increase your parallelism by increasing the number of shards." "Finally, confirm you have an adequate amount of physical resources (memory, CPU utilization, etc.) on the underlying processing nodes during peak demand." https://docs.aws.amazon.com/streams/latest/dev/troubleshooting-consumers.html

B is a good choice The GetRecords.IteratorAgeMilliseconds metric in Amazon CloudWatch for Amazon Kinesis Data Streams measures the age of the last record returned by the GetRecords operation. Specifically, it represents the time difference between the current time and the approximate arrival timestamp of the last record processed by a consumer in milliseconds. Purpose: Measures the delay in processing data records from the time they are added to the stream to the time they are processed by a consumer. Scaling: If you observe high iterator age values, consider increasing the number of shards or enhancing the processing capacity of your consumers (e.g., adding more instances or increasing the processing power of existing instances).

I choose B

Consumer Record Processing Falling Behind For most use cases, consumer applications are reading the latest data from the stream. In certain circumstances, consumer reads may fall behind, which may not be desired. After you identify how far behind your consumers are reading, look at the most common reasons why consumers fall behind. Start with the GetRecords.IteratorAgeMilliseconds metric, which tracks the read position across all shards and consumers in the stream. Note that if an iterator's age passes 50% of the retention period (by default, 24 hours, configurable up to 365 days), there is risk for data loss due to record expiration. A quick stopgap solution is to increase the retention period. This stops the loss of important data while you troubleshoot the issue further. https://docs.aws.amazon.com/streams/latest/dev/troubleshooting-consumers.html#record-processing-falls-behind

B GetRecords.IteratorAgeMilliseconds metric : its for track the progress of Kinese consumer, this cloud watch matric is use for the measuring the difference between current time and when the last record of GetRecords calls written to the stream. IteratorAgeMilliseconds metric is 0 means is processing fast enough and if its >0 its slow in processing. Therefore, Horizontally scale the Kinesis consumer application by adding more EC2 instances based on the Amazon CloudWatch GetRecords.IteratorAgeMilliseconds metric. Increase the retention period of the Kinesis data streams.

option C (Converting the Kinesis consumer application to run as an AWS Lambda function) is the most suitable solution. This approach automatically scales with the amount of incoming data, reduces the operational burden of managing EC2 instances, and leverages the serverless model to only incur costs for the actual compute time used for processing the data. This option provides a scalable, efficient, and cost-effective solution to the problem without the need for extensive infrastructure management.

B is correct: <consumer application to fall behind> means we need to increase the power of the consumer. <Kinesis data streams drop records> means we should extend timeout. Only B match these requirements A: irrelevant C: Lambda is used only for short-lived tasks because its maximum execution time is 15 min. In this case, we need to process web logs. This is a time-consuming task, which is not suitable for Lambda D: No mention of increasing Consumer power

B & D are correct. However, the question is looking for a solution for two issues "application to fall behind, and the Kinesis data streams drop records before the records can be processed" Then, B is the most appropriate solution

B is the answer: The data fall beind due to lack of pysical resources at consumer side. Icrease of more nodes will address this issue. https://docs.aws.amazon.com/streams/latest/dev/troubleshooting-consumers.html#record-processing-falls-behind

I would say B

D. Increase the number of shards in the Kinesis data streams to increase the overall throughput so that the consumer application processes the data faster. Here's the rationale for choosing this option: Increasing Shards for Throughput: By increasing the number of shards in the Kinesis data streams, you increase the overall throughput and the capacity to handle sudden increases in data. This directly addresses the issue of the consumer application falling behind during data spikes. Operational Efficiency: Scaling the shards provides a more straightforward and efficient solution in terms of operation compared to modifying the consumer application, horizontally scaling instances, or converting the application to run as an AWS Lambda function.

B is not correct. it manually scale EC2 instances. C is operationally efficiency .