HashiCorp Certified: Consul Associate (Consul 1.15) (Consul 1.15) (Consul 1.15) — Questions 226–265

Consul-template watches the Consul catalog and KV store, then renders templates into local configuration files and reloads dependent services. Across datacenters it queries the relevant Consul servers, so the stem's requirement for generating configuration from Consul data is met directly.

When destination_type is left at its default of service, the sidecar resolves the upstream through Consul's service discovery using destination_name. The proxy watches the catalog for healthy instances and load-balances across them, so IP changes and scaling events are handled automatically. Hard-coding an address would defeat the purpose of dynamic discovery.

A TTL check starts in a critical state and only becomes passing when the service calls the /v1/agent/check/pass/<check_id> endpoint, or when the check is registered with a non-critical initial status. If the application never sends the heartbeat within the TTL window, Consul marks the check critical and excludes the instance from healthy DNS answers. This matches the observed behavior exactly.

By default, Consul DNS queries are scoped to the local datacenter of the agent handling the query. A client in `dc1` querying `user-auth.service.consul` will receive only instances registered in `dc1`. To query other datacenters, the client must explicitly specify the datacenter, such as `user-auth.service.dc2.consul`. This default behavior ensures locality and reduces cross-datacenter traffic.

The consul health service command queries Consul's health endpoint for a registered service, returning its instances and passing or failing checks. This directly reports service status, matching the requirement to verify a registered service's health.

Raising the agent's log verbosity to debug makes Consul emit detailed health-check execution output, including script invocations and timing, which reveals where a hanging check stalls. The -log-level=debug flag therefore exposes the check's internal behaviour in the agent logs.

A health check defines how Consul probes a service instance's availability, determining whether it is registered as passing or failing in the catalogue. It is a core service-definition block, alongside name and port, controlling readiness and DNS or load-balancing eligibility.

Three servers allow the Raft consensus quorum of two to survive a single node failure while still electing a leader, giving high availability without the write-latency penalty that five or more servers introduce in one datacenter.

Consul servers use the Serf library, which implements the SWIM gossip protocol, to exchange membership and failure-detection messages across the WAN gossip pool. SWIM's infection-style dissemination lets datacentre servers converge on membership state without a central coordinator.

The `consul connect envoy` command generates the Envoy bootstrap configuration and starts the sidecar proxy process, registering it with Consul's service mesh. This directly satisfies the stem's requirement by launching and managing the per-service Envoy sidecar, handling its lifecycle and configuration without manual bootstrap files.

Consul DNS only returns healthy instances by default. If a service's health check is critical, it is considered unhealthy and is omitted from DNS responses. This is the most likely reason the service does not appear in DNS queries, even though it is registered in the catalog.

The HTTP check's 'header' object accepts a map of header names to arrays of values, which Consul sends with each probe request. Defining it in the check block lets you assert that the specified header reaches the endpoint, satisfying the verification requirement.

The upstreams block names the destination service and the local port the sidecar listens on. Binding local port 6379 lets the application connect to localhost:6379, and the sidecar transparently forwards to the 'redis' service through mTLS, satisfying the application's expectation without code changes.

The interval parameter defines the duration between consecutive health check executions, so altering it changes how often Consul probes the service. Shorter intervals detect failures faster; longer intervals reduce probe traffic but delay status updates.

Consul's DNS interface resolves services through standard DNS queries, so existing applications discover services without any code modification or SDK integration. This satisfies the stem's benefit criterion by removing development effort entirely from the discovery path.

The `-detailed` flag on `consul kv get` prints the key's metadata fields, including `CreateIndex`, `ModifyIndex`, `LockIndex`, `Flags`, and `Session`, in addition to the value. It is the intended CLI way to inspect KV entry metadata without issuing raw HTTP requests, which is precisely what the operator needs here.

The `proxy` block configures the sidecar's Envoy settings, including upstreams, listeners and bootstrap options. Incorrect values here directly prevent the proxy from starting, so it is the field to inspect first when diagnosing startup failure.

Blocks check traffic.

SRV records include the service port as part of their data, so Consul cannot synthesize a meaningful SRV answer without a port. The service registration must therefore include a port field; if it is omitted or zero, Consul either omits the SRV record or returns a record with port 0, which clients cannot use to connect. This is why the port is essential for SRV-based discovery.

Consul's native health checks cannot reference another service's status, so dependency-aware health must be scripted. A script check queries the dependency's health endpoint or Consul API and returns the appropriate exit code, letting the registered service report unhealthy when its dependency fails.

