A city transit telemetry team is writing unit-style consumer tests for a Kinesis Data Streams processor. Developers need repeatable, crafted records without waiting for live buses. What approach fits Domain 3 testing for streaming consumers?
Select an answer to reveal the explanation.
Short Explanation
Think of a practice lane at the bus depot—same doors and sensors, fake riders. Drop crafted records into a test shard so the consumer exercises real Kinesis APIs without gambling on live traffic. Production sampling and IAM-only checks do not prove the parser works.
Full Explanation
Unit-style consumer tests for a Kinesis Data Streams processor on city transit telemetry should put representative crafted records into a dedicated test stream shard and let the consumer process those synthetic events. Crafted records give repeatable coverage of municipal message shapes without waiting for live buses or sampling production streams during office hours. Domain 3 streaming tests favor controlled inputs over opportunistic live traffic.
Pointing the consumer at the production stream and sampling a few live records during office hours fails because production data may be sparse, sensitive, or non-representative, and tests become nondeterministic. Disabling the consumer in CI and only validating IAM policies on the stream ARN fails conceptually—policy checks are not behavioral consumer tests. Replacing Kinesis with an in-memory Python list and skipping AWS stream APIs for all environments fails when the goal includes exercising stream consumption semantics in a test stream.
Exam caveat: synthetic telemetry must avoid embedding real rider identifiers if those appear in production schemas; use anonymized fixtures. Operational check: publish crafted records to the test stream, assert consumer side effects (metrics, stores, downstream events), and keep the test stream sealed from production producers.