Select Two (Multi-Select) Questions

Consul UI

Why it fails: The Consul UI only displays health check status and lets you browse registered services; it offers no mechanism to declare a check. Health checks are defined in service definitions, the agent configuration files, or via the /agent/check/register HTTP API. The UI is tempting because it visualises checks.

Consul KV store

Why it fails: The KV store holds arbitrary application configuration key-value pairs; Consul never parses it for check definitions, so a check placed there is never registered or executed. Health checks belong in service definitions, agent configuration, or the check registration API. The KV store is tempting as a central place to store configuration.

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

Why it fails: The 'connect' block in a service definition is used to configure sidecar proxy settings, but simply setting 'connect.enabled' is not a valid parameter in Consul 1.15 service definitions. To enable Connect for a service, you include a 'connect' stanza with a sidecar proxy definition. However, the question states both services are already registered with Connect sidecars, so this action is already done and not required.

Enable TLS on the Consul agents in both datacenters.

Why it fails: Enabling TLS on Consul agents secures communication between Consul servers and clients, but it is not required for service-to-service mTLS in Connect. Connect uses its own certificate authority and mTLS for service proxies, independent of agent TLS. While agent TLS is a good security practice, it does not directly enable or authorize the frontend-to-backend connection.

Manually generate and distribute leaf certificates to both services.

Why it fails: Consul Connect automatically manages leaf certificate issuance and rotation through its built-in CA or an external CA. Manual certificate distribution is unnecessary and error-prone. Connect's sidecar proxies obtain certificates via SDS and handle mTLS transparently. Manually managing certificates would bypass Consul's security model and is not a required step.

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

Why it fails: Consul watches are a core feature available in both open-source and Enterprise versions. They are part of the standard Consul agent capabilities. The statement that they are Enterprise-only is incorrect and would mislead users about feature availability.

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

Why it fails: Watches can be configured in multiple ways: via the `consul watch` CLI command, through the HTTP API's `/v1/watch` endpoint (if enabled), or by defining them in agent configuration files under the `watches` stanza. The statement that they can only be configured via HTTP API is false.

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

Why it fails: Watches do not create keys. If the key does not exist, the watch will block until the key is created or the watch is cancelled. The watch is a read-only operation that waits for changes; it does not perform writes. Therefore, it cannot create a key.

The node is immediately deleted from the cluster.

Why it fails: A failed node is marked unhealthy and its services deregistered after the failure timeout, but it remains in the catalog until explicitly removed or it rejoins. It is tempting because Consul does evict dead members from the gossip ring eventually, yet immediate deletion would break the Raft quorum accounting and prevent graceful recovery.

The node is automatically rebooted.

Why it fails: Consul detects failure through Serf gossip and marks the node unhealthy, but it never issues a reboot; that requires an external orchestrator such as systemd or a cloud auto-healing group. It is tempting because Consul agents run as host services, yet their failure handling is limited to membership and health state, not host power control.

The entire cluster shuts down.

Why it fails: A single node failure triggers only local service re-registration and health-check failover; the remaining quorum keeps serving reads and writes, so the cluster continues operating. It is tempting because Consul's gossip and Raft protocols coordinate cluster-wide state, but that coordination preserves availability rather than halting every agent.

Provides advanced traffic shifting.

Why it fails: Consul DNS resolves service names to addresses and ports; traffic shifting requires Consul service mesh features such as service splitters and resolvers configured through intentions and mesh gateways. It is tempting because DNS is part of service discovery, but shifting weight between versions is a mesh routing capability, not a DNS interface benefit.

Encrypts all traffic between services.

Why it fails: Consul DNS returns SRV and A records for service discovery; it does not encrypt traffic, which requires mTLS through the service mesh or TLS termination at proxies. It is tempting because DNS queries can be secured individually, but end-to-end encryption between services is a mesh identity and certificate function, not a DNS interface benefit.

Client browser

Why it fails: Irrelevant.

Consul server uptime

Why it fails: Does not affect local checks.

An explicit tag on the service

Why it fails: Tags are optional metadata used for filtering and routing; they do not influence whether SRV records are generated or what they contain. A service registered with no tags still returns SRV records as long as it has a port and an address. Requiring a tag would be an unnecessary constraint not imposed by Consul's DNS interface.

A health check attached to the service

Why it fails: Health checks affect whether an instance is included in DNS answers, but they are not required for Consul to generate SRV records. A service with no checks is treated as passing and its SRV record is still returned. The absence of a check does not prevent SRV resolution; it only removes the health gating that would otherwise filter instances.

A DNS-friendly service name with no underscores

