Consul 1.15 Health Checking Practice Test 6 — 15 Questions

Question 1

A Consul administrator is reviewing how check results propagate and wants to understand which factors determine whether a service instance is considered healthy in the catalog. Which two factors directly determine a service's aggregate health status in Consul? (Choose two.)

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

The status of the node-level checks associated with the agent hosting the service. Consul determines a service instance's health from two sources: the checks attached to that service and the checks attached to the node hosting it. A critical node check, such as a failed serfHealth, makes every service on that node unhealthy, while a critical service check makes only that instance unhealthy. Other attributes such as sibling service count, datacenter, or server version do not participate in the health computation.

Answer

The number of other services registered on the same agent

Answer

The Consul version running on the server that handles the catalog write

Answer

The datacenter in which the service is registered

Question 2

An operations engineer registers an external PostgreSQL service on a Consul 1.15 client agent. The database listens on 10.20.30.40:5432 and is not managed by Consul, but a co-located exporter on the same VM exposes readiness at http://127.0.0.1:9187/ready. The engineer wants Consul to gate the service on the exporter's readiness signal while still advertising the database's real address and port to consumers. Which registration best achieves this?

Accepted Answer

Register the service with address 10.20.30.40 and port 5432, and attach an http check with target http://127.0.0.1:9187/ready.. A service definition's address and port fields describe where consumers should connect, while checks are independent probes the agent executes. Pointing an http check at the loopback exporter while advertising the database's real endpoint gives accurate discovery plus a meaningful readiness gate. The other approaches either mispublish the endpoint, detach the check from the service, or substitute a weaker signal.

Answer

Register only an http check named postgres-ready and rely on the check ID to imply the backing service.

Answer

Register the service with address 127.0.0.1 and port 9187, and attach a tcp check on the exporter port.

Answer

Register the service with address 10.20.30.40 and port 5432, and attach a tcp check to 10.20.30.40:5432 with a short interval.

Question 3

A service is registered with a check that has deregister_critical_service_after set to 30m. The service's check enters the critical state due to a transient network partition. The partition is resolved after 20 minutes, and the check returns to passing. What is the effect on the service registration?

Accepted Answer

The service remains registered because the check returned to passing before the 30-minute deregistration timer expired. The deregister_critical_service_after field starts a timer when a check becomes critical and resets that timer if the check leaves the critical state. In this scenario, the check returned to passing after 20 minutes, before the 30-minute threshold, so the service remains registered. Deregistration only happens if the check stays critical continuously for the full configured duration.

Answer

The service is deregistered immediately when the check becomes critical

Answer

The service is deregistered after 30 minutes from the initial registration, regardless of check state

Answer

The service is deregistered because it was critical at any point

Question 4

A service team wants its check to be automatically deregistered along with the service when the service is deregistered, but they also want the check to survive a Consul agent restart without being manually recreated. Which configuration achieves both goals?

Accepted Answer

Define the check inside the service block with a name but no explicit check ID, and register the service through the agent configuration directory.. Nesting a check inside a service block without an explicit check ID causes Consul to generate an ID linked to the service, so deregistering the service also removes the check. Declaring that service in the agent configuration directory means the agent re-registers it on every startup, providing restart persistence. API-only registration and in-memory reliance fail both the automatic removal and the restart-survival requirements.

Answer

Define the check in the service block with an explicit check ID that differs from the service ID.

Answer

Register the check separately through the HTTP API with a standalone check ID and no service association.

Answer

Register the service and check via the HTTP API and rely on the agent's in-memory state to persist across restarts.

Question 5

A service is registered with a health check that has the field deregister_critical_service_after set to "10m". The service's check has been in the critical state for 15 minutes. What will Consul do?

Accepted Answer

The service will be deregistered from the catalog.. When deregister_critical_service_after is set, Consul automatically deregisters a service if its check remains critical for longer than the specified duration. In this case, 15 minutes exceeds the 10-minute threshold, so the service is removed from the catalog. The check status does not change to warning, and maintenance mode is not involved.

Answer

The check will be marked as warning.

Answer

The service will be placed in maintenance mode.

Answer

The check will be restarted and re-evaluated.

Question 6

A Consul operator needs to register a health check that runs a custom binary located at /opt/checks/validate.sh every 15 seconds. The check should be considered passing only when the script exits with code 0. Which check definition correctly implements this?

