Scenario practice questions

An operations team runs a legacy application that cannot expose an HTTP endpoint but does listen on TCP port 5432. They define a TCP health check in the service registration. During an incident, the port remains open but the application process is hung and no longer accepts new connections. What will Consul report for this check?

Trap 1: warning, because the TCP handshake is slow

The scenario does not state that the handshake is slow, only that the application is hung after the port is open. Warning status is not automatically assigned based on latency. Consul's TCP check either succeeds or fails; it does not produce a warning purely because the application behind the port is unresponsive.

Trap 2: critical, because the application is hung

Consul's TCP check has no application-level awareness. It does not send data or inspect the application's state; it only verifies that a TCP connection can be established. A hung process that still holds the listening socket open will not cause a critical result, so this answer misstates how the check works.

Trap 3: maintenance, because the process is not accepting connections

Maintenance mode is an operator-controlled state, not an automatic result of application behavior. Consul does not place a check into maintenance because a process is hung. The TCP check will still evaluate the socket and report passing if the port accepts a connection, so maintenance is not applicable here.

A
warning, because the TCP handshake is slow
Why it fails: The scenario does not state that the handshake is slow, only that the application is hung after the port is open. Warning status is not automatically assigned based on latency. Consul's TCP check either succeeds or fails; it does not produce a warning purely because the application behind the port is unresponsive.
B
critical, because the application is hung
Why it fails: Consul's TCP check has no application-level awareness. It does not send data or inspect the application's state; it only verifies that a TCP connection can be established. A hung process that still holds the listening socket open will not cause a critical result, so this answer misstates how the check works.
C
maintenance, because the process is not accepting connections
Why it fails: Maintenance mode is an operator-controlled state, not an automatic result of application behavior. Consul does not place a check into maintenance because a process is hung. The TCP check will still evaluate the socket and report passing if the port accepts a connection, so maintenance is not applicable here.
D
passing, because the TCP port is open
A TCP check only attempts to open a connection to the configured host and port. If the TCP handshake succeeds, the check is passing regardless of whether the application accepts or processes data on that connection. In this scenario the port is still open, so Consul reports passing even though the process is hung.

Question 2mediummultiple choice

You are deploying a service that requires distributed locking with automatic release if the service instance fails. You have created a session named 'lock-session' and acquired a lock on the KV key 'locks/db'. After a few minutes, the lock is unexpectedly released even though the service instance is still running. Which action should you take to diagnose the most likely cause?

Trap 1: Inspect the KV key's metadata to see if it was modified externally.

External modification of the KV key does not release a lock; the lock is tied to the session, not the key's value. The lock is released only when the session is invalidated or explicitly destroyed. Inspecting metadata might show changes but won't explain automatic release. This distractor misattributes the lock release mechanism.

Trap 2: Check the Consul server logs for errors related to the session.

While server logs can reveal session-related issues, they are not the primary diagnostic for unexpected lock release due to session invalidation. The most common cause is the session TTL expiring because the service failed to renew it. Checking logs might show TTL expiration, but it's more direct to verify session renewal activity from the client side. This option is plausible but not the best first step.

Trap 3: Restart the Consul agent on the node where the service is running.

Restarting the Consul agent would not resolve a session renewal issue and could disrupt other services. The problem is likely on the service side, not the agent. Restarting might temporarily clear the issue but does not address the root cause of missed renewals. This is an incorrect troubleshooting step for this scenario.

A
Inspect the KV key's metadata to see if it was modified externally.
Why it fails: External modification of the KV key does not release a lock; the lock is tied to the session, not the key's value. The lock is released only when the session is invalidated or explicitly destroyed. Inspecting metadata might show changes but won't explain automatic release. This distractor misattributes the lock release mechanism.
B
Check the Consul server logs for errors related to the session.
Why it fails: While server logs can reveal session-related issues, they are not the primary diagnostic for unexpected lock release due to session invalidation. The most common cause is the session TTL expiring because the service failed to renew it. Checking logs might show TTL expiration, but it's more direct to verify session renewal activity from the client side. This option is plausible but not the best first step.
C
Restart the Consul agent on the node where the service is running.
Why it fails: Restarting the Consul agent would not resolve a session renewal issue and could disrupt other services. The problem is likely on the service side, not the agent. Restarting might temporarily clear the issue but does not address the root cause of missed renewals. This is an incorrect troubleshooting step for this scenario.
D
Verify that the service is sending session renewals within the TTL period.
Consul sessions are invalidated if not renewed within their TTL. If the service fails to renew the session, the lock is released automatically. This is the most likely cause when the service is still running but not properly renewing. Checking renewal activity directly addresses the root cause and is the correct diagnostic step.