Why it fails: While underscores are technically valid in DNS labels, Consul's SRV generation does not depend on the service name being free of them. Consul can return SRV records for services whose names contain underscores or other characters, because the name is used as a label rather than as a hostname. Name formatting is not a prerequisite for SRV resolution.

SSH

Why it fails: Consul registers checks for HTTP, TCP, UDP, gRPC, Docker, alias, TTL and script; SSH is not among them, so an SSH check definition is rejected. It tempts because SSH is a standard service to monitor, yet that needs a script check wrapping an SSH client, not a native check type.

FTP

Why it fails: Consul's built-in check types are HTTP, TCP, UDP, gRPC, Docker, alias, TTL and script; FTP is absent, so no FTP check can be registered. It tempts because FTP is a common network service worth monitoring, but that requires a script check invoking an FTP client rather than a native check type.

Secret Key

Why it fails: A secret key is credential material supplied to an application at runtime, not a field of a Consul service definition, which declares name, port, tags, checks and meta. It is tempting because Consul does store secrets for services, and it would be correct when configuring intentions or TLS rather than the service definition itself.

Node BIOS version

Why it fails: BIOS version describes the underlying host hardware and is never declared in a Consul service definition, which covers name, port, tags, checks and metadata. It is tempting because node-level attributes appear in Consul's catalog, and it would be relevant when registering a node rather than defining a service.

It requires manual service registration.

Why it fails: The passing parameter filters results by current health-check status; it does not require services to be registered manually. Tempting because filtering presupposes registered services with checks, and it would be correct when querying services that were registered via configuration or the API, but registration is independent of this parameter.

It forces the DNS server to restart.

Why it fails: The passing parameter filters DNS results to instances whose health checks currently pass; it never restarts the DNS server. Tempting because unhealthy services disappear from results, and it would be correct when querying only healthy endpoints, but restarting is done by restarting the Consul agent or server process.

It is a permanent configuration setting.

Why it fails: The passing parameter applies per DNS query as a query-string argument; it is not stored configuration. Tempting because it changes returned records, and it would be correct when permanently excluding unhealthy instances, but that is achieved through health-check definitions, not this query parameter.

Increased application latency.

Why it fails: Consul Connect adds sidecar proxies and mTLS handshakes, which increase latency rather than reduce it; it is a cost, not a benefit. It is tempting because latency overhead is a real consideration, so it is the correct answer when asked to identify drawbacks of service mesh adoption.

Elimination of firewalls.

Why it fails: Consul Connect enforces intentions and mTLS between services; it does not remove firewalls, which still filter external and host traffic. It is tempting because intentions centralise service-to-service authorisation, so it is the correct choice when the question asks about replacing manual firewall rules between services.

Automatic database replication.

Why it fails: Consul Connect handles service identity, authorisation and traffic encryption; database replication is outside its scope. It is tempting because Consul does provide service discovery and health checking, so it is the correct answer when asked which capability Consul offers for locating healthy service instances.

Session TTL renewal must be performed through the `/v1/kv` endpoint rather than the session endpoint.

Why it fails: Session TTLs are renewed via the session endpoint at `/v1/session/renew/<id>`, not through `/v1/kv`. The KV endpoint handles key reads and writes, including lock acquire and release, but it does not manage session lifetimes. Renewing through the wrong endpoint would fail, so this statement misstates where session upkeep occurs.

A lock key can be held simultaneously by multiple sessions as long as each session renews within its TTL.

Why it fails: Consul enforces mutual exclusion: a single lock key can be associated with only one valid session at a time. Multiple sessions cannot concurrently hold the same key, regardless of renewal. This exclusivity is the whole point of the lock, so allowing several holders would break the coordination guarantee the engineer depends on.

Releasing a lock requires calling a dedicated `consul kv unlock` subcommand that is separate from the put operation.

Why it fails: There is no `consul kv unlock` subcommand. Locks are released by writing to the key with the `release` operation and the holding session ID, or implicitly when the session ends. Inventing a separate unlock command misrepresents the API, which folds release into the same key-write path rather than a standalone tool.

It is strictly read-only.

Why it fails: It is modified via registration.

It is only accessible via the CLI.

Why it fails: It is accessible via API and DNS.

It is stored in the local disk of every agent.

Why it fails: It is stored in the server's Raft log.

Directly modifying the Consul database file.

Why it fails: Consul's database file is an internal on-disk artefact, not a supported registration mechanism; modifying it directly risks corruption and is ignored by the running agent. It is tempting because the file stores service records, so it looks like a shortcut — but registration must go through the API, agent config, or service sync.

Manual editing of the Raft log.

Why it fails: The Raft log is Consul's internal replicated state store, not a registration interface; editing it directly corrupts cluster consistency and bypasses the catalogue API. It is tempting because the Raft log does hold service data, so it appears authoritative — but valid registration uses the HTTP API, config files, or service sync.

