Consul 1.15 Practice Test 1 — 30 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?

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

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

A Consul 1.15 operator is configuring a service mesh with Connect and needs to ensure that the sidecar proxy for 'frontend' can establish mTLS connections to the 'backend' service. The operator has already registered both services with Connect sidecars. Which two actions are required to allow this communication? (Choose two.)

Accepted Answer

Configure the 'frontend' service registration with an upstream stanza pointing to 'backend'.. To allow 'frontend' to communicate with 'backend' through Connect, two things are needed: an intention that authorizes the traffic, and an upstream configuration in the 'frontend' service registration so its sidecar knows where to forward requests. Intentions enforce authorization, while the upstream stanza provides the necessary listener and routing information for the sidecar to initiate the mTLS connection.

Answer

Set the 'connect.enabled' parameter to true in the service definition for both services.

Answer

Enable TLS on the Consul agents in both datacenters.

Answer

Manually generate and distribute leaf certificates to both services.

Question 4

A platform team operates two Consul datacenters, dc1 (primary) and dc2 (secondary), with ACLs enabled. They have configured token replication using a replication token in dc2. After rotating the replication token in dc1, they update the configuration in dc2 and restart the Consul agents. However, ACL replication stops working and dc2 logs show 'Permission denied'. What is the most likely cause?

Accepted Answer

The new replication token must be created in the primary datacenter and have read permissions on ACLs, then configured in dc2.. ACL token replication in Consul allows secondary datacenters to mirror ACL data from the primary. The replication token must be created in the primary datacenter with read permissions on ACL resources. After rotating the token, the old token becomes invalid, leading to permission errors in the secondary. Updating the secondary's configuration with a valid token from the primary restores replication.

Answer

The replication token must be configured in both dc1 and dc2 under acl.tokens.replication.

Answer

The replication token must be a management token with acl:write permissions in the primary datacenter.

Answer

The replication token in dc2 must match the token used in dc1's acl.tokens.replication configuration.

Question 5

A team is using the Consul KV store to store application configuration. They want to implement a watch that runs a script whenever the value of the key `config/app` changes. Which two of the following statements are true regarding Consul KV watches? (Choose two.)

Accepted Answer

A watch of type `key` blocks until the value of the specified key changes, then invokes the handler.. Watches in Consul allow monitoring of KV changes. The `key` type watches a single key and blocks until it changes. The `keyprefix` type watches a prefix and triggers on any change within it. These are both standard watch types. Watches can be configured via CLI, API, or agent configuration, and they do not create keys. They are available in all Consul versions.

Answer

Watches are only available in Consul Enterprise and not in the open-source version.

Answer

Watches can only be configured via the Consul HTTP API and not through the CLI or configuration files.

Answer

A watch of type `key` will automatically create the key if it does not exist.

Question 6

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 7

You have a Consul 1.15 cluster with two datacenters, dc1 and dc2, federated via WAN gossip. You want to use a prepared query to automatically failover to a service in dc2 if the service in dc1 becomes unhealthy. Which configuration in the prepared query is required to achieve this?

Accepted Answer

A `Failover` block with `Datacenters` set to `["dc2"]`.. Prepared queries support a `Failover` block that can list datacenters to try when local instances are unhealthy. By setting `Datacenters` to `["dc2"]`, the query will automatically attempt to find healthy instances in dc2 if none are available in the local datacenter. This is the standard method for cross-datacenter failover in Consul. Other options either misuse fields or do not provide the required failover behavior.

Answer

A `Service` block with `Datacenter` set to `dc2`.

Answer

A `Failover` block with `NearestN` set to 3.

Answer

A `Failover` block with `NearestN` set to 2 and `Datacenters` listing dc2.

Question 8

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 9

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 10

A service has a TTL check configured with a 30-second TTL. If the application crashes and stops sending heartbeats, when will the service status change to 'critical'?

Accepted Answer

After 30 seconds. A TTL check in Consul marks the service as critical when the TTL interval elapses without a heartbeat update. Since the TTL is set to 30 seconds, the check will transition to critical exactly 30 seconds after the last successful heartbeat. The application crashing means no further heartbeats are sent, so the timer expires and Consul updates the service status to critical.

Answer

After 60 seconds

Answer

Once the agent restarts

Answer

Immediately

Question 11

You are deploying a Consul Connect service mesh in a single datacenter. A developer asks how service-to-service authorization is enforced when two services communicate through their sidecar proxies. What is the primary mechanism that controls whether the connection is allowed?

Accepted Answer

