Consul 1.15 Practice Test 2 — 10 Questions

Question 1

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?

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

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 2

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 3

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 4

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 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 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 7

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 8

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 9

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 10

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.