Consul 1.15 Timed Hard Questions — 25 Difficult Questions

Question 1

An operator registers a service with a TTL health check. The service is responsible for updating the check status via the HTTP API. The service fails to send updates for 90 seconds. The check is configured with 'DeregisterCriticalServiceAfter' set to 10 minutes. What is the current health status of the service, and what will happen after 10 minutes?

15 minute time limit — choose an answer to begin.

Accepted Answer

The service is critical; it will be deregistered after 10 minutes.. TTL health checks require periodic updates from the service. If no update is received within the TTL period, the check becomes critical. The 'DeregisterCriticalServiceAfter' field, when set, schedules deregistration of the service instance after the check has been critical for the specified duration. In this case, after 90 seconds the check is critical, and after 10 minutes of being critical, the service is deregistered.

Answer

The service is passing; it will be deregistered after 10 minutes.

Answer

The service is warning; it will be deregistered after 10 minutes.

Answer

The service is critical; it will be deregistered immediately.

Question 2

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 3

If a KV operation returns a 403 Forbidden status, what is the most common cause?

Accepted Answer

The ACL token lacks sufficient permissions.. A 403 Forbidden response from Consul's HTTP API indicates the request was authenticated but the associated ACL token does not have the required policy permissions for the target resource. Consul returns 403 specifically when an ACL is enforced and the token lacks the necessary 'read', 'write', or 'list' capability on the KV prefix being accessed. This is distinct from 401 (missing/invalid token) and 404 (key not found).

Answer

The server is down.

Answer

The data is too large.

Answer

The key does not exist.

Question 4

Which TWO of the following actions occur when a node fails in a Consul cluster?

Accepted Answer

All services on the node are marked critical.. Option A is correct because when a Consul node fails, its health checks stop passing and Consul marks all services registered on that node as critical, reflecting their unhealthy state in the catalog. Option D is correct because Consul's DNS interface only returns healthy service instances by default, so services on the failed node are removed from DNS results until the node recovers. Option B is incorrect because a failed node is not immediately deleted; it remains in the catalog and is only removed after being marked as failed or explicitly deregistered. Option C is incorrect because Consul does not reboot nodes; it only detects and reports failures. Option E is incorrect because Consul is a distributed, fault-tolerant system and a single node failure does not shut down the entire cluster.

Answer

The node is immediately deleted from the cluster.

Answer

The node is automatically rebooted.

Answer

The entire cluster shuts down.

Question 5

You are using Consul 1.15 with Connect enabled. A service 'web' needs to communicate with an upstream service 'api' in a different datacenter. You have configured a mesh gateway in each datacenter. The 'web' service's sidecar proxy is configured with an upstream for 'api'. However, traffic is failing. You check the sidecar proxy logs and see 'no healthy upstream'. What is the most likely cause?

Accepted Answer

The upstream service 'api' is not registered in the remote datacenter or has no healthy instances.. The error 'no healthy upstream' means the sidecar proxy cannot find any healthy instances of the upstream service. In a cross-datacenter setup with mesh gateways, this typically occurs when the upstream service is not registered or has no healthy instances in the remote datacenter. Other issues like missing gateway registration or deny intentions would produce different errors.

Answer

The 'web' service's sidecar proxy is not configured with the correct CA certificate.

Answer

The intention between 'web' and 'api' is set to 'deny'.

Answer

The mesh gateway is not registered as a service in Consul.

Question 6

You need to register a service that runs on a dynamic port. How should the service definition be configured to allow Consul to detect the port?

Accepted Answer

Set 'port' to 0 in the service definition.. Consul allows the use of 0 as a port, and the registration process typically involves discovering the port via an external process or environment variable.

Answer

Set 'port' to 'auto' in the service definition.

Answer

Omit the 'port' field entirely.

Answer

Use the 'address' field for the port.

Question 7

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 8

You are monitoring service health using Consul and want to ensure that a service is automatically removed from the catalog if it remains in a 'critical' state for more than 24 hours. Which configuration key supports this?

Accepted Answer

deregister_critical_service_after. The deregister_critical_service_after setting in a Consul service definition tells Consul to automatically deregister a service instance if its health check remains in the critical state for longer than the specified duration (e.g., '24h'). This is exactly the built-in mechanism for automatic removal of persistently unhealthy services.

Answer

cleanup_interval

Answer

critical_timeout

Answer

remove_service_after

Question 9

If you are running Consul Enterprise, what feature simplifies the management of cross-datacenter secrets?

Accepted Answer

ACL Replication.. In Consul Enterprise, ACL replication is the feature that simplifies the management of cross-datacenter secrets by automatically replicating ACL tokens, policies, and roles from the primary datacenter to secondary datacenters. This ensures consistent access control across datacenters without manual intervention. Other options are not specific to cross-datacenter secret management.

Answer

KV Mirroring.

Answer

Automatic Secret Rotation.

Answer

Centralized Config.

Question 10

A Consul cluster spans multiple datacenters. A service `user-auth` is registered in both `dc1` and `dc2`. A client in `dc1` queries the DNS interface for `user-auth.service.consul`. By default, which instances will be returned?

