Shovel and Federation for multi-DC in RabbitMQ - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Difference between Shovel and Federation plugins

Which statement correctly describes the main difference between RabbitMQ's Shovel and Federation plugins in a multi-data-center setup?

A Federation is designed for dynamic topology changes and scales better across multiple data centers, while Shovel is more static and configured per link.

B Shovel only works within a single data center, whereas Federation works only across multiple data centers.

C Shovel creates a continuous, automatic message transfer between brokers, while Federation requires manual message pulling.

D Federation duplicates messages locally, while Shovel deletes messages after transfer.

💡 Hint

Think about which plugin adapts better to changing network conditions and scales automatically.

Federation is designed to handle dynamic topologies and scales well across multiple data centers by federating exchanges or queues. Shovel is configured per link and is more static, transferring messages continuously but requiring manual setup for each link.

💻 Command Output

intermediate

Output of Shovel status command

What is the output of the following command on a RabbitMQ node with a configured shovel named 'shovel1' currently running?

rabbitmqctl shovel_status shovel1

A {"state":"running","source":"amqp://source","destination":"amqp://dest"}

B Error: shovel 'shovel1' not found

C {"state":"stopped","source":"amqp://source","destination":"amqp://dest"}

D shovel1: active

💡 Hint

Check the JSON output format for shovel status showing state and endpoints.

The shovel_status command returns a JSON object with the shovel's state and its source and destination URIs. If the shovel is running, the state is 'running'.

❓ Configuration

advanced

Correct Shovel configuration for multi-DC message transfer

Which of the following RabbitMQ shovel configuration snippets correctly sets up a shovel to transfer messages from a queue named 'orders' in one data center to a queue named 'orders' in another data center?

A

shovels:
  orders_shovel:
    source-uri: amqp://dc1
    source-exchange: orders
    destination-uri: amqp://dc2
    destination-queue: orders
    ack-mode: on-publish

B

shovels:
  orders_shovel:
    source-uri: amqp://dc1
    source-exchange: orders
    destination-uri: amqp://dc2
    destination-exchange: orders
    ack-mode: on-publish

C

shovels:
  orders_shovel:
    source-uri: amqp://dc1
    source-queue: orders
    destination-uri: amqp://dc2
    destination-queue: orders
    ack-mode: on-confirm

D

shovels:
  orders_shovel:
    source-uri: amqp://dc1
    source-queue: orders
    destination-uri: amqp://dc2
    destination-exchange: orders
    ack-mode: on-confirm

💡 Hint

Remember that queues and exchanges are different entities; the source and destination must match types.

To transfer messages from a queue to a queue, both source and destination must specify queues. Option C correctly uses source-queue and destination-queue. Other options mix exchanges and queues incorrectly.

❓ Troubleshoot

advanced

Troubleshooting Federation link failure

You have a RabbitMQ federation link configured between two data centers. Messages are not flowing, and the federation link status shows 'down'. Which of the following is the most likely cause?

A The shovel plugin is not enabled on the downstream node.

B The upstream URI is incorrect or unreachable from the downstream node.

C The queue names do not match exactly on both sides of the federation link.

D The federation plugin requires manual message acknowledgment to start.

💡 Hint

Check connectivity and URI correctness first when federation links are down.

A federation link depends on the downstream node connecting to the upstream URI. If the URI is wrong or network connectivity is blocked, the link will be down. Shovel plugin is unrelated, queue names do not have to match exactly, and federation does not require manual ack to start.

🔀 Workflow

expert

Order of steps to set up Federation for multi-DC RabbitMQ

Arrange the following steps in the correct order to set up a RabbitMQ Federation link between two data centers:

A 3,1,2,4

B 2,1,3,4

C 1,3,2,4

D 1,2,3,4

💡 Hint

Think about enabling features before configuring them and verifying last.

First, enable the federation plugin on both nodes. Then configure the upstream URI on the downstream node. Next, define the federated exchange or queue. Finally, verify the link status and message flow.