Consul 1.15 Practice Test 5 — 10 Questions

Question 1

If a Consul agent is configured with 'disable_remote_exec = true', how does this affect the KV store?

Accepted Answer

It has no effect on the KV store.. 'disable_remote_exec' controls whether Consul's remote execution feature (the 'consul exec' command) is allowed on the agent. It has no relationship to the KV store — KV reads, writes, watches, and consistency modes are governed by separate ACL and query parameters. Setting this flag simply blocks remote command execution for security hardening.

Answer

It forces all KV reads to be consistent.

Answer

It prevents all KV writes.

Answer

It disables KV watches.

Question 2

Which of the following best describes the 'consul agent -dev' mode in relation to service discovery?

Accepted Answer

It provides a single-node Consul environment for testing.. The 'consul agent -dev' flag starts a single-node Consul agent configured as a server and client in one process, with an in-memory datastore, no persistence, and no cluster join. It is explicitly designed for local development, testing, and demos — not for production — and it still exposes the DNS interface, HTTP API, and service catalog so you can exercise service discovery locally.

Answer

It disables DNS interfaces.

Answer

It forces the service catalog to be stored in Redis.

Answer

It is suitable for production clusters.

Question 3

You notice that the KV store is not consistent across datacenters. What is the cause?

Accepted Answer

KV store is datacenter-local by design.. Consul's KV store is datacenter-local by design — each datacenter maintains its own independent KV namespace with no automatic replication to peer datacenters. When you write a key in dc1, it does not appear in dc2 unless you explicitly write it there or use a tool like consul-replicate. This is expected behaviour, not a fault.

Answer

The Raft protocol is broken.

Answer

The ACL token lacks the 'write' permission.

Answer

The WAN gossip is disabled.

Question 4

Which command line tool can you use to manually trigger a TTL check update for a specific service?

Accepted Answer

curl -X PUT http://localhost:8500/v1/agent/check/pass/checkID. The Consul HTTP API exposes agent check endpoints that allow external systems to push health status updates. A TTL check registered with the local agent can be manually marked passing by sending an HTTP PUT to /v1/agent/check/pass/<checkID> on port 8500. This is the documented mechanism for scripts and external monitors to report liveness without waiting for the TTL to expire.

Answer

consul kv put

Answer

consul agent -check-update

Answer

consul health update

Question 5

Which TWO of the following statements are true about the 'passing' parameter in DNS queries?

Accepted Answer

It returns only services with passing health checks.. Option B is correct because the 'passing' parameter filters DNS query results so that only service instances whose health checks are currently passing are returned, which is essential for service discovery in tools like Consul. Option E is correct because 'passing' is appended as a query string parameter in the DNS query URL, for example when querying a service name with ?passing to restrict results to healthy instances. Option A is incorrect because the 'passing' parameter does not require manual service registration; services are registered through the service registry or API, not through this query parameter. Option C is incorrect because 'passing' is a query-time filter and has no effect on restarting the DNS server. Option D is incorrect because 'passing' is a per-query parameter, not a permanent configuration setting.

Answer

It requires manual service registration.

Answer

It forces the DNS server to restart.

Answer

It is a permanent configuration setting.

Question 6

Which Consul API endpoint is used to create a new session that can be used for locking KV keys?

Accepted Answer

/v1/session/create. The correct endpoint is /v1/session/create because it is specifically designed to create a new session in Consul. Sessions are the foundation for distributed locks and KV key acquisition. When you create a session, Consul returns a session ID that can be used with the KV acquire endpoint to obtain a lock on a key. This endpoint accepts parameters like name, TTL, and behavior on invalidation, allowing fine-grained control over lock semantics.

Answer

/v1/kv/acquire

Answer

/v1/lock/init

Answer

/v1/session/renew

Question 7

When using multiple datacenters, what is the primary role of the 'consul-template' tool?

Accepted Answer

To generate configuration files based on Consul data.. consul-template is a daemon that watches Consul for changes (KV pairs, services, health checks) and renders configuration files from templates, optionally running commands when files change. Its primary role is dynamic configuration generation based on Consul data, commonly used to configure HAProxy, Nginx, or Vault. It does not provision infrastructure or manage the cluster.

Answer

To provision infrastructure.

Answer

To replicate KV stores.

Answer

To manage the Consul cluster nodes.

Question 8

You need to deny all traffic between 'service-a' and 'service-b' using intentions. What is the most efficient way to achieve this?

Accepted Answer

consul intention create -deny service-a service-b. Intentions can be set to 'deny' explicitly, which overrides any 'allow' rules.

Answer

consul intention create -allow-none service-a service-b

Answer

consul intention set -action=drop service-a service-b

Answer

consul intention delete service-a service-b

Question 9

Which protocol do Consul servers use to maintain the WAN gossip pool?

Accepted Answer

Serf (SWIM). Consul servers use the Serf library, which implements the SWIM gossip protocol, to maintain the WAN gossip pool across datacenters. Serf handles membership, failure detection, and lightweight message dissemination over UDP/TCP. This is distinct from Raft, which handles consensus for the replicated state.

Answer

gRPC

Answer

DNS

Answer

HTTP

Question 10

What is the recommended number of Consul servers per datacenter to ensure high availability?

Accepted Answer

3. The recommended number of Consul servers per datacenter for high availability is three, because it allows the cluster to tolerate the failure of one server while maintaining quorum. Consul uses the Raft consensus algorithm, which requires a majority of servers to be available for writes. With three servers, a single failure leaves two servers, still a majority, so the cluster remains operational.

Answer

2

Answer

1

Answer

10