Question 3mediummultiple choice

A service 'orders' must call an upstream database service through its sidecar proxy. The upstream is registered in the same Consul datacenter and the operator wants the sidecar to discover it dynamically rather than hard-code an address. Which upstream configuration entry in the sidecar_service stanza accomplishes this?

Trap 1: A local_bind_port and a destination_name, but with destination_type…

Setting the datacenter to a remote value changes the discovery target to a different Consul datacenter, which typically requires a mesh gateway to bridge traffic. The scenario states the upstream is in the same datacenter, so this configuration would send requests to the wrong place or fail without a gateway. The local bind port alone does not correct the wrong discovery scope.

Trap 2: destination_type set to 'static' with a destination_name equal to…

A static destination type tells the sidecar to treat the destination as a fixed address rather than a Consul service, so no catalog discovery or health filtering occurs. If the upstream moves or new instances appear, the proxy keeps sending traffic to the original address. This directly contradicts the requirement for dynamic discovery.

Trap 3: destination_type set to 'prepared_query' with a destination_name…

Prepared query destinations are valid, but they require an existing prepared query to be defined and add failover and nearness semantics on top of discovery. The scenario asks for straightforward dynamic discovery of a registered service, and introducing a prepared query is unnecessary complexity. If the query does not exist, the sidecar cannot resolve the upstream at all.

A
A local_bind_port and a destination_name, but with destination_type omitted and datacenter set to a remote value.
Why it fails: Setting the datacenter to a remote value changes the discovery target to a different Consul datacenter, which typically requires a mesh gateway to bridge traffic. The scenario states the upstream is in the same datacenter, so this configuration would send requests to the wrong place or fail without a gateway. The local bind port alone does not correct the wrong discovery scope.
B
destination_type set to 'static' with a destination_name equal to the upstream's DNS name.
Why it fails: A static destination type tells the sidecar to treat the destination as a fixed address rather than a Consul service, so no catalog discovery or health filtering occurs. If the upstream moves or new instances appear, the proxy keeps sending traffic to the original address. This directly contradicts the requirement for dynamic discovery.
C
destination_name set to the upstream service name, with no destination_type or fixed address.
When destination_type is left at its default of service, the sidecar resolves the upstream through Consul's service discovery using destination_name. The proxy watches the catalog for healthy instances and load-balances across them, so IP changes and scaling events are handled automatically. Hard-coding an address would defeat the purpose of dynamic discovery.
D
destination_type set to 'prepared_query' with a destination_name matching the upstream service.
Why it fails: Prepared query destinations are valid, but they require an existing prepared query to be defined and add failover and nearness semantics on top of discovery. The scenario asks for straightforward dynamic discovery of a registered service, and introducing a prepared query is unnecessary complexity. If the query does not exist, the sidecar cannot resolve the upstream at all.

Question 4easymultiple choice

A Consul operator wants to ensure that if the primary datacenter becomes unavailable, the secondary datacenter can continue to operate for existing services and intentions. Which statement best describes Consul's behavior in this scenario?

Trap 1: The secondary datacenter will switch to using its local ACLs and…

The secondary datacenter does not ignore the primary's configuration. It continues to use the replicated ACLs and intentions from the primary. It does not switch to a separate local configuration. The primary remains the source of truth for ACLs and intentions, even when unavailable, until manually changed.

Trap 2: The secondary datacenter will immediately stop all services and…

Consul is designed for resilience. The secondary datacenter does not stop services if the primary is unreachable. It continues to operate using its local state, including service registrations and health checks. Only operations that require the primary, such as ACL token creation, are affected.

Trap 3: The secondary datacenter will automatically promote itself to…

