Hard Difficulty Questions

The service is passing; it will be deregistered after 10 minutes.

Why it fails: A TTL check that has not received an update within its TTL period becomes critical. Since the service failed to send updates for 90 seconds, and the TTL is likely set to a shorter duration (e.g., 30 seconds), the check is critical. It is not passing. The deregistration will occur, but the status is critical, not passing. Therefore, this option is incorrect.

The service is warning; it will be deregistered after 10 minutes.

Why it fails: TTL checks do not transition to a warning state automatically; they go from passing to critical when the TTL expires. Warning status is typically set explicitly by the service via the API. Therefore, the service is not in warning state. The deregistration will occur, but the status is critical, not warning. Thus, this option is incorrect.

The service is critical; it will be deregistered immediately.

Why it fails: The 'DeregisterCriticalServiceAfter' setting defines a delay after the check becomes critical before deregistration. It is not immediate. The delay is 10 minutes in this scenario. Therefore, the service will not be deregistered immediately. This option misinterprets the setting, making it incorrect.

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.

The server is down.

Why it fails: A 403 Forbidden means the request reached Consul and was rejected by ACL policy, typically a missing or invalid token. It is tempting because connectivity failures feel like the cause, but a down server yields connection refused or 500, not an authorisation denial.

The data is too large.

Why it fails: Oversized values return 413 Request Entity Too Large, not 403; Consul's KV limit is checked separately from authorisation. It is tempting because large payloads do fail, but a 403 specifically signals ACL or token rejection, which is the common cause.

The key does not exist.

Why it fails: A missing key returns 404 Not Found, not 403. Consul reserves 403 for authorisation failures, so the ACL token or policy attached to the request lacks read permission on that path. The 404/403 split is the diagnostic axis. Checking key existence is a reasonable first instinct, but that scenario yields 404.

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.

The 'web' service's sidecar proxy is not configured with the correct CA certificate.

Why it fails: An incorrect CA certificate would cause TLS handshake failures, resulting in errors like 'certificate signed by unknown authority'. The error 'no healthy upstream' is about service discovery, not certificate validation. Therefore, this is not the most likely cause.

The intention between 'web' and 'api' is set to 'deny'.

Why it fails: If an intention denies traffic, the sidecar proxy would typically log a permission denied or mTLS authentication error, not 'no healthy upstream'. Intentions are enforced after a connection is attempted, so a deny intention would not prevent the proxy from discovering the upstream service. Thus, this is not the cause of the specific error.

The mesh gateway is not registered as a service in Consul.

Why it fails: Mesh gateways must be registered as services in Consul to be used. However, if the mesh gateway were not registered, the sidecar proxy would likely report a different error, such as 'no gateway available'. The specific error 'no healthy upstream' typically indicates that the upstream service itself is not reachable or has no healthy instances, not that the gateway is missing.

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.

The agent is restarting

Why it fails: An agent restart briefly marks its services critical while checks are re-registered, not warning. Warning is emitted when a check executes and returns a non-passing state such as HTTP 500. Agent restarts would be the answer only if the question concerned transient critical flapping during agent startup.

The network is down

Why it fails: Network loss between Consul agents produces a critical status, since the service check cannot be executed or its node is marked failed. Warning arises when the check runs and returns a non-passing result, not when connectivity is absent. Network failure would be the answer only for a node-level health question.

The service crashed

Why it fails: A crashed service process is reported as critical, because the check itself fails outright rather than merely missing its output. Warning is reserved for a check that executes successfully but returns a non-passing status, such as a failing HTTP or script check. A crash would be the answer only if the question asked about critical status.

cleanup_interval

Why it fails: cleanup_interval controls how often Consul sweeps dead nodes and stale entries, not how long a service may remain critical before removal. It tempts because cleanup sounds like deregistration, and it would be the right choice if the requirement concerned node reaping frequency rather than a critical-state duration threshold.

critical_timeout

Why it fails: No such Consul configuration key exists; deregistration after sustained critical health is governed by deregister_critical_service_after in the service definition. It tempts because the name suggests a timeout on critical state, which would be the right concept if Consul exposed a per-status timeout rather than a single deregistration threshold.

remove_service_after

Why it fails: remove_service_after is not a Consul health-check field; Consul uses deregister_critical_service_after to remove a service once it stays critical past the specified duration. It tempts because the name describes exactly the desired outcome, and it would be correct if Consul named its deregistration parameter by effect rather than by the critical state.

KV Mirroring.

Why it fails: KV mirroring is a feature, but ACL replication is the standard for secrets.

