Service Discovery practice questions

consul kv get

Why it fails: KV store is separate from the service catalog.

consul reload

Why it fails: This command triggers a configuration reload.

consul members

Why it fails: This shows cluster membership, not service state.

TCP health check.

Why it fails: TCP checks require an exposed port.

HTTP health check.

Why it fails: HTTP checks require an HTTP server.

gRPC health check.

Why it fails: gRPC checks require a gRPC server.

/var/lib/consul/

Why it fails: /var/lib/consul stores the agent's persistent state, including the Raft data directory and serf snapshots, not service definitions. Consul does not parse JSON files placed there. This location would be correct when relocating the data directory via the data_dir setting, not for registering services.

/etc/consul/

Why it fails: Consul loads service definition files only from the agent's configured config-dir, typically /etc/consul.d, not /etc/consul itself. Files placed there are ignored unless the -config-dir flag points at that path. /etc/consul suits agent configuration files such as consul.hcl, not auto-loaded service registrations.

/usr/local/bin/

Why it fails: /usr/local/bin holds executable binaries, and Consul never scans it for service definitions; only the agent's config-dir is read at startup and reload. A JSON service file there is simply ignored. This path would be correct for installing the consul binary itself, not for registration.

Set 'port' to 'auto' in the service definition.

Why it fails: 'auto' is not a valid value for the port field.

Omit the 'port' field entirely.

Why it fails: The port field is mandatory in service definitions.

Use the 'address' field for the port.

Why it fails: The address field is for IP/hostname, not ports.

Enable 'only_passing' in the DNS configuration.

Why it fails: This setting does not exist in Consul DNS configuration.

Disable the agent's 'allow_stale' read setting.

Why it fails: Allow_stale affects consistency, not health check filtering.

Set 'deregister_critical_service_after' to 0.

Why it fails: This setting controls service cleanup, not DNS visibility.

Use a tag named 'maintenance'.

Why it fails: Tags do not affect check logic.

Set 'maintenance_mode' to true in the service definition.

Why it fails: This is not a valid field in the service definition.

Set the 'status' to 'maintenance' in the API.

Why it fails: This field does not exist.

It only queries the leader of the entire WAN.

Why it fails: Queries are handled by local agents.

It automatically replicates all services to all datacenters.

Why it fails: Service catalog is not replicated by default to all datacenters.

It always returns instances from all datacenters.

Why it fails: Consul defaults to the local datacenter unless specified.

Use a 'pre-stop' script.

Why it fails: This is not a Consul native feature.

Enable 'auto_cleanup' in the agent config.

Why it fails: This is not a real configuration flag.

Set 'ttl' to 0.

Why it fails: TTL is for health checks.

By automatically creating new services.

Why it fails: They do not create services.

By disabling health checks.

Why it fails: They support health checks.

By caching all DNS records in memory.

Why it fails: Caching is not the main purpose of prepared queries.

Use the '!' character before the tag name.

Why it fails: This syntax is not supported in DNS.

Add a 'not' parameter to the query.

Why it fails: 'not' is not a valid parameter.

Use regex in the service name.

Why it fails: Service names do not support regex.

YAML

Why it fails: YAML is not natively supported by Consul configuration loaders.

TOML

Why it fails: TOML is not supported.

XML

Why it fails: XML is not supported.

consul show

Why it fails: This command does not exist.

consul agent services

Why it fails: This command does not exist.

consul services list

Why it fails: This command does not exist.

IP Address

Why it fails: IP is a result, not a filter.

Metadata

Why it fails: Metadata is not a standard DNS filter.

Node Name

Why it fails: DNS discovery is usually service-based.

kernel_version

Why it fails: Usually not service metadata.

password

Why it fails: Security risk.

A database-specific configuration.

Why it fails: Not database specific.

A static, immutable file.

Why it fails: They can be reloaded.

A binary file loaded into the server.

Why it fails: Not binary.

maintenance

Why it fails: Maintenance is a state of the node, not a check status.

unknown

Why it fails: Not a valid check status.

