Consul 1.15 Practice Test 15 — 15 Questions

Question 1

How are intentions applied to services in different partitions or namespaces?

Accepted Answer

You must specify the namespace in the intention definition.. In Consul Enterprise, intentions are applied to services in different partitions or namespaces by specifying the namespace (and partition, if applicable) in the intention definition. This allows fine-grained control over which services can communicate across these boundaries. Intentions are not limited to the default namespace, nor are they always global.

Answer

Intentions only work within the 'default' namespace.

Answer

Intentions are always global.

Answer

They must be created via API only.

Question 2

You need to ensure that a read operation from the KV store is strongly consistent. Which consistency mode should you specify?

Accepted Answer

consistent. The 'consistent' mode forces the Consul server handling the request to forward it to the leader, which then verifies it still holds leadership via a quorum of followers before serving the read. This guarantees linearizable (strongly consistent) reads, ensuring you never see stale data. In contrast, 'default' and 'stale' allow reads from any server and may return outdated values, while 'quorum' is not a valid consistency mode for KV reads.

Answer

default

Answer

quorum

Answer

stale

Question 3

You have implemented a leader election mechanism using Consul KV sessions. The session has a TTL of 15 seconds. If the application crashes, how long will it take for the lock to be automatically released?

Accepted Answer

15 seconds.. Consul sessions are invalidated when their TTL expires without a renewal. With a 15-second TTL, if the application crashes and stops calling session renew, the session becomes invalid after 15 seconds, and any locks or KV entries tied to that session are released at that point. The lock release is therefore bounded by the session TTL, not by any manual intervention.

Answer

Immediately.

Answer

60 seconds.

Answer

The lock is never released until manually deleted.

Question 4

Which HTTP status code range does Consul interpret as a passing state for an HTTP health check?

Accepted Answer

2xx. Consul's HTTP health check considers the check passing only when the endpoint returns an HTTP status code in the 2xx range (200-299). Any other status — including 3xx redirects — is treated as critical/failing. This strict interpretation ensures the monitored service is actually serving content, not redirecting or erroring.

Answer

3xx

Answer

Any code less than 500

Answer

1xx

Question 5

When joining a new datacenter to an existing WAN pool, what is the best practice for server versions?

Accepted Answer

Versions should be consistent across all datacenters.. Consul best practice is to keep server versions consistent across all datacenters in a WAN pool. Version skew can cause protocol incompatibilities, inconsistent behavior, and upgrade complications, so the official guidance is to run the same version everywhere. This is why option C is correct.

Answer

The new DC must run a newer version.

Answer

The new DC must run an older version.

Answer

Version doesn't matter at all.

Question 6

Which TWO of the following are true about Consul datacenters?

Accepted Answer

Each datacenter must have at least one server node.. Option A is correct because every Consul datacenter requires at least one server node to form the Raft quorum and maintain the catalog, since servers are the only agents that participate in the consensus protocol and store cluster state. Option C is correct because a Consul datacenter is defined as a group of nodes that are expected to have low-latency, high-bandwidth connectivity to each other, which is why datacenters are typically mapped to a single network region or availability zone. Option B is incorrect because a datacenter in Consul is a logical grouping, not strictly a physical location, and can span or subdivide physical sites. Option D is incorrect because each datacenter maintains its own independent Raft quorum; servers in different datacenters do not share a single quorum. Option E is incorrect because a single Consul agent belongs to exactly one datacenter and cannot join multiple datacenters simultaneously.

Answer

They are strictly physical locations.

Answer

They must share the same Raft quorum.

Answer

They allow a single Consul agent to join multiple DCs.

Question 7

Which THREE of the following represent potential bottlenecks for Consul KV performance?

Accepted Answer

Very large number of keys. Option A is correct because Consul's KV store keeps all keys in memory and replicates them via Raft, so a very large number of keys increases memory pressure, snapshot size, and Raft log/replication overhead, degrading performance. Option B is correct because every KV write must be committed through the Raft consensus protocol and replicated to a quorum of servers, so very high write throughput becomes a bottleneck as the leader serializes and replicates each write. Option D is correct because very large value sizes inflate Raft log entries, snapshot transfers, and network replication traffic, and Consul enforces a maximum KV value size (512 KB) precisely because oversized values harm performance. Option C is not a primary bottleneck because reads can be served by any server (including non-leaders) and stale reads can be served locally, so high read frequency scales better than writes. Option E is not a bottleneck because HTTP is the standard Consul KV API transport and the RPC layer is used internally; the protocol choice itself is not a performance-limiting factor compared to key count, write volume, and value size.

Answer

High read frequency

Answer

Using HTTP instead of RPC

Question 8

Which TWO of the following are common use cases for the Consul KV store?

Accepted Answer

Distributed locking. Option B (Distributed locking) is correct because Consul KV supports acquiring and releasing locks via sessions, using the KV store's compare-and-swap semantics combined with session invalidation to implement distributed locking and leader election. Option E (Distributed configuration management) is correct because Consul KV is commonly used to store application configuration key/value pairs that services read at runtime, with Consul's blocking queries and watches enabling dynamic config updates. Option A (Traffic routing) is not a KV use case; traffic routing is handled by Consul service mesh features such as intentions, service resolvers, and Envoy sidecar proxies. Option C (Service discovery) is provided by Consul's catalog and DNS/HTTP service registration APIs, not the KV store. Option D (Running custom scripts) is not a Consul KV function; Consul executes scripts only via health checks or watches that trigger external handlers, not as a KV capability.

Answer

Traffic routing

Answer

Service discovery

Answer

Running custom scripts

Question 9

