Self-Assessment Quiz: Schema Evolution and Data Contracts

Twenty questions. Aim for 16 or more.

Question 1

The chapter's central argument is about:

• A. Whether producers may change their systems
• B. Where a failure lands — at the producer at write time, or at the consumer weeks later
• C. Which serialization format to use
• D. How to version a schema

Question 2

The missing artifact between producer and consumer exists because:

• A. Producers do not document their systems
• B. The producer cannot know who reads them, and the consumer cannot know when the shape changes
• C. Schemas are optional
• D. Teams do not communicate

Question 3

A data contract is NOT:

• A. Owned by the producer
• B. Enforced by something automated
• C. A restriction forbidding the producer from changing
• D. Discoverable by consumers

Question 4

Backward compatibility means:

• A. An old reader can read new data
• B. A new reader can read old data
• C. Both readers work
• D. Neither

Question 5

Which compatibility mode lets you upgrade consumers first?

• A. Forward
• B. Backward
• C. Full
• D. None

Question 6

Removing an optional field is compatible under:

• A. Backward only
• B. Forward only
• C. Full
• D. None

Question 7

Adding an enum value is:

• A. Always safe
• B. Compatible on paper and frequently breaking in practice
• C. Always breaking
• D. Only relevant for Avro

Question 8

Use the transitive compatibility variant when:

• A. You have many producers
• B. Consumers may read arbitrarily old data — which for a replayable log they can
• C. The schema is large
• D. The registry requires it

Question 9

A schema registry's most valuable behavior is:

• A. Storing schemas centrally
• B. Reducing message size by carrying an id
• C. Refusing to register an incompatible schema, at deploy time, so the bad data never exists
• D. Documenting the data model

Question 10

A registry outage during a consumer restart with a cold cache is:

• A. Harmless — schemas are embedded in messages
• B. A real failure mode; run the registry with database-level availability
• C. Impossible
• D. Handled automatically by retry

Question 11

Which contract field solves the producer's central problem?

• A. The schema
• B. The consumer list
• C. The guarantees
• D. The change policy

Question 12

Which contract field catches a sign inversion or a redefined timestamp?

• A. The schema
• B. The compatibility mode
• C. The semantics section — and nothing automated enforces it
• D. The validation section

Question 13

Which enforcement point is cheapest and most valuable?

• A. Producer CI, before merge
• B. Producer runtime
• C. Consumer runtime
• D. Scheduled guarantee checks

Question 14

Which enforcement point catches a producer that is schema-compliant and has halved its volume?

• A. Producer CI
• B. Producer runtime
• C. Consumer runtime
• D. Scheduled checks against the guarantees

Question 15

Build consumer validation first because:

• A. It is more thorough
• B. You can build it unilaterally, today, without anyone's agreement — and it generates evidence
• C. Producer enforcement does not work
• D. It is cheaper to run

Question 16

A MAJOR version change should be:

• A. A modification of the existing topic
• B. A new topic or table, with a dual-write window
• C. A configuration flag
• D. Announced but not versioned

Question 17

In expand-contract, step 3 (removing the old field) is possible because:

• A. The registry permits it
• B. The consumer list tells you nobody reads it
• C. Enough time has passed
• D. The schema is backward compatible

Question 18

The most important social fix is to frame the contract as:

• A. A requirement from the data team
• B. What the producer already provides — and the consumer list is the producer's benefit
• C. A compliance obligation
• D. A shared document

Question 19

For a source you do not control, you should:

• A. Skip the contract
• B. Write it with status: observed, enforce at the consumer, and log violations
• C. Demand agreement
• D. Rely on the vendor's documentation

Question 20

Which is NOT a case where a contract is skippable?

• A. One producer, one consumer, same team
• B. Genuinely exploratory data
• C. No enforcement point is available anywhere
• D. The producer will not agree

Answer Key

1. B — §17.1. Changes will happen; the question is who absorbs the cost and when.

2. B — §17.1. And the data itself carries no statement of intent.

3. C — §17.1. A contract that forbids change gets routed around.

4. B — §17.2. The direction names what the new schema is compatible with — data written backward in time.

5. B — §17.2. Which is why backward is the default and what replay requires.

6. B — §17.2. A new reader would find the field gone; an old reader is fine.

7. B — §17.2. Many implementations reject unknown symbols. The most common "it should have worked" registry incident.

8. B — §17.2. Non-transitive checks only against the latest version.

9. C — §17.3. Compare Chapter 11 §11.5's alternative: the change succeeds and surfaces in a consumer weeks later.

10. B — §17.3. Messages carry an id, not a schema, so a consumer that cannot resolve it cannot proceed.

11. B — §17.4. And being on the list is what entitles you to notice.

12. C — §17.4. Chapter 2's discount_cents inversion had no schema change at all.

13. A — §17.5. The change never merges, the author sees it in context, no data is written.

14. D — §17.5. The only point that catches a guarantee violated with no schema change.

15. B — §17.5, 📐 callout. Producer enforcement requires a conversation, a roadmap slot, and a negotiation.

16. B — §17.6. v1 consumers keep reading, undisturbed, during the dual-write window.

17. B — §17.6. Without the list, step 3 is a guess.

18. B — §17.7. A contract framed as "you may not change without asking us" will be resisted, and should be.

19. B — §17.8. It records what you measured, defines "broken," and generates evidence.

20. D — §17.10. That is a reason to write an observed contract, not to skip it. The same applies to "a different team" and "an external producer."

Topic map