Accepted Answer

Only instances from `dc1`.. By default, Consul DNS queries are limited to the local datacenter of the agent that receives the query. A client in `dc1` querying `user-auth.service.consul` will only get instances from `dc1`. To discover instances in other datacenters, the query must explicitly include the datacenter, such as `user-auth.service.dc2.consul`. This design promotes locality and avoids unintended cross-datacenter traffic.

Answer

Only instances from `dc2` if `dc1` has no healthy instances.

Answer

Instances from both `dc1` and `dc2`, load-balanced.

Answer

Instances from all datacenters, sorted by latency.

Question 11

A service is intermittently failing to resolve via DNS because it has multiple health checks, some of which are 'warning'. How do you ensure it is only returned when all checks are 'passing'?

Accepted Answer

Use the 'passing' query parameter in the DNS request.. Consul DNS supports a 'passing' query parameter that filters results to only those service instances whose health checks are all passing — warning and critical instances are excluded. Appending ?passing to the DNS query (e.g., 'dig @127.0.0.1 web.service.consul SRV?passing') ensures the service is returned only when every check is green. This is the standard mechanism for strict health-based DNS filtering.

Answer

Configure 'service_prefix' in DNS settings.

Answer

Use the 'stale' query parameter.

Answer

Set 'enable_tag_override' to true.

Question 12

Which of the following parameters are used in a service health check configuration? (Select THREE)

Accepted Answer

interval. Interval, timeout, and script/http are standard parameters in check definitions.

Answer

weight

Answer

service_id

Question 13

What happens to a session if the associated node is marked as 'failed' by the Consul health check?

Accepted Answer

The session is invalidated when the TTL expires.. In Consul, when a node is marked as 'failed' by the health check (for example, the node-level TTL or serf health check fails), the node's sessions are not deleted immediately. Instead, they are invalidated when their associated TTL expires, at which point any locks or KV entries tied to the session are released. This grace period prevents transient network blips from destroying locks held by otherwise-healthy services.

Answer

The session stays active.

Answer

The session is immediately deleted.

Answer

The session is transferred to another node.

Question 14

Which THREE configuration items are part of a complete WAN gossip setup?

Accepted Answer

The 'server' role flag set to true.. Option A is correct because a complete WAN gossip setup requires the 'server' role flag set to true so the agent participates as a server in the gossip protocol and can accept WAN federation traffic. Option B is correct because the 'join-wan' operation needs a list of remote server addresses (retry_join_wan or -join-wan) to establish the WAN gossip pool with other datacenters. Option D is correct because the 'encrypt' key (via encrypt or encrypt_verify_outgoing) secures gossip traffic with symmetric encryption, which is a standard part of a complete WAN gossip configuration. Option C is not required because restricting 'client_addr' to local only is a client interface binding choice, not a WAN gossip requirement. Option E is not required because enabling the 'ui' configuration only exposes the web UI and has no role in forming or securing the WAN gossip pool.

Answer

The 'client_addr' restricted to local only.

Answer

The 'ui' configuration set to true.

Question 15

You are configuring a service check that needs to be ignored if the node is in maintenance mode. What is the correct approach?

Accepted Answer

Use the 'consul maintenance' command on the node.. In Consul, node maintenance mode is enabled using the 'consul maint' (maintenance) command, which places the node into maintenance and causes its service checks to be marked as critical or ignored depending on configuration. The 'consul maintenance' command is the correct CLI approach to toggle maintenance mode on a node so that checks are suppressed. This is the documented mechanism for ignoring checks during planned maintenance.

Answer

Use a tag named 'maintenance'.

Answer

Set 'maintenance_mode' to true in the service definition.

Answer

Set the 'status' to 'maintenance' in the API.

Question 16

A service 'api' is configured with mTLS. You want to rotate the CA root certificate without interrupting existing connections. What is the recommended strategy?

Accepted Answer

Update the CA configuration to include the new root in the 'additional_roots' field.. Consul supports a 'prepared_ca' rotation where the new CA is added to the trust bundle before the old one is removed.

Answer

Disable mTLS globally, update, and re-enable.

Answer

Delete the existing CA and restart all agents.

Answer

Use the 'consul tls ca create' command with the --rotate flag.

Question 17

When using the HTTP health check type, how can you verify that a specific header is included in the health check request?

Accepted Answer

By adding the 'header' object to the check definition. In Consul's HTTP health check definition, you can specify custom headers using the 'header' object, which is a map of header names to arrays of values. This allows the health check request to include specific headers required by the application.

Answer

By appending it to the URL string

Answer

It is not possible

Answer

By setting the environment variable

Question 18

When troubleshooting a service that fails to start its Envoy proxy, which service definition field should you check for incorrect configuration?

Accepted Answer

proxy. The proxy field in a Consul service definition configures the Envoy sidecar, including upstreams, protocol, and the sidecar's port and configuration. If Envoy fails to start, the proxy stanza is the first place to inspect for malformed upstream definitions, invalid protocol values, or missing sidecar service registration.

Answer

checks

Answer