Configure the service with `"weights"` to prioritize healthy instances.

Why it fails: Weights are used in Consul's DNS SRV records and service resolver configurations to influence traffic distribution, not to exclude unhealthy instances. Even with weights, an unhealthy instance may still appear in DNS results unless health-based filtering is applied. This option does not guarantee that only healthy instances are returned, so it is incorrect for this requirement.

Enable the `enable_tag_override` option in the service definition.

Why it fails: The `enable_tag_override` option allows external agents to modify tags via the catalog API, which is unrelated to health-based filtering. It does not affect whether unhealthy instances are returned in DNS or catalog queries. Enabling it would not prevent `redis-cache` from being discovered when its health check is failing, so it fails to solve the stated problem.

Ensure the service's health check is registered and the DNS query uses the default behavior.

Why it fails: By default, Consul DNS queries return only healthy instances when the service has a health check. However, the question states they have already configured a TTL health check; simply relying on default behavior does not actively enforce filtering if the check is not properly associated or if the service is registered without a check. The requirement is to prevent discovery unless healthy, which default behavior may already do, but the option does not address the need to explicitly link the check or use the correct query. This option is too vague and does not guarantee the desired outcome.

Consul's external service registration via the `/catalog/register` HTTP API with a node definition

Why it fails: The `/catalog/register` API can register nodes and services, but it is typically used for manual catalog entries and does not provide built-in health checking or DNS-based service discovery for external services. It also requires managing the lifecycle manually, which is not ideal for external service integration.

Consul's `consul services register` command with a service definition file

Why it fails: The `consul services register` command registers services on the local agent, which requires an agent running on the same host. Since the external service has no agent, this command cannot be used. It also does not support registering services that reside outside the Consul cluster natively.

Consul's `consul connect` feature with an Envoy sidecar proxy

Why it fails: Consul Connect provides service-to-service security via sidecar proxies, but it does not directly register external services into the catalog for discovery. It assumes the service is part of the mesh and typically requires an agent, which is not available for the external API.

The query used does not include the `?meta` parameter to return metadata.

Why it fails: Consul's catalog API does not require a special parameter to return metadata; the `meta` field is included in the service definition and is returned by default when querying the service. There is no `?meta` parameter for this purpose. The absence of metadata suggests the service was registered without it or the query is targeting a different endpoint.

The `meta` block is only supported for services registered via the CLI, not the HTTP API.

Why it fails: The `meta` block is supported in both the HTTP API and CLI service registration. The HTTP API accepts `meta` as part of the service definition JSON. Therefore, this is not the reason for missing metadata. The issue likely lies elsewhere, such as the query not requesting the metadata or the service not being properly registered with the meta fields.

The Consul agent must be restarted after registering a service with metadata.

Why it fails: Consul does not require an agent restart to recognize service metadata. Services are registered dynamically, and metadata is stored in the catalog immediately upon successful registration. Restarting the agent would not affect the availability of metadata and is unnecessary. The missing metadata is due to the registration payload, not the agent's state.

The check is configured to run on a remote node instead of the local agent.

Why it fails: TCP checks are executed by the Consul agent on the node where the service is registered. If the check were configured for a remote node, the agent would need that node's address, but the scenario says the service is registered with the local agent. Remote execution is not a typical configuration for TCP checks and would not explain a critical status when the port is open locally.

The service is listening on localhost only, and the Consul agent cannot reach it.

Why it fails: If the service binds only to 127.0.0.1, the Consul agent can still connect because it runs on the same host. The agent uses the address specified in the check definition; if that address is 127.0.0.1, the check would pass. A critical status would occur if the check targets a different interface that is not listening, but the scenario says the port is open on the same host.

The check definition is missing the 'interval' field, so Consul never runs the check.

Why it fails: Consul requires an interval for TCP checks; if omitted, the agent rejects the registration or the check will not run. However, the scenario states the check is registered and reporting critical, meaning it is running. The absence of interval would prevent the check from executing, not cause a critical status. The critical status indicates the check ran and failed.