Quiz: HashiCorp Consul¶
6 questions
L1 (3 questions)¶
1. What is HashiCorp Consul and what are its primary use cases?
Show answer
Consul is a service mesh and service discovery tool. Primary use cases:1. Service discovery — services register themselves and others find them via DNS or HTTP API.
2. Health checking — Consul runs checks (HTTP, TCP, script) and only returns healthy instances.
3. KV store — hierarchical key-value storage for configuration.
4. Service mesh — sidecar proxies (Connect) enforce mutual TLS and intentions (authorization).
5. Multi-datacenter — built-in WAN federation for cross-DC service discovery. It uses Raft consensus for consistency and gossip (Serf) for membership.
2. How do you use Consul for service discovery and what happens when a service instance becomes unhealthy?
Show answer
Services register via agent config file or HTTP API (PUT /v1/agent/service/register). Clients query via DNS (web.service.consul) or HTTP API (GET /v1/health/service/web?passing). When a health check fails, Consul marks the instance as critical and stops returning it in DNS queries and passing-only API queries. After the deregister_critical_service_after timeout, it is automatically deregistered. Anti-caching: use blocking queries (long-poll) or watches for real-time updates instead of polling.3. What is the difference between a Consul client agent and a server agent?
Show answer
Server agents participate in the Raft consensus protocol, store all state (service catalog, KV, intentions), and replicate data. Run 3 or 5 servers per datacenter for fault tolerance. Client agents run on every node where services run — they handle local service registration, run health checks, and forward queries to servers via RPC. Clients are lightweight and stateless. The split reduces server load: health checks run locally, only results are forwarded. All agents participate in the LAN gossip pool.L2 (3 questions)¶
1. How does Consul's gossip protocol work and what is the difference between LAN and WAN gossip pools?
Show answer
Consul uses Serf (based on SWIM) for gossip-based membership management. Each agent periodically pings random peers and propagates state changes (join, leave, fail) exponentially through the cluster. LAN gossip pool: all agents in a single datacenter — high frequency, low latency, uses LAN network. WAN gossip pool: only server agents across datacenters — lower frequency, tolerates higher latency, uses WAN links. The LAN pool detects local failures in seconds. The WAN pool enables cross-DC service discovery and failover.2. What are Consul intentions and how do they provide service-to-service authorization?
Show answer
Intentions define which services are allowed to communicate. They are identity-based ACLs: 'web can talk to api' or 'deny all to database except api'. With Connect (service mesh), Consul injects sidecar proxies that enforce intentions using mutual TLS — the proxy verifies the caller's service identity from its TLS certificate before allowing the connection. Intentions can be managed via CLI, API, or Terraform. Default behavior is configurable: allow-all or deny-all. In production, use deny-all default and explicitly allow required paths.3. How do you configure Consul for multi-datacenter operation and what is WAN federation vs mesh gateways?