An urchin-cove team tries to create “an Event Hub” with no parent and wonders where the endpoint lives. What hierarchy should they create first?
Select an answer to reveal the explanation.
Short Explanation
Namespace first, hub second. Throughput units and the endpoint hang off the Event Hubs namespace; the hub is the stream inside it.
Full Explanation
Event Hubs resources are hierarchical: create an Event Hubs namespace first, then create a hub (the Kafka-analogous topic) inside that namespace. The FQDN endpoint, shared access policies, and capacity settings such as throughput units hang off the namespace; the urchin-cove team cannot create a floating hub with no parent and expect a stable messaging endpoint.
Only a storage account container named eventhub with no messaging namespace fails because a blob container is not an Event Hubs namespace or hub, regardless of the folder name you choose for convenience.
An App Service plan that auto-hosts hubs without a namespace fails: App Service plans host web apps and Functions compute capacity; they do not provision Event Hubs namespaces or Kafka-style topics.
A single Logic Apps connector labeled Event Hub as the namespace fails because a designer connector is not the Azure resource hierarchy—you still need a real namespace and hub before any connector can send or receive.
Exam caveat: Kafka clients often talk to the namespace FQDN and use the hub name as the topic—confusing “hub” with “namespace” breaks connection strings and DNS expectations. Operational check: create the namespace, create a hub inside it, copy the namespace-level connection details, send a test event to that hub name, and confirm the endpoint resolves only after the namespace exists.