Which TWO of the following are true regarding Consul KV watches?

Accepted Answer

Watches use blocking queries internally. Option B is correct because Consul watches are implemented on top of blocking queries: the watch issues a request with an index and the Consul server holds the connection open until the data changes or the wait time expires, then returns a new index. Option D is correct because watches can be declared in the agent's configuration files (a `watches` block in HCL/JSON) so the agent starts them automatically, in addition to being startable via the `consul watch` CLI command. Option A is wrong because a watch can target a key that does not yet exist and will fire when it is created. Option C is wrong because Consul does not automatically restart a watch handler script that fails; the handler is simply invoked on each change. Option E is wrong because watches are available in the open-source edition, not only Consul Enterprise.

Answer

Watches can only monitor keys that exist

Answer

Watches automatically restart after a script failure

Answer

Watches are only available in the Enterprise edition

Question 10

Which TWO of the following accurately describe Consul's WAN gossip protocol behavior?

Accepted Answer

It involves only the server nodes of each datacenter.. Option A is correct because Consul's WAN gossip pool is formed exclusively by the server nodes from each datacenter, which federate across datacenters; client agents do not participate in the WAN gossip. Option C is correct because the WAN gossip protocol is specifically tuned for higher latency and lower bandwidth conditions typical of cross-datacenter links, unlike the LAN gossip pool that assumes low-latency local networks. Option B is not correct because Consul's WAN gossip uses a full-mesh among servers rather than a central hub-and-spoke topology. Option D is not correct because client nodes only join the LAN gossip pool within their own datacenter, not the WAN pool. Option E is not correct because service discovery relies on the catalog and DNS/HTTP interfaces, not on the WAN gossip protocol being mandatory.

Answer

It relies on a central hub-and-spoke architecture.

Answer

It includes all client nodes in the gossip pool.

Answer

It is mandatory for service discovery.

Question 11

Which TWO of the following are true about the 'cas' parameter in KV writes?

Accepted Answer

It stands for Check-And-Set. Option C is correct because 'cas' stands for Check-And-Set, the Consul KV write flag that makes a write conditional on the key's current ModifyIndex. Option E is correct because using cas requires supplying a valid ModifyIndex value: the write succeeds only if it matches the key's current index, otherwise Consul returns an error (e.g., HTTP 409). The other options are wrong: cas is available through the HTTP API and UI as well as the CLI, it works for existing keys (not only new ones), and it is optional rather than mandatory for all writes.

Answer

It is only available in the CLI

Answer

It only works for new keys

Answer

It is mandatory for all writes

Question 12

Which TWO of the following are valid ways to configure Consul Connect?

Accepted Answer

JSON service definition files.. Option D (JSON service definition files) is correct because Consul Connect is configured by declaring a service with a `connect` block (e.g., `"connect": {"sidecar_service": {}}`) inside a service registration JSON file, which the agent reads to enable the sidecar proxy and intentions. Option E (Consul HTTP API) is correct because the same service registration, including the `connect` stanza, can be submitted programmatically via the `/v1/agent/service/register` endpoint, and intentions can be managed through the `/v1/connect/intentions` endpoints. Options A, B, and C are not valid configuration methods: modifying the Envoy binary, the Consul source code, or the agent binary are unsupported hacks that alter the software itself rather than configuring Connect through its documented interfaces, and they would break upgrades and support.

Answer

Directly modifying the Envoy binary.

Answer

Modifying the Consul source code.

Answer

Editing the agent binary.

Question 13

Which THREE of the following are valid ways to categorize services in Consul?

Accepted Answer

Metadata (meta). Consul supports categorizing services by metadata (meta), which are arbitrary key/value pairs attached to a service registration and can be used to filter services via the catalog API (e.g., ?filter=ServiceMeta.Key==value). Namespaces are a Consul Enterprise feature that logically partitions services and other resources within a single datacenter, so services are effectively categorized by namespace. Tags are string labels attached to a service (and optionally to individual checks) that can be used to filter and query services, such as with the /v1/catalog/service/:name?tag=... endpoint. IP subnets (A) are not a Consul service categorization mechanism; Consul does not group services by subnet. Port ranges (E) are likewise not a categorization feature, since a service's port is just a registration attribute and Consul provides no grouping or filtering by port range.

Answer

IP subnets

Answer

Port ranges

Question 14

A platform team runs a service on a VM and wants Consul to automatically remove the service instance from the catalog if its health check remains critical for more than 10 minutes. The service is registered via the agent's configuration directory. Which check definition field accomplishes this?

Accepted Answer

deregister_critical_service_after. Consul provides deregister_critical_service_after specifically to remove a service from the catalog after it has been critical for a configured duration. This prevents stale service instances from remaining discoverable. The other options are either invalid field names or serve unrelated purposes such as TTL check timing.

Answer

ttl

Answer

critical_timeout

Answer

deregister_after

Question 15

A Consul operator is troubleshooting a service that intermittently disappears from the catalog. The service is registered with a TTL health check that is updated every 30 seconds by a script. The operator notices that the service is marked as critical and then deregistered. Which configuration change should the operator make to prevent the service from being deregistered?

Accepted Answer

Increase the `deregister_critical_service_after` value in the agent configuration. The `deregister_critical_service_after` setting defines the duration a service can remain critical before automatic deregistration. Increasing this value allows more time for the service to recover from transient failures. The other options either mask the problem or remove health monitoring, which is not advisable.

Answer

Set the `status` field of the service to `passing` in the service definition

Answer

Disable the health check by removing the `check` block from the service definition

Answer

Change the health check to a script check that runs every 30 seconds