Health Checking practice questions

InitialStatus

Why it fails: Sets the status of the check when it is first registered.

Interval

Why it fails: Controls how often the check runs, not the wait time.

DeregisterCriticalServiceAfter

Why it fails: Controls when a service is removed after failure.

advertise_addr

Why it fails: Used for cluster communication.

client_addr

Why it fails: Used for HTTP/DNS/RPC API access.

check_addr

Why it fails: This parameter does not exist.

allow_unprivileged_scripts

Why it fails: This is not a valid Consul agent configuration option.

disable_remote_exec

Why it fails: Controls Consul's remote execution feature, not local script checks.

enable_local_script_execution

Why it fails: This is not a valid configuration key.

XML

Why it fails: Not supported.

INI

Why it fails: Not supported.

YAML

Why it fails: Not natively supported by the agent config loader.

It is automatically removed from the catalog

Why it fails: It remains in the catalog until deregistered.

It remains passing

Why it fails: The server eventually marks it as critical.

It stays in the last known state

Why it fails: Consul updates the state based on heartbeat/check failures.

check_exec

Why it fails: check_exec is not a Consul service definition field; the command is specified via args within the check stanza, so this key is silently ignored. A dedicated exec key would suit tools with separate script hooks, not Consul's health check schema.

command

Why it fails: Consul does not define a command field inside the service definition's check block; the shell command belongs in args, so command is unrecognised and the check fails to register. A command key would be correct in Docker or systemd health configurations, not Consul.

action

Why it fails: Consul's health check block uses no action field; the executable is declared under args within the check stanza, so action is ignored and no command runs. An action-style field would fit systems where a named handler is invoked, not Consul's service definition schema.

It inherits the agent's check interval

Why it fails: No such global default exists.

It defaults to 10 seconds

Why it fails: Consul requires an explicit interval.

It runs once and stops

Why it fails: It needs an interval to repeat.

ICMP

Why it fails: Not a native check type.

UDP

Why it fails: Not a native check type.

SNMP

Why it fails: Not a native check type.

tls_insecure

Why it fails: Not a valid parameter.

disable_tls

Why it fails: This would disable HTTPS entirely.

ignore_cert

Why it fails: Not a valid parameter.

weight

Why it fails: Weight is a service attribute.

service_id

Why it fails: This is for the service itself.

restart

Why it fails: Not supported.

suspend

Why it fails: Not supported.

fail

Why it fails: Though it sets critical, 'fail' is not the API endpoint name; 'warn' and 'pass' are standard.

terminated

Why it fails: Not a standard state.

pending

Why it fails: Not a standard state.

timeout

Why it fails: Optional.

http

Why it fails: Irrelevant for TCP.

Set `tls_server_name` to `payments.internal` in the check definition.

Why it fails: The `tls_server_name` field overrides the SNI value sent during the TLS handshake, which is useful when the certificate's subject does not match the dialed address. Here the address already matches the certificate name, so this field changes nothing about the untrusted CA or the missing bearer token and cannot resolve the critical status.

Set `method` to POST so the agent sends credentials in the request body.

Why it fails: The `method` field changes the HTTP verb used by the check, but it does not carry credentials and the endpoint expects a bearer token in a header, not in a body. Changing the verb to POST would likely break a health endpoint that only accepts GET, and it leaves both the TLS trust problem and the authentication problem unaddressed.

Set `tls_skip_verify` to true in the check definition.

Why it fails: Setting `tls_skip_verify` to true disables certificate chain and hostname verification, which would let the check pass, but it sacrifices the assurance that the agent is talking to the legitimate payments service and is not the recommended fix when a CA certificate can be supplied. It also does nothing for the missing bearer token, so it cannot be one of the two required additions.

address

Why it fails: The address field in a check definition sets the address of the service being checked, but it is used in conjunction with the service's port. For a TCP check, if you specify address and port, Consul will use them. However, the question asks for the field within the check to specify the target, and the correct field is tcp, which includes host and port. Using address alone without tcp may not override the default check target.

http

Why it fails: The http field is used for HTTP health checks and specifies a URL. It is not applicable for a TCP check. Using http would change the check type entirely and would not perform a simple TCP connection to the desired address and port.

service_id

Why it fails: The service_id field associates the check with a specific service instance but does not control the network address used for the check. It is used for registration and identification, not for specifying the target host and port of a TCP check.

status

Why it fails: The status field sets the initial state of the check, but it is not required. If omitted, the check starts in the critical state until the first successful run. Operators may set it to passing to avoid initial critical alerts, but it is optional and does not affect the check's ability to run.

notes

Why it fails: The notes field provides a human-readable description of the check. It is entirely optional and has no effect on the execution or result of the health check. It is used for documentation and UI display only, so it is not required for a functional script check.