Automatic Secret Rotation.

Why it fails: This is not a specific multi-DC feature.

Centralized Config.

Why it fails: This is for configuration entries, not secrets.

Only instances from `dc2` if `dc1` has no healthy instances.

Why it fails: Consul does not automatically failover to another datacenter in DNS queries by default. Even if `dc1` has no healthy instances, a default DNS query will return an empty result or only unhealthy instances (depending on query parameters). Failover must be configured using prepared queries with `Failover` settings. Thus, this option is not the default behavior.

Instances from both `dc1` and `dc2`, load-balanced.

Why it fails: Consul does not automatically load-balance across datacenters for DNS queries. By default, only the local datacenter's instances are returned. Returning instances from both datacenters would require explicit configuration or the use of prepared queries with datacenter failover, which is not the default behavior. Therefore, this option is incorrect.

Instances from all datacenters, sorted by latency.

Why it fails: Consul DNS queries do not return instances from all datacenters by default. They are scoped to the local datacenter unless a specific datacenter is specified in the query. Sorting by latency is achieved with the `?near` parameter, but that only applies within the queried datacenter. Therefore, this option is incorrect.

Configure 'service_prefix' in DNS settings.

Why it fails: service_prefix controls DNS subdomain naming, not health-check aggregation, so it cannot restrict records to fully passing instances. It tempts as a DNS-level setting, but the correct mechanism is a passing health-check requirement, such as only_passing, which excludes warning states.

Use the 'stale' query parameter.

Why it fails: The 'stale' parameter permits reads from non-leader servers with slightly outdated data, so it cannot filter health-check states at all. It is tempting because it widens DNS results during outages, but the stem requires excluding warning checks, which only the 'passing' parameter achieves.

Set 'enable_tag_override' to true.

Why it fails: Tag override lets a service's own tags supersede agent-registered tags; it has no bearing on which health checks gate DNS answers. It is tempting as a service-registration control, but the stem's requirement is filtering on check status, which 'passing' handles.

weight

Why it fails: Weight is a service attribute.

service_id

Why it fails: This is for the service itself.

The session stays active.

Why it fails: It will expire due to inactivity or health check failure.

The session is immediately deleted.

Why it fails: It remains until the TTL expires.

The session is transferred to another node.

Why it fails: Sessions are tied to the node's lifecycle.

The 'client_addr' restricted to local only.

Why it fails: Client addresses are for local access.

The 'ui' configuration set to true.

Why it fails: UI configuration is independent.

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.

Disable mTLS globally, update, and re-enable.

Why it fails: Disabling mTLS is a security risk and unnecessary.

Delete the existing CA and restart all agents.

Why it fails: This would cause immediate mTLS failures.

Use the 'consul tls ca create' command with the --rotate flag.

Why it fails: This command does not exist in the CLI.

By appending it to the URL string

Why it fails: Headers cannot be set through URL query strings; Consul's HTTP check sends only the request line and default headers, so appending text to the URL changes the path, not a header. The header field exists for this purpose, making it the correct mechanism when a custom header must be verified.

It is not possible

Why it fails: Consul's HTTP check definition includes a header map, so arbitrary request headers can be specified and verified. Declaring it impossible ignores that configuration block. The option would only hold if the check schema lacked any header field, which it does not.

By setting the environment variable

Why it fails: Header values for HTTP health checks are configured in the service definition's header block, not through an environment variable. It is tempting because environment variables can inject configuration into checks, but Consul reads headers from the check's declared header map, so an environment variable has no effect.

checks

Why it fails: Health checks govern service registration and instance health, not Envoy sidecar startup; a malformed check fails the service, not the proxy process. It is tempting because checks are the usual cause of services being marked unhealthy, and it would be correct when instances are deregistered despite the proxy running.

meta

Why it fails: Meta holds arbitrary key-value metadata for filtering and UI display, and Consul never parses it to configure Envoy. It is tempting because meta appears in service definitions alongside proxy settings, and it would be correct when you need custom attributes for intentions or API filtering.

tags

Why it fails: Tags are opaque labels used for filtering and versioning, and they do not feed Envoy's bootstrap configuration. It is tempting because tags sit in the same service block as proxy settings, and it would be correct when restricting which instances a upstream selects.

service_prefix "*" { policy = "write" }

Why it fails: Write access is not required for discovery.

agent_prefix "" { policy = "read" }

Why it fails: Agent read is for local agent status.

acl_prefix "" { policy = "read" }

Why it fails: This relates to ACL management, not service discovery.

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.