Consul does not support automatic promotion of a secondary datacenter to primary. Promotion is a manual process that requires reconfiguring the datacenter. Automatic failover of the primary role is not a feature of Consul's multi-datacenter federation. The secondary will continue to operate for existing services but will not become primary.

A
The secondary datacenter will continue to serve existing services and enforce replicated intentions, but new ACL tokens or intention changes cannot be made until the primary is restored.
In a federated setup, the secondary datacenter maintains its own state and can continue to serve existing services using local data. Replicated ACLs and intentions are enforced based on the last successful replication. However, any changes to ACLs or intentions must be made in the primary, so new changes cannot be applied until the primary is back online.
B
The secondary datacenter will switch to using its local ACLs and intentions, ignoring the primary's configuration entirely.
Why it fails: The secondary datacenter does not ignore the primary's configuration. It continues to use the replicated ACLs and intentions from the primary. It does not switch to a separate local configuration. The primary remains the source of truth for ACLs and intentions, even when unavailable, until manually changed.
C
The secondary datacenter will immediately stop all services and return errors until the primary datacenter is reachable again.
Why it fails: Consul is designed for resilience. The secondary datacenter does not stop services if the primary is unreachable. It continues to operate using its local state, including service registrations and health checks. Only operations that require the primary, such as ACL token creation, are affected.
D
The secondary datacenter will automatically promote itself to primary and continue operating without interruption.
Why it fails: Consul does not support automatic promotion of a secondary datacenter to primary. Promotion is a manual process that requires reconfiguring the datacenter. Automatic failover of the primary role is not a feature of Consul's multi-datacenter federation. The secondary will continue to operate for existing services but will not become primary.

Study the full ACL explanation →

Question 5hardmultiple choice

You are configuring a Consul secondary datacenter to replicate ACLs from the primary. You have set 'primary_datacenter' and 'acl_replication_token' on the servers. However, replication is failing. Which of the following is the most likely cause?

Trap 1: The secondary datacenter does not have 'verify_outgoing' enabled…

TLS settings like 'verify_outgoing' are not required for ACL replication. While they enhance security, they are not a prerequisite for replication to function. Replication uses RPC over the WAN, which can be secured with TLS, but the absence of TLS verification does not cause replication to fail.

Trap 2: The 'encrypt' key is different between the primary and secondary…

A mismatched 'encrypt' key would prevent WAN gossip communication, which would also break replication, but the question states that 'primary_datacenter' and 'acl_replication_token' are set. If the encryption key were mismatched, the servers would not be able to join the WAN gossip pool, and replication would fail at a lower level. However, the most likely cause given the configuration is the token permissions.

Trap 3: The 'acl_replication_token' is set on the client agents instead of…

The 'acl_replication_token' must be set on the servers in the secondary datacenter, as they are responsible for replicating ACL data. If set on client agents, it would have no effect. However, the question states it is set on the servers, so this is not the cause. The most likely cause is insufficient permissions on the token.

A
The secondary datacenter does not have 'verify_outgoing' enabled for TLS.
Why it fails: TLS settings like 'verify_outgoing' are not required for ACL replication. While they enhance security, they are not a prerequisite for replication to function. Replication uses RPC over the WAN, which can be secured with TLS, but the absence of TLS verification does not cause replication to fail.
B
The 'encrypt' key is different between the primary and secondary datacenters.
Why it fails: A mismatched 'encrypt' key would prevent WAN gossip communication, which would also break replication, but the question states that 'primary_datacenter' and 'acl_replication_token' are set. If the encryption key were mismatched, the servers would not be able to join the WAN gossip pool, and replication would fail at a lower level. However, the most likely cause given the configuration is the token permissions.
C
The 'acl_replication_token' is set on the client agents instead of the servers.
Why it fails: The 'acl_replication_token' must be set on the servers in the secondary datacenter, as they are responsible for replicating ACL data. If set on client agents, it would have no effect. However, the question states it is set on the servers, so this is not the cause. The most likely cause is insufficient permissions on the token.
D
The 'acl_replication_token' does not have 'acl:read' permissions on the primary datacenter.
For ACL replication to work, the replication token must have 'acl:read' permissions on the primary datacenter. Without this, the secondary servers cannot read the ACL policies, tokens, and intentions from the primary, causing replication to fail. This is a common misconfiguration.

Question 6hardmultiple choice

