Exam AWS Certified Solutions Architect - Associate SAA-C02 topic 1 question 279 discussion

Every time you see Decoupling please choose SQS so the answer is D

The answer is D. I am a full time MQ support guy before so i know this type of message queues designs very well. Usually large number of messages go into a topic and they will be consumed by many message queues who subscribed to them.

D is the answer

Agree with D because it said one or more SQS

It's not possible to do the requirements with a single shard, so has to be D (although it makes more sense to use kinesis streams if there is no shard limitation)

A is out because Kinesis Data Analysis is not meant for digesting data. It is for querying streams. It gets data from and sends data to either Kinesis Data Stream or Firehose. B is out for obvious reasons. C is out because it mentions a single shard. For a single shard we have the limitation of 1 MB or 1000 messages/sec. The question says there might be 100,000 messages/sec. D is the answer.

D for decouple and divorce..queue

SNS Fanout to SQS. Kinesis supports only 1000 per sec.

decoupling=SQS

Every time you see Decoupling please choose SQS so the answer is D

Q: What is a shard, producer, and consumer in Kinesis Data Streams? A shard has a sequence of data records in a stream. It serves as a base throughput unit of a Kinesis data stream. A shard supports 1 MB/second and 1,000 records per second for writes and 2 MB/second for reads. The shard limits ensure predictable performance, making it easy to design and operate a highly reliable data streaming workflow. A producer puts data records into shards and a consumer gets data records from shards. Consumers use shards for parallel data processing and for consuming data in the exact order in which they are stored. If writes and reads exceed the shard limits, the producer and consumer applications will receive throttles, which can be handled through retries.

When in doubt, fan out!! SNS + SQS for me. Answer D

D. A-incorrect as KDA can have source as KDS or KDF only,not direct from clients. C-KDS has max limit of 1 MB/s or 1000 messages /sec going in per shard and 2 MB/s or 5 messages/sec out per shard( per consumer in enhanced mode or this limit is shared across all consumers in Standard mode) Max size of message is 1 MB. 100 000 per second cannot be handled by KDS. NOTE-KDF would not fit either as 'matter of seconds' .KDF is 'near real time' not real time (60 seconds latency for buffer to fill) 'fluctuates significantly'--EC2 with ASG(A) or option D both can help. But the 'divorce from infrastructure' looks more like D D fits publish once,receive many SNS,Lambda, custom HTTP endpoint ,SMS, email,mobile alerts, KDF are valid targets(subscribers) of SNS. P.S.AWS queue(SQS) does not have limits on queue size. It only poses limit on inflight messages ie messages already consumed by consumers but not deleted.

It should be D

why the hell is the answer wrong for this question too!! I am tired of the wrong answers

It seems not to be a use case of stream processing: stream in not mentioned and the number of messages varies drastically. B is boguous Ans is D

D "SNS Standard Topic" Maximum throughput: Standard topics support a nearly unlimited number of messages per second. https://aws.amazon.com/sns/features/ "SQS Standard Queue" Unlimited Throughput: Standard queues support a nearly unlimited number of transactions per second (TPS) per API action. https://aws.amazon.com/sqs/features/