B. The routing key 'task' does not match exchange type
C. The exchange 'logs' does not exist
D. The channel is closed
Solution
Step 1: Check prerequisites for binding
RabbitMQ queue_bind requires both the exchange and queue to exist and be declared beforehand.
Step 2: Spot the missing declaration
The code shows only queue_bind with no channel.exchange_declare('logs', exchange_type='fanout') prior. Without declaring the exchange, queue_bind fails (exchange not found), no binding created, messages not delivered.
Final Answer:
The exchange 'logs' does not exist -> Option C
Quick Check:
exchange_declare before queue_bind [OK]
Hint: Declare exchanges before binding [OK]
Common Mistakes:
Assuming exchange existence without checking
Ignoring exchange type rules
Not verifying queue name correctness
5. You want two systems to communicate reliably with flexible routing using RabbitMQ. Which integration pattern should you use?
hard
A. Point-to-point with direct exchange and queues
B. Publish-subscribe with fanout exchange
C. Request-reply with temporary queues
D. Store-and-forward with dead-letter queues
Solution
Step 1: Define reliable and flexible routing needs
Reliable communication means messages must be delivered to a specific receiver; flexible routing means routing keys can direct messages.
Step 2: Match pattern to needs
Point-to-point with direct exchange allows routing messages to specific queues using routing keys, ensuring reliability and flexibility.
Final Answer:
Point-to-point with direct exchange and queues -> Option A
Quick Check:
Direct exchange = reliable, flexible routing [OK]
Hint: Direct exchange for reliable, flexible routing [OK]
Common Mistakes:
Choosing fanout which broadcasts to all
Confusing request-reply with routing pattern
Thinking dead-letter queues handle routing
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.