timeout

Why it fails: The timeout field is optional for script checks. If omitted, Consul uses a default timeout value. While it is good practice to set a timeout to prevent hung scripts from delaying health updates, it is not a required field. The check can function without an explicit timeout.

A tcp check with tcp: "10.0.4.21:8443" and a header stanza specifying X-Health-Token.

Why it fails: TCP checks only attempt a socket connection and immediately close it; they cannot send HTTP headers, evaluate response codes, or validate TLS certificates. The header stanza is not a valid field for tcp checks, so the definition would be rejected or silently ignored. This check would report success merely because the port is listening, even if the readiness endpoint returns 500.

A script check that runs curl -k -H "X-Health-Token: s3cr3t" https://10.0.4.21:8443/ready and interprets a zero exit code as passing.

Why it fails: A script check can technically perform the request, but it relies on curl being installed on every node, spawns a process on each interval, and the -k flag disables certificate validation entirely. It also bypasses Consul's native HTTP check scheduling and status mapping, which is unnecessary here because the built-in http check already supports custom headers and TLS verification via tls_skip_verify.

An http check with http: "https://10.0.4.21:8443/ready" and method: "HEAD", relying on the agent's default header injection.

Why it fails: Consul does not inject arbitrary headers by default; the X-Health-Token header would be missing and the endpoint would return 401 or 403, marking the service critical. A HEAD request is also not guaranteed to be supported by the readiness handler. Without an explicit header map and with default TLS verification behaviour, this definition cannot satisfy the stated authentication and CA requirements.

The check definition uses tcp = "localhost:5432" but the interval is set to "10s" and the timeout is set to "1s".

Why it fails: A 1-second timeout is short but would likely still succeed for a local TCP connection if the port is open. The timeout is not the most likely cause of an immediate critical state. The issue is more fundamental: the agent cannot reach the address at all, not that it is too slow to respond.

The check definition uses tcp = "localhost:5432" but the service is registered with a different port in its service definition.

Why it fails: The service port and the check port are independent. The check targets port 5432 directly, so a mismatch with the service port would not affect the check's ability to connect. The check would still succeed if the database is listening on 5432 and reachable, regardless of the service's registered port.

The check definition uses tcp = "localhost:5432" but the agent is configured with enable_script_checks = false.

Why it fails: enable_script_checks controls script checks, not TCP checks. TCP checks do not require this setting and are enabled by default. Disabling script checks would not prevent a TCP check from running. Therefore, this setting is irrelevant to the TCP check's failure.

The check's interval is set to 10s, but the Consul agent's clock is skewed by 15 seconds relative to the service.

Why it fails: Clock skew between the Consul agent and the service does not affect the outcome of an HTTP check, as the check is initiated by the agent and evaluated based on the response. The interval only controls frequency. Clock skew might affect TTL checks, but not HTTP checks. This is not a valid cause for critical status.

The check is defined with method = "POST" instead of GET, but the service only accepts GET.

Why it fails: The stem states the check is configured with http = "https://internal.service/health" without specifying a method. By default, Consul uses GET. If method were POST and the service rejected it, the check would fail. However, the stem does not indicate a method mismatch, and the logs show requests returning 200, implying GET is working. This is not a likely cause given the scenario.

The service's health endpoint returns a 200 status code but includes a response body that Consul cannot parse.

Why it fails: Consul does not parse the response body for HTTP checks; it only considers the status code. A 200 response is sufficient for a passing check regardless of body content. Therefore, an unparseable body would not cause a critical status. This option misrepresents how HTTP checks evaluate success.

A tcp check with interval = "10s" and timeout = "45s"

Why it fails: Raising the timeout to 45s does give the blocked worker room to answer, but a 10s interval means Consul is opening a new socket probe every 10 seconds while the previous probes may still be in flight. Consul does not queue these indefinitely, yet the short interval generates noisy, overlapping connection attempts against a process that is deliberately stalled, producing misleading failure records even though the socket is technically reachable.

An http check with method = "GET" and timeout = "5s"

Why it fails: This worker deliberately has no HTTP listener, so an HTTP check cannot succeed no matter how the timeout is tuned. Consul would receive connection-refused or malformed responses on port 9100 and immediately record the check as critical. The scenario explicitly rules out an HTTP endpoint, so choosing this type misreads the service's actual interface and would generate constant false unhealthy states.

An alias check that aliases the node-level Serf health check

Why it fails: An alias check simply mirrors the state of another existing check, most commonly the node's SerfHealth. That reflects whether the Consul agent itself is alive, not whether the batch worker's port 9100 socket is accepting connections. If the worker crashed while the agent kept running, this alias would still report passing, which defeats the entire purpose of liveness monitoring here.