Consul 1.15 Health Checking Practice Test 4 — 15 Questions

Question 1

You are troubleshooting a health check that seems to be hanging. Which flag, if available, would provide more information about the check's execution within the agent logs?

Accepted Answer

-log-level=debug. Increasing the agent's log level to 'debug' provides detailed information about check execution and processing.

Answer

-verbose

Answer

-monitor-checks

Answer

-trace

Question 2

What is the consequence of having a service with no health checks registered?

Accepted Answer

The service status is 'passing'. In Consul, a service registered without any health checks is treated as healthy by default, so its status is reported as 'passing'. Consul only marks a service as critical if an associated check fails; with no check defined, there is nothing to fail, so the service remains passing and is returned by DNS and service discovery queries.

Answer

The agent will error out

Answer

The service is ignored by DNS

Answer

The service is critical

Question 3

What information does the Consul HTTP API return for a health check? (Select TWO)

Accepted Answer

Output. The Consul HTTP API health check response includes the Status field (E), which reports the check's current state as "passing", "warning", or "critical", and the Output field (B), which contains the human-readable message or command output produced by the check. These two fields are part of the standard check object returned by endpoints such as /v1/health/checks/<service> and /v1/agent/checks. Service CPU usage (A) is not reported by Consul health checks, as Consul does not collect resource metrics. Service port (C) is part of the service definition, not the health check object returned by the health API. Check uptime (D) is not a field Consul tracks or returns for health checks.

Answer

Service CPU usage

Answer

Service port

Answer

Check uptime

Question 4

Which feature allows you to define a health check that depends on the health of another service?

Accepted Answer

You must implement this logic in a script check. Consul does not have a native 'service dependency' health check type. To make one service's health depend on another, you must implement the logic yourself, typically in a script check that queries the Consul API or DNS for the other service's health and returns an appropriate exit code. This is the documented and practical approach for cross-service health dependencies.

Answer

Service dependency field

Answer

Cross-service monitoring

Answer

Service grouping

Question 5

You observe a 'warning' status for a service. What is the most common reason for this?

Accepted Answer

The service is operating but with performance issues. In Consul, a 'warning' status means the check is returning a warning result — typically the service is up and responding but is degraded or experiencing performance issues. This is distinct from 'critical', which indicates failure. The most common cause of warning is a service that is operational but not fully healthy.

Answer

The agent is restarting

Answer

The network is down

Answer

The service crashed

Question 6

Which of the following conditions can cause a health check to transition to the 'critical' state? (Select TWO)

Accepted Answer

The HTTP check times out. Option A is correct because a health check that times out — for example, an HTTP/HTTPS check that fails to receive a response within its configured timeout interval — is treated as a failed check and drives the target into the 'critical' state. Option B is correct because a script-based health check that returns a non-zero exit code signals failure (exit code 0 conventionally means success), so the check is marked unhealthy and transitions to 'critical'. Options C, D, and E do not belong: an idle service is not inherently unhealthy, a 200 OK response is a successful HTTP status that keeps the check healthy, and 50% disk usage is well below typical warning/critical thresholds, so none of these would trigger a critical health state.

Answer

The service is idle

Answer

The service returns a 200 OK

Answer

The disk space is 50% full

Question 7

Where can you define health checks in Consul? (Select THREE)

Accepted Answer

Agent configuration files. Health checks in Consul can be defined in agent configuration files (A), where you place `check` blocks or `checks` arrays in HCL/JSON to register node-level or service-level checks that the agent loads at startup. They can also be defined via the HTTP API (B), using endpoints such as `PUT /v1/agent/check/register` to register a check at runtime, or within a service registration payload sent to `/v1/agent/service/register`. Service definition files (E) are also valid, since a service registration JSON/HCL file can include a `checks` array (or a single `check`) that defines checks tied to that service, commonly loaded via the agent's `services` configuration directory. The Consul UI (C) is only for viewing and managing existing checks, not for authoring their definitions, and the Consul KV store (D) holds arbitrary key/value data and has no role in defining health checks.

Answer

Consul UI

Answer

Consul KV store

Question 8

When troubleshooting a failing health check, which tools are recommended? (Select TWO)

Accepted Answer

Consul UI. The Consul UI (A) is recommended because it visually displays the current health status of each service and node, showing which checks are passing, warning, or critical, and it lets you drill into the specific check output to identify the failure. Agent logs (B) are recommended because the Consul agent records detailed health check execution results, errors, and state transitions, which reveal why a check is failing (e.g., script exit codes, timeouts, or connection errors). DNS query (C) is not appropriate here because DNS only resolves service names to addresses and does not expose health check diagnostics. The Consul key-value store (D) holds arbitrary configuration data and is unrelated to health check troubleshooting. System metrics (E) provide resource usage data but do not show Consul health check status or failure reasons.

Answer

DNS query

Answer

Consul key-value store

Answer

System metrics

Question 9

What is true about Consul health checks? (Select TWO)

Accepted Answer