Consul intentions define whether a connection between a source and destination service is permitted.. Consul intentions are the authorization mechanism in Consul Connect. They evaluate the source service identity against the destination service and determine whether the connection is allowed. While mTLS provides authentication and encryption, it is the intention that enforces authorization. Network ACLs and static proxy configurations do not fulfill this role. Therefore, intentions are the correct answer.

Answer

Network ACLs on the Consul servers filter traffic between sidecar proxies.

Answer

mTLS certificates alone determine if a connection is permitted.

Answer

The Envoy proxy configuration includes a static list of allowed upstream services.

Question 12

An operator writes a feature flag to `app/features/new-ui` using `consul kv put app/features/new-ui true`. Later, a health-check script reads that key and receives an error instead of the value. The operator confirms the key exists with `consul kv get app/features/new-ui`. Which command should the operator run to inspect the metadata that would reveal a problem such as a missing or expired session on the key?

Accepted Answer

consul kv get -detailed app/features/new-ui. Metadata such as the attached session and lock index is only exposed when the detailed view is requested. A key can be readable while still being held by a session, and a health script that attempts to acquire the lock will fail in that case. Requesting the detailed output surfaces the session identifier needed to investigate further.

Answer

consul kv put app/features/new-ui -flags=42

Answer

consul catalog nodes -service=app

Answer

consul kv get -recurse app/features/

Question 13

You need to perform a write operation to the Consul KV store that only succeeds if the current ModifyIndex of the key is zero. Which parameter should you include in your API call?

Accepted Answer

cas=0. The Consul KV write API supports a 'cas' (Check-And-Set) parameter that performs an atomic compare-and-swap against the key's ModifyIndex. Setting cas=0 means the write only succeeds if the key does not currently exist (ModifyIndex is zero), which is the standard way to implement create-if-not-exists semantics.

Answer

acquire=0

Answer

flags=0

Answer

index=0

Question 14

What is the purpose of the 'datacenter' field in the Consul agent configuration?

Accepted Answer

To segment the cluster into logical datacenters.. The 'datacenter' field in the Consul agent configuration assigns the agent to a named logical datacenter, which segments the cluster into independent failure domains. Each datacenter has its own LAN gossip pool, its own Raft consensus group of servers, and its own catalog and KV store. Agents in different datacenters communicate only through the WAN gossip pool and cross-datacenter RPC, not through the LAN pool.

Answer

To limit the number of clients.

Answer

To enable encryption.

Answer

To identify the node for metrics.

Question 15

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 16

Which of the following is a valid method to update a TTL health check?

Accepted Answer

HTTP PUT to the /agent/check/pass endpoint. TTL checks are updated by calling the Consul HTTP API's agent check endpoints — specifically an HTTP PUT to /v1/agent/check/pass/<check_id> (or /warn and /fail) — which resets the TTL timer and marks the check healthy. This is the canonical heartbeat mechanism for TTL checks.

Answer

Using the 'consul kv' update

Answer

Consul CLI 'health' command

Answer

Editing the service definition file

Question 17

You need to retrieve the session information for a specific session ID. Which endpoint should you query?

Accepted Answer

/v1/session/info/:id. The Consul HTTP API exposes session information through the /v1/session/info/:id endpoint, which returns the full session object (ID, node, checks, behavior, TTL, lock-delay) for the specified UUID. This is the documented read endpoint for a single session, distinct from /v1/session/list (all sessions) and /v1/session/node/:node (sessions on a node).

Answer

/v1/session/read/:id

Answer

/v1/kv/session/:id

Answer

/v1/session/get/:id

Question 18

Which status indicates that a health check is successfully passing according to Consul?

Accepted Answer

passing. In Consul, a health check status of 'passing' means the check is succeeding — the service is healthy according to that check. This is the positive status that indicates the check's success condition is met, whether it's an HTTP 200, a script exit code 0, or a TTL being renewed.

Answer

unknown

Answer

critical

Answer

warning

Question 19

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 20

An operator registers a web service with Consul using the HTTP API. The registration includes a TTL health check with a 30-second interval, but the application code does not yet call the pass endpoint. Shortly after registration, the service disappears from healthy DNS results. What is the most likely reason?

Accepted Answer

The TTL check entered the critical state because no pass heartbeat was received before the TTL expired.. TTL checks require the service to actively report health by calling the pass endpoint within the configured TTL. Until that heartbeat arrives, Consul considers the check critical and omits the instance from healthy DNS responses. The described behavior is the expected outcome of a TTL check that was registered but never fed, so the fix is to implement the heartbeat or use an active check type.

Answer

The service was deregistered because Consul automatically removes services after 30 seconds without traffic.

Answer

The DNS interface only returns services registered with a script-based check, so TTL checks are ignored.

Answer

The service was never added to the catalog because the HTTP API requires a separate catalog registration call.