Google ACE Practice Question: Arrange the steps to create a Cloud Pub/Sub…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Create topic -> Create subscription -> Publish message -> Pull message

  Why this is correct

  Creating the topic first is mandatory because a subscription must reference an existing topic at creation time. Then the subscription must be created before any messages are published, since Pub/Sub retains messages in the subscription backlog, not in the topic itself. Publishing after the subscription exists guarantees the message is added to that subscription's backlog and can be pulled. Finally, the subscriber pulls the message from the subscription, completing the correct end-to-end flow.

• ✗

  Create subscription -> Create topic -> Publish message -> Pull message

  Why it's wrong here

  This order is invalid because a subscription cannot be created without a pre-existing topic; the Pub/Sub API returns an error (NOT_FOUND) if the referenced topic does not exist. Even if the subscription creation somehow succeeded, it would have no associated topic to receive messages from, making the subsequent publish and pull steps meaningless. The topic must always be the first resource created in the Pub/Sub hierarchy.

• ✗

  Create topic -> Publish message -> Create subscription -> Pull message

  Why it's wrong here

  Publishing a message before creating the subscription is a common mistake that causes message loss. In Pub/Sub, messages are not stored in the topic; they are stored in the subscription's backlog, and a subscription only receives messages published after it has been created. Therefore, a message published before subscription creation will never appear in that subscription, regardless of its retention window. The subscription must exist at the moment of publish so the message can be attached to its backlog.

• ✗

  Create topic -> Create subscription -> Pull message -> Publish message

  Why it's wrong here

  Pulling before publishing is logically futile because there are no messages in the subscription's backlog to retrieve. Even though pull operations can be long-lived and wait for messages, the publish step in this sequence occurs after the pull, so the subscriber would simply receive an empty response or time out. The correct workflow requires the message to be published first, then the subscriber pulls the newly available message.

Go deeper

Related to this question