They run on the local agent. They run locally on the agent and can be associated with specific services.

Answer

They only support GET requests

Answer

They always run on the server

Answer

They cannot be disabled

Question 10

What components can affect the outcome of a health check? (Select THREE)

Accepted Answer

Network connectivity. Network connectivity (A) is correct because a health check must be able to reach the target service or node over the network; if the path is blocked, the check fails regardless of the service's actual state. Application responsiveness (C) is correct because the check's result depends on whether the application actually answers within the configured timeout and returns the expected status. Agent configuration (D) is correct because settings such as check interval, timeout, and the check definition itself determine when and how the check runs and what result is reported. The client browser (B) is not involved, since health checks are performed by agents or servers, not by end-user browsers. Consul server uptime (E) is not a direct component of an individual health check outcome, as checks are executed by the local agent and only aggregated by the servers.

Answer

Client browser

Answer

Consul server uptime

Question 11

Which of the following are true regarding TTL checks? (Select TWO)

Accepted Answer

They require the app to push updates. Option A is correct because TTL-based checks rely on the application or service itself to push updates (e.g., via an API or heartbeat) before the TTL expires; the monitoring system does not actively poll, so the app must refresh the record to keep the check healthy. Option D is correct because TTL checks are event-driven rather than scheduled: instead of running on a fixed interval, they expire after a defined time-to-live, making them the only check type without a polling interval. Option B is wrong because TTL checks are not automatically removed; they transition to a failed/expired state when the TTL lapses unless the app pushes an update. Option C is wrong because TTL checks are not inherently faster than script checks—speed depends on the push mechanism and network, not on the check type itself. Option E is wrong because TTL checks are explicitly not polled at a fixed interval; that description applies to standard interval-based checks.

Answer

They are automatically removed

Answer

They are faster than script checks

Answer

They are polled at a fixed interval

Question 12

A Consul cluster has a service registered with an HTTP health check pointing to https://10.0.0.5:8443/health. The check is failing with a TLS certificate verification error even though the service is healthy. The operator wants Consul to skip certificate verification for this specific check without disabling TLS globally. Which check configuration field should be set?

Accepted Answer

tls_skip_verify. HTTP health checks in Consul support a tls_skip_verify boolean that disables certificate verification for that individual check. This allows checks against services with self-signed or internal CA certificates to succeed without weakening the agent's global TLS posture. The other listed fields either apply to agent-level TLS settings or to unrelated aspects of the check request.

Answer

ca_file

Answer

verify_outgoing

Answer

method

Question 13

A platform team runs Consul agents in server mode on three dedicated hosts and client agents on each application node. They need a check that verifies the Consul servers themselves are reachable on the Serf LAN gossip port from the perspective of every client agent, so that a partitioned server is flagged even if it still answers HTTP requests on port 8500. Which check definition should they register on each client agent?

Accepted Answer

A TCP check with `tcp` set to the server's address on port 8301, registered as a check on each client agent.. Testing reachability of the Serf LAN port from each client agent requires a check that actually opens a connection to that port on the server host. A TCP check pointed at port 8301 does exactly that, and because it is registered on the client agent, the health status reflects the client's own network path rather than the server's self-assessment. HTTP or script checks that exercise the API can pass while gossip connectivity is broken.

Answer

An HTTP check against `http://<server>:8500/v1/status/leader` on each server, with `interval` set to 10s.

Answer

A UDP check with `udp` set to the server's address on port 8301, registered on each client agent.

Answer

A script check that runs `consul members -status=alive` and fails if any server is missing from the output.

Question 14

A Consul service is registered with a TTL health check. The application owner wants the service to be marked unhealthy automatically if the application stops sending heartbeats, without requiring a separate check script or endpoint. The application can send heartbeats every 10 seconds. Which TTL check configuration should be used to mark the service unhealthy after no heartbeat is received for 30 seconds?

Accepted Answer

check { ttl = "30s" }. A TTL check expires and becomes critical if no heartbeat is received within the configured ttl duration. Setting ttl to 30 seconds aligns with the requirement to mark the service unhealthy after 30 seconds without a heartbeat. The interval, timeout, and status fields do not replace the ttl field for heartbeat-based checks.

Answer

check { ttl = "30s", status = "passing" }

Answer

check { ttl = "10s" }

Answer

check { interval = "30s", timeout = "10s" }

Question 15

A platform team runs a Consul 1.15 cluster where a critical payment service is registered with a TTL health check. The service owner wants Consul to mark the check as critical if the application fails to renew the TTL for more than one minute. Which configuration field should be set in the service definition to enforce this behavior?

Accepted Answer

ttl. TTL health checks are passive: the application must periodically renew the check via the HTTP API. The ttl field defines the maximum time allowed between renewals before Consul transitions the check to critical. Other fields like interval or timeout apply to active checks, and deregister_critical_service_after controls removal, not the critical transition.

Answer

deregister_critical_service_after

Answer

interval

Answer

timeout