Accepted Answer

{"check": {"id": "validate", "name": "validate", "args": ["/opt/checks/validate.sh"], "interval": "15s"}}. The args field is the correct way to define a script check in Consul 1.15. It takes an array containing the command and any arguments, and the check passes when the command exits with code 0. The script field is deprecated, and http and tcp fields define entirely different check types that cannot execute local binaries. Using args also avoids shell interpretation, which is safer and more predictable.

Answer

{"check": {"id": "validate", "name": "validate", "script": "/opt/checks/validate.sh", "interval": "15s"}}

Answer

{"check": {"id": "validate", "name": "validate", "tcp": "/opt/checks/validate.sh", "interval": "15s"}}

Answer

{"check": {"id": "validate", "name": "validate", "http": "http://localhost/opt/checks/validate.sh", "interval": "15s"}}

Question 7

A platform team runs a Consul 1.15 cluster where a legacy VM service registers its health check through the /v1/agent/check/register HTTP API rather than a service definition file. The check is a script check that takes about 40 seconds to finish on a busy host. Operators notice the check flaps to critical roughly every minute even though the script always exits 0 when run manually. The agent's check_update_interval is left at the default. Which change most directly resolves the flapping without altering the script itself?

Accepted Answer

Raise the check's timeout value so it exceeds the script's worst-case runtime.. Consul enforces the check's timeout when executing script checks; a script that runs longer than the timeout is terminated and the check reports critical. Because the observed runtime of roughly 40 seconds exceeds the default timeout, the check fails on schedule, producing the regular flapping. Increasing the timeout to exceed the worst-case runtime lets the script complete and report its genuine result.

Answer

Increase the agent's check_update_interval to a value larger than the check interval.

Answer

Set the check's status field to passing so the agent stops executing the script.

Answer

Change the check type from script to TTL and have the script call the TTL endpoint on success.

Question 8

A Consul service check is configured with `deregister_critical_service_after: "10m"`. The service enters a critical state due to a failed check. What happens after 10 minutes if the check remains critical?

Accepted Answer

The service is deregistered from the Consul catalog.. When a service check is critical for the duration specified in `deregister_critical_service_after`, Consul automatically deregisters the service from the catalog. This prevents dead services from lingering in service discovery. The service must be re-registered to reappear. Other options describe different behaviors such as maintenance mode, check disabling, or status change, none of which are caused by this field.

Answer

The service is marked as maintenance mode and removed from DNS.

Answer

The service is moved to a warning state and remains registered.

Answer

The check is disabled but the service remains registered.

Question 9

An operator registers a service with a TTL check and forgets to send periodic updates. After the TTL expires, what status does Consul report for that check, and what is the immediate effect on service discovery?

Accepted Answer

The check becomes critical, and healthy instances of the service are excluded from DNS and health API results.. A TTL check must be updated within its TTL or the agent marks it critical. Because Consul's DNS and health API default to returning only passing instances, the service stops being discoverable as healthy until a new update arrives. This makes heartbeat reliability a critical design consideration for TTL-based checks.

Answer

The check becomes warning, and the service remains discoverable but is deprioritized in DNS results.

Answer

The check remains passing until the agent restarts, because TTL expiry is evaluated lazily.

Answer

The check transitions to unknown, and the service is still returned by DNS with a warning flag.

Question 10

An operations engineer wants a service registered in Consul to be deregistered automatically from the catalog when its health check has been critical for an extended period, without any external tooling. The service definition is written in HCL and loaded via the agent's config directory. Which combination of settings accomplishes this?

Accepted Answer

Set deregister_critical_service_after on the check and define the check inside the service block. Automatic removal of a service whose check stays critical is achieved with the check-level deregister_critical_service_after setting, which the local agent enforces. Defining the check inside the service block binds that behavior to the specific service instance. No external process is required, satisfying the requirement to avoid outside tooling. The other choices either do nothing automatically or reintroduce external scripts and manual tagging.

Answer

Set the check's status to "critical" at registration and rely on Consul's garbage collector

Answer

Set the service's tags to include "critical" and configure a prepared query to filter them

Answer

Enable enable_script_checks and add a script that calls the /v1/catalog/deregister endpoint

Question 11

