Consul 1.15 Key Value Store — 15 Questions

Question 1

An application is using Consul KV to store configuration. You notice that the KV store is becoming large. What is the most efficient way to retrieve only the keys under the prefix "service/web/"?

Accepted Answer

Use the recurse=true parameter in the query string.. The Consul KV HTTP API supports a `recurse` query parameter that, when set to `true`, returns all key-value pairs under a given prefix. Using `GET /v1/kv/service/web/?recurse=true` retrieves every key beneath `service/web/` in a single request, which is the most efficient way to fetch a full subtree. Without `recurse`, the API only returns the exact key if it exists, so this parameter is essential for prefix-based bulk retrieval.

Answer

Set the depth parameter to 1.

Answer

Use the index parameter with value 0.

Answer

Use the keys parameter with the prefix.

Question 2

Which flag can be used to pass arbitrary metadata to a KV entry?

Accepted Answer

flags. The 'flags' parameter in Consul KV can be used to pass arbitrary metadata to a KV entry. It is a numeric value that can be set when writing a key, and it is returned when reading the key. This allows storing small amounts of metadata without affecting the key's value.

Answer

labels

Answer

metadata

Answer

tags

Question 3

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 4

Which Consul agent configuration parameter defines the KV store file location when running locally?

Accepted Answer

data_dir. The data_dir parameter in the Consul agent configuration specifies the directory where the agent stores its state, including the KV store when running in server mode. This is the correct parameter for defining KV store file location.

Answer

server_dir

Answer

kv_dir

Answer

state_dir

Question 5

Which TWO of the following are valid ways to interact with the Consul KV store?

Accepted Answer

Consul HTTP API. The HTTP API and the CLI are the two primary supported interfaces for KV interactions.

Answer

Direct file system access to KV data

Answer

SQL queries

Answer

Consul GUI (Web UI)

Question 6

Which THREE of the following are required to successfully acquire a lock on a KV key?

Accepted Answer

A valid session ID. To acquire a lock on a KV key in Consul, the request must include a valid session ID (option A), because locks are tied to sessions and the lock is released when the session is invalidated or expires. The 'acquire' parameter (option C) must be supplied in the API request (e.g., PUT /v1/kv/:key?acquire=<session>) to tell Consul to attempt to acquire the lock rather than perform a normal write. The key name to lock (option E) is required because the lock is associated with a specific KV path, and the API call must target that key. Option B is not required because acquiring a lock uses a write operation governed by the ACL policy on the key, but the question asks for the lock-specific requirements rather than a generic 'write' policy name. Option D is not required because 'wait' is used for blocking queries to wait for index changes, not for acquiring a lock.

Answer

A 'write' ACL policy

Answer

A 'wait' parameter

Question 7

You need to ensure that a value written to the KV store is persisted to disk on a majority of Consul servers before returning. Which parameter affects this?

Accepted Answer

Writes are committed by default via Raft.. Consul's raft protocol handles consistency; writes are only acknowledged after a quorum of servers commits the change to their log. No special parameter is needed as this is default behavior for writes. However, among the choices, understanding that KV writes are Raft-based operations is key.

Answer

sync=true

Answer

consistency=strong

Answer

wait=majority

Question 8

What happens if you try to write to a key that is currently locked by a session you do not own?

Accepted Answer

The write is rejected.. In Consul's key-value store, a lock is acquired by creating a session and using the acquire operation. If another session holds the lock, any write attempt to that key by a different session is rejected with a 500 error (or similar) to prevent accidental overwrites. This ensures that only the lock owner can modify the key.

Answer

The write overwrites the lock.

Answer

The lock is transferred.

Answer

The write is queued.

Question 9

Which TWO of the following are true regarding the behavior of the Consul KV store?

Accepted Answer

Stale reads allow for reading from non-leader nodes. Option D is correct because Consul's KV store supports a stale read consistency mode, which permits a read to be served by any Consul server (including non-leaders) rather than requiring the leader, trading freshness for lower latency and higher availability. Option E is correct because the Consul HTTP KV API returns values as base64-encoded strings in the JSON response (the "Value" field), so clients must decode them to obtain the original bytes. Option A is not correct because Consul KV keys may contain a wide range of characters (including slashes, dashes, and dots) and are not restricted to alphanumeric characters only. Option B is not correct because Consul KV writes are not synchronous across all nodes; writes are committed via the Raft consensus protocol on the server cluster and then replicated, and reads can be served with different consistency modes. Option C is not correct because the Consul KV store is not limited to 1GB of data; it is bounded by the overall Raft/state store limits and practical resource constraints, not a fixed 1GB cap.

Answer

Keys can only contain alphanumeric characters

