Service Registration, Health Checks, and Service Discovery
Registration
Services are declared in JSON/HCL service definition files in the config directory, via the HTTP API, or with consul services register. Each service has a name, an optional id (defaults to the name, and must be unique per node), address, port, tags, meta, and one or more check blocks. Registering the same ID twice overwrites the prior definition - a common trap when a question asks what happens on duplicate registration.
Health checks
Check types include script, http, tcp, grpc, ttl, docker, and alias. Statuses are passing, warning, critical. TTL checks require an explicit PUT /v1/agent/check/pass/:id within the TTL or they go critical. Checks run on the client agent that owns the service, not on servers. deregister_critical_service_after removes a service that stays critical, keeping the catalog clean after node loss.
Discovery
DNS is the classic interface: web.service.dc1.consul returns A records for healthy instances, _http._tcp.web.service.dc1.consul returns SRV records with ports, and tag.web.service.dc1.consul filters by tag. The HTTP catalog endpoint returns all instances; ?passing filters to healthy ones, and DNS returns only passing instances by default. Prepared queries store a named lookup server-side with template expansion, failover across datacenters (Failover), and nearest-instance limits (Near, OnlyPassing) - use them when the answer must survive a consumer restart or support datacenter failover.
Rule of thumb
If a query must serve traffic during a datacenter outage, reach for a prepared query with failover rather than a client-side DNS lookup.