A service is registered with a check that has deregister_critical_service_after set to 30m. The service's check enters the critical state due to a transient network partition. The partition is resolved after 20 minutes, and the check returns to passing. What is the effect on the service registration?

Trap 1: The service is deregistered immediately when the check becomes…

Immediate deregistration on critical is not how this field works. The purpose of deregister_critical_service_after is to delay cleanup, giving operators time to investigate and allowing transient issues to resolve. If immediate deregistration were desired, a different approach such as external automation would be needed.

Trap 2: The service is deregistered after 30 minutes from the initial…

The deregister_critical_service_after field is not a fixed lifetime for the service. It is a timer that starts when the check becomes critical and resets when the check returns to passing. It does not measure time from registration, so this option describes a different mechanism than the one configured.

Trap 3: The service is deregistered because it was critical at any point

Deregistration does not occur simply because a check was critical at some point. The deregister_critical_service_after field requires the check to remain critical for the full specified duration. A transient critical state that resolves before the timer expires does not cause deregistration, so this answer misinterprets the field's behavior.

A
The service remains registered because the check returned to passing before the 30-minute deregistration timer expired
The deregister_critical_service_after timer is reset when the check leaves the critical state. Since the check returned to passing after 20 minutes, well before the 30-minute threshold, the service is not deregistered. The timer only triggers deregistration if the check stays critical continuously for the configured duration.
B
The service is deregistered immediately when the check becomes critical
Why it fails: Immediate deregistration on critical is not how this field works. The purpose of deregister_critical_service_after is to delay cleanup, giving operators time to investigate and allowing transient issues to resolve. If immediate deregistration were desired, a different approach such as external automation would be needed.
C
The service is deregistered after 30 minutes from the initial registration, regardless of check state
Why it fails: The deregister_critical_service_after field is not a fixed lifetime for the service. It is a timer that starts when the check becomes critical and resets when the check returns to passing. It does not measure time from registration, so this option describes a different mechanism than the one configured.
D
The service is deregistered because it was critical at any point
Why it fails: Deregistration does not occur simply because a check was critical at some point. The deregister_critical_service_after field requires the check to remain critical for the full specified duration. A transient critical state that resolves before the timer expires does not cause deregistration, so this answer misinterprets the field's behavior.

Question 7easymultiple choice

You are deploying a legacy application that does not support HTTP or TCP health checks. Which Consul health check type should you configure to allow the application to signal its own health via a heartbeat API call?

Trap 1: HTTP check

An HTTP check actively requests an endpoint and interprets the response code, which the legacy application cannot expose. It is tempting because HTTP checks are the common pattern for web services, but the stem requires the application to push its own heartbeat, which HTTP polling cannot receive.

Trap 2: TCP check

A TCP check only verifies that a socket accepts connections, so it cannot receive an application-initiated heartbeat and would report healthy regardless of internal state. It is tempting for simple liveness detection, but the stem requires the application to signal its own health, which TCP checks cannot carry.

Trap 3: Script check

A script check runs an external command on an interval, so it polls rather than accepting a heartbeat pushed by the application; the legacy app cannot be probed. Scripts are tempting for custom logic, but the stem requires the application itself to call in, which only the TTL check supports.

A
TTL check
A TTL check inverts the model: the application must periodically call Consul's HTTP pass endpoint to reset the timer, and Consul marks it critical if the heartbeat lapses. This suits legacy apps lacking HTTP or TCP endpoints, since they signal health themselves.
B
HTTP check
Why it fails: An HTTP check actively requests an endpoint and interprets the response code, which the legacy application cannot expose. It is tempting because HTTP checks are the common pattern for web services, but the stem requires the application to push its own heartbeat, which HTTP polling cannot receive.
C
TCP check
Why it fails: A TCP check only verifies that a socket accepts connections, so it cannot receive an application-initiated heartbeat and would report healthy regardless of internal state. It is tempting for simple liveness detection, but the stem requires the application to signal its own health, which TCP checks cannot carry.
D
Script check
Why it fails: A script check runs an external command on an interval, so it polls rather than accepting a heartbeat pushed by the application; the legacy app cannot be probed. Scripts are tempting for custom logic, but the stem requires the application itself to call in, which only the TTL check supports.