Parking-sensor producers already speak Kafka APIs. The city wants those clients to publish into OCI Streaming without running a self-managed Apache Kafka cluster. What capability should they rely on?
Select an answer to reveal the explanation.
Short Explanation
Streaming’s Kafka compatibility is like a city radio that still tunes old police-band handsets—you keep the familiar protocol without standing up your own radio tower. Existing Kafka producers and consumers can target the stream pool’s bootstrap servers. This exam tests that OCI Streaming capability; it is not a Confluent admin certification and does not require a Kafka cluster on OKE.
Full Explanation
OCI Streaming offers Kafka API compatibility so existing Kafka producers and consumers can target a stream pool’s bootstrap servers instead of operating a self-managed Apache Kafka cluster. Parking-sensor producers that already speak Kafka protocols can publish into Streaming by re-pointing configuration at the pool, which is the developer-facing capability under test. The city keeps familiar client libraries and wire patterns without standing up and patching its own Kafka brokers on OKE.
Provisioning a Kafka cluster on OKE as a required path before any producer can publish ignores Streaming’s compatibility feature and adds unnecessary cluster operations. Rewriting every producer to call only the OCI Queue REST API abandons both Streaming and Kafka clients for a different messaging product. Replacing Streaming with OCI Events rules that accept Kafka produce requests invents a protocol Events does not speak.
Exam caveat: “compatible with most Kafka APIs” is not a promise of every Apache Kafka admin feature or third-party ecosystem tool. Validate the specific client APIs your sensors use against Streaming’s supported set.
Operational check: point a Kafka-capable test producer at the stream pool bootstrap servers, publish a sensor-shaped message, and consume it with a Kafka-compatible consumer to confirm end-to-end compatibility without a self-managed cluster.