Consul Ops Pro study materials
Consul Ops Pro study resources

Consul Ops Pro: Consul Architecture and Deployment Topologies

Consul Ops Pro · Work through your exam, one topic at a time.

All guide sections

Consul Architecture and Deployment Topologies

Domain 1 tests whether you can describe how a Consul cluster is actually built: which agents do which work, how datacenters federate, how many servers you need to survive failures, and which ports must be reachable between them. Expect scenario questions where a stated topology (three datacenters, two availability zones, Kubernetes plus VMs) must be matched to a correct design.

Agents, roles, and data flow

Every node runs one agent. Only server agents hold state: they run the Raft consensus log and store the catalog, KV store, ACLs, intentions and Connect CA material. Client agents run local health checks, cache catalog data, perform anti-entropy sync from configuration files, and forward RPCs to servers. Losing every client does not lose data; losing quorum of servers does.

Each datacenter is an independent Raft cluster with its own servers and its own leader. Datacenters are joined by WAN gossip for federation only - no catalog data is replicated across them, which is why cross-datacenter reads must be requested explicitly with ?dc=.

Ports and quorum

Recall cold: 8300 server RPC (servers only, must be reachable between datacenters), 8301 LAN gossip (TCP+UDP), 8302 WAN gossip (servers only), 8500 HTTP, 8501 HTTPS, 8600 DNS, 8502 gRPC/xDS for Envoy, 8503 gRPC-TLS.

Quorum is floor(n/2)+1; tolerable failures are floor((n-1)/2). Three servers survive one loss, five survive two, and four survive only one while adding latency. Client agents run on every node that hosts services.

Worked example

A design asks for three datacenters, each tolerating the loss of one server, with servers spread across two availability zones. Answer: three servers per datacenter (nine total), Raft confined within each datacenter, retry_join_wan pointing at the other datacenters' servers, and AZ metadata on each server via node_meta or the redundancy-zone tag consumed by autopilot. Reasoning: a quorum of three tolerates exactly one failure; adding a fourth server raises the majority threshold to three without increasing fault tolerance, so it is worse than three or five.

Traps

Designing an even server count "for balance"; assuming clients can answer catalog reads after all servers are down; forgetting 8302 between datacenters; assuming namespaces, admin partitions or redundancy zones exist in the community binary; and deploying a single server per datacenter "for cost" - quorum of one means every restart is an outage.