SessionTTL

Why it fails: SessionTTL appears in session API responses, not KV GET responses, which return Key, Value, Flags, CreateIndex, ModifyIndex, LockIndex and Session. It is tempting because KV pairs can be session-bound, so the field name feels related, but the KV endpoint never emits it.

CreateTime

Why it fails: KV GET responses expose CreateIndex and ModifyIndex, not a CreateTime field; Consul records index positions rather than timestamps. It is tempting because other Consul endpoints do return time-based fields, so a creation timestamp seems reasonable, but the KV payload simply does not include one.

To release leadership, the leader can simply delete the KV key, which automatically invalidates its session and allows another instance to acquire the lock.

Why it fails: Deleting the KV key does not invalidate the session. The session remains active until it expires or is explicitly destroyed. Other instances could then acquire the key, but the old session might still hold a lock on a recreated key. Proper release requires destroying the session or releasing the lock.

All instances should use the same session ID to ensure they can all attempt to acquire the lock simultaneously, and the first one to call acquire becomes the leader.

Why it fails: Sessions are tied to a single node and should not be shared across instances. Using the same session ID would cause all instances to appear as the same entity, breaking health check association and causing unpredictable lock behavior. Each instance must have its own session.

The KV key used for leader election must have a TTL set via the ?ttl= query parameter, so that it expires automatically if the leader fails.

Why it fails: Consul KV does not support a TTL parameter on keys. Automatic expiration is achieved through session invalidation, not key TTLs. There is no ?ttl= query parameter for KV writes. The lock is released only when the session is invalidated.

The app must be written in Go.

Why it fails: Native integration requires no specific language; any app can join the mesh via sidecar proxies or SDKs, so Go is not a prerequisite. It is tempting because Go is the language Consul itself is written in, and Go SDKs offer the richest native support, but that is a tooling preference, not a Connect requirement.

The sidecar proxy is still required for routing.

Why it fails: Native integration removes the sidecar requirement entirely, embedding mTLS directly in the application so traffic bypasses any proxy. It is tempting because sidecars remain the standard mechanism for non-native services, where they handle mutual TLS and authorisation without code changes.

It supports only non-secure traffic.

Why it fails: Native integration secures traffic with automatic mutual TLS between services, so it never restricts itself to plaintext. It is tempting because unsecured communication is the default for services lacking Connect integration, which is precisely the gap native integration exists to close.

tls_skip_verify

Why it fails: tls_skip_verify disables TLS certificate verification for the check. It is unrelated to adding custom headers or extending the timeout for a slow endpoint. While it is a valid HTTP check field, it does not fulfill the two specific goals in the scenario, so it is not one of the correct selections.

interval

Why it fails: The interval field controls how frequently the check runs, not how long it waits for a response. Adjusting the interval changes the frequency of probes but does not make the check tolerate a slow endpoint. It also does not add headers, so it does not meet either requirement described.

method

Why it fails: The method field specifies the HTTP verb used for the check, such as GET or POST. While it can be useful, it does not add custom headers or extend the time allowed for a response. The scenario asks for headers and slow-endpoint tolerance, so method is not one of the two required fields.

They only support GET requests

Why it fails: Consul health checks support HTTP, TCP, gRPC, Docker, TTL and script types, so restricting them to GET requests misstates the mechanism. The GET assumption tempts because HTTP checks commonly use GET, but that is one check type among several, not a protocol-wide constraint.

They always run on the server

Why it fails: Health checks execute on the Consul client agent where the service is registered, not the server; servers only aggregate and evaluate results. Running checks server-side is tempting because servers hold the catalogue, but that model applies to centralised monitoring tools, not Consul's distributed agent architecture.

They cannot be disabled

Why it fails: Consul health checks can be disabled, for example by deregistering the check or setting it to a non-critical state, so the claim is false. It tempts because checks normally run continuously and appear mandatory, but operators legitimately disable them during maintenance windows or troubleshooting.

The number of other services registered on the same agent

Why it fails: The count of co-located services has no bearing on any individual service's health. Consul evaluates each service against its own checks and the node checks, not against how many siblings share the agent. A busy agent hosting many services does not degrade their reported health.

The Consul version running on the server that handles the catalog write

Why it fails: Server version affects available features and upgrade compatibility, but it is not an input to health evaluation. The catalog computes health from check statuses regardless of which server processes the registration. Upgrading servers does not change a service's reported health unless check definitions or results change.

The datacenter in which the service is registered

Why it fails: Datacenter membership affects query routing and where the service appears, but it does not influence the computed health status. A service in any datacenter is judged by its own checks and its node's checks. Two identical services in different datacenters will report the same health if their checks behave the same way.