An engineer registers an external service for a third-party payment gateway that cannot run a Consul agent. The registration uses an alias health check that points at a Consul node named 'edge-proxy-01' and a service named 'payment-gateway'. The external service stays healthy in the catalog as long as the proxy node and service are passing. A second engineer later adds a separate script check directly to the same external service definition. After a deployment, the payment gateway disappears from DNS even though the edge proxy node and its payment-gateway service both report passing. What is the most likely cause?

Accepted Answer

The added script check is failing on the node running the catalog registration, and any failing check on a service marks the whole service critical.. Service health in Consul is the aggregate of every check attached to that service, and the worst state wins. Adding a script check that fails on the registering node therefore pushes the external payment gateway to critical even though the alias check still reflects a passing edge proxy. Since DNS queries filter to passing instances by default, the service vanishes from resolution until the failing check is corrected.

Answer

Alias checks cannot coexist with other checks on the same service, so Consul silently discards the alias result when a second check is added.

Answer

The external service node name collides with the alias target node, causing Consul to overwrite the alias check status with the external node's own health.

Answer

The alias check requires the target service to be registered on the same agent, so it failed once the deployment moved the proxy to another datacenter.

Question 12

A team is standardizing health check definitions across a fleet of Consul 1.15 agents. They want checks that can be expressed entirely in HCL and do not require an external script interpreter on the node. Which two check types meet these criteria? (Choose two.)

Accepted Answer

http. Both http and tcp checks are evaluated directly by the Consul agent using its internal networking stack, and both are fully declarable in HCL without any external interpreter or binary. Script and docker checks depend on external runtimes, while alias checks merely mirror other checks and are not standalone probes. This makes http and tcp the portable choices for a standardized fleet.

Answer

docker

Answer

script

Answer

alias

Question 13

A Consul 1.15 operator is defining a TTL-based health check for a batch job that only reports in when it completes a run. The job must be marked critical if it has not checked in within 30 minutes. The operator wants the check to start in the passing state so a freshly registered job is not immediately flagged. Which configuration block accomplishes this?

Accepted Answer

check = { id = "batch", ttl = "30m", status = "passing" }. TTL checks are passive: the service must periodically call the pass, warn, or fail endpoints, and the ttl field sets the deadline after which Consul flips the check to critical. The status field is the documented way to seed the initial reported state, so a newly registered batch job can start as passing and only become critical if it misses its 30-minute check-in window.

Answer

check = { id = "batch", ttl = "30m", deregister_critical_service_after = "30m" }

Answer

check = { id = "batch", ttl = "30m", fail_fast = true }

Answer

check = { id = "batch", interval = "30m", status = "passing" }

Question 14

A team is writing Consul 1.15 service definitions for a set of gRPC services that expose the standard gRPC health checking protocol on a dedicated port, and they want Consul to actively probe that protocol rather than a plain TCP connect. Which two settings must be present in each check block to make Consul perform a gRPC health check against the service? (Choose two.)

Accepted Answer

interval = "10s". A gRPC health check is selected by the grpc field, which carries the address Consul dials, and like any active check it needs an interval to define the probe cadence. Together those two settings make the agent invoke the standard gRPC health checking protocol against the service; TLS, a method name, and a TCP address are not required to enable that behavior.

Answer

tcp = "127.0.0.1:50051"

Answer

method = "grpc.health.v1.Health/Check"

Answer

grpc_use_tls = true

Question 15

An operator configures a TCP health check for a database service on port 5432, specifying tcp = "localhost:5432" and interval = "10s". The database process is running and accepting connections, but the check is reported as critical. What is the most likely explanation?

Accepted Answer

The Consul agent does not have network permissions or the database is bound only to a specific interface not matching localhost.. A TCP health check succeeds only if the agent can establish a TCP connection to the specified address and port. Even if the database is running, it might be listening on a different interface (e.g., only on a specific IP, not localhost) or the agent might lack the necessary permissions. The configured address localhost:5432 must match where the database is actually listening. Therefore, the most likely explanation is a mismatch in the listening address or a permission issue preventing the connection.

Answer

The check is being executed from a different network namespace than the database process.

Answer

The interval is too short; Consul requires a minimum interval of 30 seconds for TCP checks.

Answer

The TCP check requires an explicit timeout value, and without it the check immediately fails.