Protocol Buffers (protobuf) in IOT Protocols - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output of the protobuf compiler command?

You run the command protoc --python_out=. sensor.proto in your terminal. What is the expected result?

A Generates a Python file named <code>sensor_pb2.py</code> in the current directory.

B Generates a binary executable named <code>sensor</code> in the current directory.

C Outputs the compiled protobuf schema as JSON to the terminal.

D Throws an error because <code>--python_out</code> is not a valid option.

💡 Hint

Think about what the --python_out flag does in the protoc command.

The protoc compiler with the --python_out=. option generates Python code from the .proto file and saves it in the current directory. The output file is named by appending _pb2.py to the proto filename.

🧠 Conceptual

intermediate

What does the 'optional' keyword mean in a protobuf message?

In a protobuf message definition, what does marking a field as optional imply?

A The field must always be set; otherwise, the message is invalid.

B The field is deprecated and should not be used anymore.

C The field may or may not be set; if not set, it uses a default value.

D The field is repeated multiple times in the message.

💡 Hint

Think about what 'optional' means in everyday choices.

Marking a field as optional means it can be left unset. If unset, the field takes a default value (like zero for numbers or empty string for text).

❓ Configuration

advanced

How to define a repeated field in a protobuf message?

You want to define a protobuf message that holds multiple sensor readings in a list. Which of the following message definitions correctly uses a repeated field?

A message SensorData { repeated int32 readings = 1; }

B message SensorData { optional int32 readings = 1; }

C message SensorData { int32[] readings = 1; }

D message SensorData { map<int32, int32> readings = 1; }

💡 Hint

Think about how to say 'many' in protobuf syntax.

The repeated keyword defines a list of values of the specified type. Option A correctly uses repeated int32 readings = 1; to hold multiple integers.

❓ Troubleshoot

advanced

Why does this protobuf message cause a compilation error?

Given this protobuf message definition:

message Device {
  int32 id = 1;
  string name = 1;
}

Why does compiling this cause an error?

IOT Protocols

message Device {
  int32 id = 1;
  string name = 1;
}

A The 'string' type is not supported in protobuf.

B Field names cannot be 'id' or 'name' in protobuf messages.

C The message must have at least three fields to compile.

D Field numbers must be unique; both fields use number 1 causing a conflict.

💡 Hint

Check the numbers after the equals sign for each field.

Each field in a protobuf message must have a unique number. Here, both id and name use number 1, which causes a compilation error.

✅ Best Practice

expert

Which practice helps maintain backward compatibility in protobuf schemas?

You want to update a protobuf message without breaking existing clients. Which practice below best supports backward compatibility?

A Change the type of existing fields to the new desired type directly.

B Add new fields with new unique numbers and mark old fields as deprecated instead of removing them.

C Reuse field numbers for new fields after removing old ones.

D Remove old fields and renumber all fields to keep numbers sequential.

💡 Hint

Think about how to keep old data working while adding new features.

Adding new fields with new unique numbers and deprecating old fields keeps old clients working and supports new features. Changing types or reusing numbers breaks compatibility.