Appending `keys=true` to a KV list request returns only key names, omitting values and metadata from the response body. This directly satisfies the stem's payload-reduction constraint, since the default list operation includes values for every key under the prefix, inflating the response unnecessarily.

Consul Watches monitor a specified KV prefix or key for changes and invoke a handler, such as an executable script, when an update occurs. This satisfies the requirement to observe the KV store and run a command in response.

The check field attaches a health check definition to the service, specifying the script, interval and status thresholds Consul uses to determine whether that service instance is healthy and should remain in DNS or catalog results.

`retry_join_wan` is specifically designed to provide addresses of servers in other datacenters to join the WAN gossip pool. When set, the agent will attempt to join the WAN gossip pool using the provided addresses. This is the correct way to federate a new datacenter with existing ones. It is commonly used in multi-datacenter deployments to automate WAN joining.

Consul treats a service with no registered health checks as healthy by default, so its status is reported as passing. No check can fail, meaning the service remains in the catalog and receives traffic until checks are defined.

The service block can advertise the database's genuine address and port independently of the check, and an http check may target any URL the agent can reach, including a loopback exporter. This keeps service discovery accurate while gating catalog health on the exporter. It is the cleanest way to monitor an unmanaged dependency through a sidecar signal without exposing the exporter as a service.

An HTTP check transitions to critical when its request exceeds the configured timeout, since Consul cannot confirm the endpoint is healthy. The timeout constraint in the stem is satisfied because no successful response is received within the allowed interval, marking the service unhealthy.

When a TTL check is not updated within its TTL, Consul marks it critical. By default, DNS queries and the health API return only passing instances, so the service is effectively removed from the healthy set until an update is sent. This behaviour is the primary reason TTL checks require a reliable heartbeat mechanism from the service or its supervisor.

Consul's KV store supports acquire and release operations backed by session-based consensus, letting clients hold a lock key exclusively. This satisfies the distributed locking use case: multiple service instances coordinate leader election or serialised access without an external coordinator.

The intention check subcommand evaluates the effective authorization decision between a source and destination, reporting whether the connection is allowed or denied. It accounts for matching intentions and the default policy, making it the right tool to verify permissions without generating actual mesh traffic.

Registering a service with kind = "connect-proxy" and a proxy destination identifies it as the sidecar that fronts another service, so Consul wires the proxy's listeners and upstreams to that target rather than treating it as an ordinary service.

Consul's HTTP check marks the service critical for any HTTP response code outside the 2xx range, including 500. Since the endpoint returns 500 when the database connection fails, Consul reports critical. This correctly signals that the service is running but unhealthy and should not receive traffic.

Sessions are kept alive only by timely renewal; if the client cannot reach the servers to renew within the TTL, the session expires and Consul deletes it, which releases every lock and invalidates every key held by that session. The severed link prevented renewal, so the lock was freed exactly as designed.

A service's aggregate health includes the status of the node on which it runs. If a node-level check such as the built-in serfHealth check is critical, the node is unhealthy and every service on that node is reported as unhealthy in catalog queries, even if the service's own check is passing.

The WAN gossip pool contains only Consul server nodes, one per datacentre, which exchange membership and datacentre information across the federation. Clients join only the LAN pool, so this statement accurately describes WAN gossip behaviour.

This is the correct pattern for leader election. Each candidate creates a session and attempts to acquire a shared key. Only one session can hold the lock at a time. The successful acquirer becomes the leader, and others receive a false response and should retry or wait.

A TTL check inverts the model: the application must periodically call Consul's HTTP pass endpoint to reset the timer, and Consul marks it critical if the heartbeat lapses. This suits legacy apps lacking HTTP or TCP endpoints, since they signal health themselves.

ACL replication requires the secondary datacenter to authenticate to the primary using a token with replication permissions. If acl_replication_token is missing, expired, or lacks the necessary policies, the secondary cannot pull token and policy updates. As a result, tokens created in the primary will not be replicated, and the secondary will not recognize them for authorization.

The `deregister_critical_service_after` setting controls how long a service can be critical before being automatically deregistered. By default, it is 30 minutes. If the service is intermittently failing health checks, increasing this value gives more time for the service to recover before being removed. This is the correct approach to prevent deregistration due to temporary failures.

The tls_skip_verify field is a boolean on HTTP checks that instructs the Consul agent to skip TLS certificate verification for that specific check. Setting it to true allows the check to succeed against a service using a self-signed or otherwise untrusted certificate without altering global agent TLS settings. This is the correct targeted approach for the scenario.