Service Registration, Health Checks, and Service Mesh (Connect)
Domain 3 tests registration mechanics and health checking in detail, plus the Connect data path. Expect questions about which agent runs a check, why a TTL check went critical, how a sidecar is registered, and what an intention does when a connection is refused while the service looks healthy.
Registration paths
A service can be registered by a JSON/HCL definition in the agent's config-dir (kept in sync by anti-entropy), by PUT /v1/agent/service/register, by consul services register, by the Kubernetes catalog sync, or by ECS/Helm integrations. API and file registration are agent-local: registering on one node does not register elsewhere. Name is the logical service; ID must be unique per instance (it defaults to Name, which silently overwrites when two instances share an agent).
Health checks
Check types are script, http, tcp, ttl, grpc, alias, docker and h2ping. Checks execute on the agent that owns the registration, so a check cannot run if that agent is down - which is why serfHealth marking a node critical removes its services from healthy queries regardless of individual check state. TTL checks are passive: the service must PUT /v1/agent/check/pass/:check_id before the TTL elapses or the check flips critical. Set deregister_critical_service_after to evict long-dead instances automatically.
Connect and intentions
Connect provides service-to-service mTLS through sidecar or native proxies. consul connect envoy -sidecar-for web renders Envoy configuration with a listener per entry in the proxy's upstreams list. Leaf certificates are issued by the Connect CA (built-in or Vault). Traffic is gated by intentions, and intentions are only enforced for traffic that actually traverses a proxy. Mesh gateways carry cross-datacenter and cross-network Connect traffic.
Worked example
A service named payments reports passing in the UI, but callers get connection refused through Connect. Reasoning order: is payments registered with a connect block and a running sidecar; are callers dialing localhost:<upstream-port> rather than the service's own port; and does an intention exist - a default-deny service-intentions entry with no matching allow rule produces refused connections while health stays green. Health describes process liveness; intentions describe authorization; the two are independent signals.
Traps
Registering two instances with the same ID; TTL checks that are created but never pinged; expecting intentions to cover traffic that bypasses the proxy; and assuming a passing check means Connect will authorize the call.