What is the main purpose of a schema registry in an event-driven system?
A schema registry (e.g., Confluent Schema Registry) lets producers register schemas and consumers validate incoming messages against them. It prevents format mismatches from breaking consumers when producers evolve.
2 / 18
A schema change is backward compatible if:
Backward compatibility means: you can update the producer (deploy new schema) without updating consumers. Old consumers can still deserialise new messages. Typically achieved by only adding optional fields with defaults.
3 / 18
Which statement correctly describes forward compatibility?
Forward compatibility means: you can update consumers (new schema) before producers. Old producer messages can still be read by new consumers — achieved by consumers ignoring unknown fields and having defaults for new required fields.
4 / 18
Avro is commonly used as an event schema format because:
Avro's binary encoding is compact and efficient. Combined with a schema registry, Avro messages include only a schema ID (not the full schema) — consumers fetch the schema to deserialise. This balance of efficiency and schema governance makes it popular for Kafka.
5 / 18
Before deploying, the team says: "Validate that your schema change is backward-compatible." Which change would break backward compatibility?
Removing a field breaks backward compatibility — old consumers that expect the field will fail to deserialise new messages. Safe changes include: adding optional fields with defaults, adding new types (unused by old consumers).
6 / 18
Reviewer: 'Okay, the PR looks good, but I'm seeing a new field, `customer_tier`, in your event contracts. We haven't defined this yet – it seems like you're anticipating future data requirements before we've agreed on the schema. This could introduce problems later when other services consume these events. Also, is there any documentation explaining why this field was added?'
This question tests understanding that introducing new fields into event contracts *before* schema registry updates and consensus can lead to issues. The key concept here is backward compatibility – if a consumer isn't designed to handle the new field, it will fail. Option A represents overly restrictive behavior; option B misinterprets best practices for evolving schemas; option D highlights the missing documentation that should have accompanied the change. The correct answer emphasizes the need for discussion and schema registry governance.
7 / 18
// Event Contract (simplified)
During code review, Sarah explains to you: "I've updated the `OrderCreated` event schema to include a customer_segment field. This will allow us to better target marketing campaigns based on customer behavior."
Which of the following best describes the potential issue with this change, considering the principles of event contracts and schema registries?
Option A: Adding a new field is *always* beneficial for future extensibility and should be encouraged.
Option B: The issue lies solely in the lack of immediate marketing integration; the schema itself is perfectly valid.
Option C: Introducing customer_segment without a clear understanding of existing consumers could break compatibility, as services relying on the previous schema might not be able to handle or interpret this new data.
Option D: It's acceptable if Sarah documents the change thoroughly and provides examples of how other systems will use the customer_segment field.
The correct answer highlights the core risk associated with adding fields to event contracts without considering existing consumers. A schema registry's primary function is to manage and govern schemas, ensuring compatibility between producers and consumers. Adding an un-defined field like customer_segment *can* break backward compatibility because services expecting only the original schema might fail to process or interpret the new data correctly, leading to errors or processing failures. Options A and B misinterpret the importance of compatibility; option D focuses on documentation which is important but doesn't address the fundamental issue of potential incompatibility.
8 / 18
Reviewer: 'Okay, the PR looks good, but I'm seeing a new field, `customer_tier`, in your event contracts. We haven't defined this yet – it seems like you're anticipating future data requirements before we've agreed on the schema. This could introduce problems later when other services consume these events. Also, is there any documentation explaining why this field was added?'
This question tests understanding that introducing new fields into event contracts *before* schema registry updates and consensus can lead to issues. The key concept here is backward compatibility – if a consumer isn't designed to handle the new field, it will fail. Option A represents overly restrictive behavior; option B misinterprets best practices for evolving schemas; option D highlights the missing documentation that should have accompanied the change. The correct answer emphasizes the need for discussion and schema registry governance.
9 / 18
// Event Contract (simplified)
During code review, Sarah explains to you: "I've updated the `OrderCreated` event schema to include a customer_segment field. This will allow us to better target marketing campaigns based on customer behavior."
Which of the following best describes the potential issue with this change, considering the principles of event contracts and schema registries?
Option A: Adding a new field is *always* beneficial for future extensibility and should be encouraged.
Option B: The issue lies solely in the lack of immediate marketing integration; the schema itself is perfectly valid.
Option C: Introducing customer_segment without a clear understanding of existing consumers could break compatibility, as services relying on the previous schema might not be able to handle or interpret this new data.
Option D: It's acceptable if Sarah documents the change thoroughly and provides examples of how other systems will use the customer_segment field.
The correct answer highlights the core risk associated with adding fields to event contracts without considering existing consumers. A schema registry's primary function is to manage and govern schemas, ensuring compatibility between producers and consumers. Adding an un-defined field like customer_segment *can* break backward compatibility because services expecting only the original schema might fail to process or interpret the new data correctly, leading to errors or processing failures. Options A and B misinterpret the importance of compatibility; option D focuses on documentation which is important but doesn't address the fundamental issue of potential incompatibility.
10 / 18
Reviewer: 'Okay, the PR looks good, but I'm seeing a new field, `customer_tier`, in your event contracts. We haven't defined this yet – it seems like you're anticipating future data requirements before we've agreed on the schema. This could introduce problems later when other services consume these events. Also, is there any documentation explaining why this field was added?'
This question tests understanding that introducing new fields into event contracts *before* schema registry updates and consensus can lead to issues. The key concept here is backward compatibility – if a consumer isn't designed to handle the new field, it will fail. Option A represents overly restrictive behavior; option B misinterprets best practices for evolving schemas; option D highlights the missing documentation that should have accompanied the change. The correct answer emphasizes the need for discussion and schema registry governance.
11 / 18
// Event Contract (simplified)
During code review, Sarah explains to you: "I've updated the `OrderCreated` event schema to include a customer_segment field. This will allow us to better target marketing campaigns based on customer behavior."
Which of the following best describes the potential issue with this change, considering the principles of event contracts and schema registries?
Option A: Adding a new field is *always* beneficial for future extensibility and should be encouraged.
Option B: The issue lies solely in the lack of immediate marketing integration; the schema itself is perfectly valid.
Option C: Introducing customer_segment without a clear understanding of existing consumers could break compatibility, as services relying on the previous schema might not be able to handle or interpret this new data.
Option D: It's acceptable if Sarah documents the change thoroughly and provides examples of how other systems will use the customer_segment field.
The correct answer highlights the core risk associated with adding fields to event contracts without considering existing consumers. A schema registry's primary function is to manage and govern schemas, ensuring compatibility between producers and consumers. Adding an un-defined field like customer_segment *can* break backward compatibility because services expecting only the original schema might fail to process or interpret the new data correctly, leading to errors or processing failures. Options A and B misinterpret the importance of compatibility; option D focuses on documentation which is important but doesn't address the fundamental issue of potential incompatibility.
12 / 18
Reviewer: 'Okay, the PR looks good, but I'm seeing a new field, `customer_tier`, in your event contracts. We haven't defined this yet – it seems like you're anticipating future data requirements before we've agreed on the schema. This could introduce problems later when other services consume these events. Also, is there any documentation explaining why this field was added?'
This question tests understanding that introducing new fields into event contracts *before* schema registry updates and consensus can lead to issues. The key concept here is backward compatibility – if a consumer isn't designed to handle the new field, it will fail. Option A represents overly restrictive behavior; option B misinterprets best practices for evolving schemas; option D highlights the missing documentation that should have accompanied the change. The correct answer emphasizes the need for discussion and schema registry governance.
13 / 18
// Event Contract (simplified)
During code review, Sarah explains to you: "I've updated the `OrderCreated` event schema to include a customer_segment field. This will allow us to better target marketing campaigns based on customer behavior."
Which of the following best describes the potential issue with this change, considering the principles of event contracts and schema registries?
Option A: Adding a new field is *always* beneficial for future extensibility and should be encouraged.
Option B: The issue lies solely in the lack of immediate marketing integration; the schema itself is perfectly valid.
Option C: Introducing customer_segment without a clear understanding of existing consumers could break compatibility, as services relying on the previous schema might not be able to handle or interpret this new data.
Option D: It's acceptable if Sarah documents the change thoroughly and provides examples of how other systems will use the customer_segment field.
The correct answer highlights the core risk associated with adding fields to event contracts without considering existing consumers. A schema registry's primary function is to manage and govern schemas, ensuring compatibility between producers and consumers. Adding an un-defined field like customer_segment *can* break backward compatibility because services expecting only the original schema might fail to process or interpret the new data correctly, leading to errors or processing failures. Options A and B misinterpret the importance of compatibility; option D focuses on documentation which is important but doesn't address the fundamental issue of potential incompatibility.
14 / 18
David from the operations team Slack channel says: "Hey, I'm seeing a lot of events with a new field called `event_timestamp_ms`. It's causing some issues with our monitoring dashboards because we weren't expecting it. What does this typically indicate about the event contracts?"
Event-driven architectures rely on consistent schemas. When a new field like `event_timestamp_ms` is introduced, it indicates a change in the event contract's structure. This necessitates adjustments to applications consuming these events to correctly interpret and process this additional data; option A accurately describes this requirement.
15 / 18
Sarah is writing a pull request description for an event contract update. She writes: "We've added a `product_id` field to the `OrderPlaced` event schema. This will help us track which products are most frequently ordered. Backward compatibility is crucial; existing consumers shouldn't break when this change is deployed."
Backward compatibility in event contracts centers around allowing new consumers to process events while existing ones continue to function. A nullable field (allowing null values) for `product_id` is the correct approach because older consumers that don't yet have this field will simply ignore it without causing an error, maintaining compatibility; option B addresses this core concept.
16 / 18
Mark, a senior developer, is reviewing a change to the `CustomerCreated` event. He sees that a new field, `address_line2`, has been added. He asks you: 'How does this relate to schema evolution?'
Forward compatibility in event contracts means that newer versions can consume events produced by older ones. Adding `address_line2` allows for this; older consumers ignoring it don't break, while newer consumers can process the new field without issues. Option A correctly describes the fundamental principle of forward compatibility.
17 / 18
Emily is troubleshooting an issue where some events are failing to process after a schema update. The logs show a 'Schema mismatch' error. Which of the following scenarios *most likely* caused this problem?
Schema mismatches typically occur when consumers are using an older version of the event contract that doesn't include the newly added fields or data types. This leads to validation errors because the consumer expects a different structure than what's actually present in the event. Option A is the most probable cause given the scenario.
18 / 18
During a standup meeting, Ben explains: 'We've updated the `UserLoggedIn` event to include a `device_type` field. This will allow us to track user behavior across different devices for analytics purposes.' Which of the following statements best describes the significance of this change from a schema registry perspective?
Schema registries play a vital role in managing schema changes. While backward compatibility is important, the registry often handles aspects like data type conversions or validation rules related to the new `device_type` field—option A accurately reflects this responsibility; it's crucial for maintaining consistency across event producers and consumers.
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Schema Registry & Event Contracts — Vocabulary — Event-Driven Architecture | CoderLingo"?
This exercise has 18 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Event-Driven Architecture Language exercises?
Browse the full Event-Driven Architecture Language hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.