Answer

All KV writes are synchronous across all nodes

Answer

The KV store is limited to 1GB of data

Question 10

Which THREE of the following are valid session behaviors when a session is invalidated?

Accepted Answer

keep. In session-management semantics, when a session is invalidated the valid behaviors are keep, delete, and release. Option B (keep) is correct because invalidation can mark the session as no longer valid while retaining the session record for audit, logging, or later reference rather than destroying it immediately. Option C (delete) is correct because the session object and its associated data can be removed entirely from the session store upon invalidation. Option E (release) is correct because invalidation can release the session's resources, locks, or references back to the pool while the session itself is retired from active use. Options A (transfer) and D (terminate) are not standard session-invalidation behaviors: transfer implies moving session ownership or state to another context, and terminate implies forcibly ending a connection or process, neither of which describes invalidating a session's validity state.

Answer

transfer

Answer

terminate

Question 11

Which TWO of the following are valid ways to trigger a KV watch?

Accepted Answer

Updating the key's value. In Consul's KV store, a blocking watch on a key is triggered whenever the key's index changes, which happens on a write to that key. Option B (Updating the key's value) is correct because modifying the value performs a KV write that increments the modify index, causing watchers to fire. Option D (Updating the key's flags) is also correct because flags are part of the KV pair's metadata and changing them constitutes a write that bumps the index, triggering the watch. Option A (Reading the key) does not belong because a read does not alter the key's index and therefore does not trigger a watch. Option C (Creating a new session) does not belong because sessions are separate from KV entries and creating one does not modify any key's index. Option E (Changing the key's TTL) does not belong because Consul KV pairs do not have a per-key TTL attribute that can be changed to trigger a watch.

Answer

Reading the key

Answer

Creating a new session

Answer

Changing the key's TTL

Question 12

Which THREE of the following are standard Consul KV CLI subcommands?

Accepted Answer

put. The Consul KV CLI exposes a small set of subcommands under `consul kv`, and the three standard ones among the options are put, delete, and get. Option C (`put`) is correct because `consul kv put ` writes or overwrites a key's value in the KV store, optionally with flags like `-flags` or `-cas`. Option D (`delete`) is correct because `consul kv delete ` removes a key (or a key prefix with `-recurse`) from the KV store. Option E (`get`) is correct because `consul kv get ` reads the value and metadata for a key, with options such as `-detailed` and `-recurse`. Option A (`describe`) is not a Consul KV subcommand — it is not part of the `consul kv` command family (descriptive output is obtained via `get -detailed`). Option B (`list`) is not a Consul KV subcommand either; listing keys is done with `consul kv get -recurse` or `consul kv export`, not a `list` verb.

Answer

describe

Answer

list

Question 13

You need to store a small JSON configuration blob in Consul KV and later retrieve it exactly as written. Which Consul CLI command should you use to write the value from a file named config.json to the key app/config?

Accepted Answer

consul kv put app/config @config.json. The consul kv put command accepts a key and a value. To read the value from a file, prefix the filename with @. This is the documented method for file input. Other options either use unsupported flags, non-existent subcommands, or assume stdin reading that is not implemented.

Answer

consul kv put app/config --file=config.json

Answer

consul kv import app/config config.json

Answer

consul kv put app/config < config.json

Question 14

You are using Consul KV to store feature flags. A service instance reads a flag using a blocking query with a wait time of 5 minutes. After 3 minutes, the flag is updated. The service instance expects to receive the new value immediately. However, it does not receive an update until the full 5 minutes elapse. What is the most likely reason for this behavior?

Accepted Answer

The service instance did not set the 'index' parameter correctly in the blocking query.. Blocking queries in Consul rely on the 'index' parameter to detect changes. The client must pass the ModifyIndex from the previous response. If the index is omitted or incorrect, Consul cannot block on the specific key's changes and may wait until the timeout. Thus, the service instance likely failed to set the index correctly, causing the delayed update.

Answer

The service instance is using the 'stale' consistency mode, which does not return updates until the wait time expires.

Answer

The service instance is querying a Consul server that is not the leader, and the leader did not propagate the update.

Answer

The KV store is configured with a default ACL policy that denies read access, causing the query to hang.

Question 15

You are using the Consul KV store to store feature flags. You want to ensure that a read request returns the most up-to-date value, even if it means increased latency. Which consistency mode should you use for the KV read operation?

Accepted Answer

consistent. The 'consistent' mode ensures that reads are served by the leader, providing the most up-to-date value. It is the strongest consistency mode available for KV reads in Consul. The 'default' and 'stale' modes may return stale data, and 'linearizable' is not a recognized mode.

Answer

stale

Answer

default

Answer

linearizable