AI-Assisted Protobuf and gRPC Schema Migration

End-of-lesson check

15 questions · take it digitally for instant feedback at tendril.neural-forge.io/learn/quiz/end-ai-coding-AI-protobuf-migration-creators

1. What is a key capability of AI tools when assisting with protobuf schema migration?

   1. AI can flag wire-compatibility risks and draft migration code
   2. AI can determine which old binary versions are still running in production
   3. AI can guarantee that all schema changes will be backward compatible
   4. AI can automatically deploy schemas to production servers

2. In protobuf schema evolution, what risk arises from field-number reuse?

   1. The schema file size increases exponentially
   2. The compiler generates faster code
   3. New data may be incorrectly read as old data types
   4. The gRPC service becomes unavailable

3. A protobuf change is considered 'wire-compatible' when:

   1. The new schema compiles without errors
   2. Both old and new schema versions can read each other's messages on the wire
   3. The gRPC service returns successful status codes
   4. All optional fields are removed

4. Why is a wire-incompatible protobuf change particularly dangerous when it doesn't produce a compile-time error?

   1. The schema automatically rolls back
   2. Data may be silently corrupted or misinterpreted
   3. gRPC connections will automatically restart
   4. The code will run faster without error checking

5. Which piece of information is AI unable to determine during schema migration analysis?

   1. If required fields are being changed to optional
   2. Which old binary versions remain deployed in production
   3. Whether packed/unpacked settings are being altered
   4. Whether field numbers are being reused

6. Why can changing a required field to optional in proto2 schemas cause compatibility issues?

   1. Old binaries expecting required fields may fail when receiving missing values
   2. Proto2 does not support backward compatibility
   3. The compiler will reject the change as illegal
   4. Optional fields cannot be serialized in proto2

7. In protobuf terminology, 'tag collision' refers to:

   1. Two fields having the same name in a message
   2. A gRPC method name conflict
   3. A message type defined multiple times
   4. Two different fields using the same field number

8. What does switching a field between 'packed' and 'unpacked' encoding in protobuf affect?

   1. The data type of the field
   2. How repeated scalar values are serialized on the wire
   3. The field name in generated code
   4. Whether the field is optional or required

9. Which of the following is NOT a task AI performs well in protobuf schema migration?

   1. Generating cross-version test fixtures
   2. Checking for field-number reuse and collision risks
   3. Drafting proto changes with compatibility comments
   4. Determining which old binaries remain in customer environments

10. Why might a wire-incompatible protobuf change compile without errors?

    1. Optional fields cannot cause compile errors
    2. Protobuf compilers ignore wire format entirely
    3. The schema syntax is valid even when wire-incompatible
    4. Old field numbers are always valid

11. In the context of protobuf schema migration, a 'migration PR' typically refers to:

    1. A pull request that only updates documentation
    2. A request to migrate entire services to new frameworks
    3. A proposed code change containing proto modifications and compatibility notes
    4. A pull request that reverts schema changes

12. Backward compatibility in protobuf schemas primarily depends on:

    1. Wire format rules for field numbers and types
    2. Field names remaining unchanged
    3. gRPC service names staying the same
    4. All fields being optional

13. When reviewing a proto diff for wire-compatibility, which of the following should be flagged as a risk?

    1. Adding entirely new optional fields with new numbers
    2. Removing an optional field and reusing its number
    3. Adding a new service method
    4. Changing a field from optional to required

14. In protobuf's wire format, the field number directly determines:

    1. The order of fields in generated code
    2. The size of the encoded message
    3. The default value for the field
    4. Which field a particular piece of data belongs to

15. Why is it important to know which old binary versions are still in production during schema migration?

    1. To measure network latency between services
    2. To calculate cloud infrastructure costs
    3. To determine how much disk space is available
    4. To understand what wire formats those versions expect