How many Troubleshooting Scenario Questions questions are on this page?

This page has 12 Troubleshooting Scenario Questions scenario questions for the Consul 1.15 exam, each with detailed explanations and wrong-answer analysis.

How should I approach Consul 1.15 scenario questions?

Read the full scenario before looking at the answer options. Identify the constraint or requirement in the scenario, then eliminate options that are generally true but wrong for this specific case. Scenario questions reward careful reading over pattern matching.

← Back to HashiCorp Certified: Consul Associate (Consul 1.15) (Consul 1.15) questions

Scenario-based practice

Troubleshooting Scenario Questions

Practise HashiCorp Certified: Consul Associate (Consul 1.15) (Consul 1.15) practice questions — original exam-style scenarios covering every exam domain, with detailed explanations, wrong-answer analysis, and common exam traps.

Start full practice test Read exam guide

scenario questions

Consul 1.15

exam code

HashiCorp

vendor

Scenario guide

How to approach troubleshooting scenario questions

These questions describe a network symptom and ask you to identify the root cause or the correct fix. They appear across all certification exams and reward systematic thinking over memorisation. The best candidates follow a consistent troubleshooting framework even under time pressure.

Quick answer

Troubleshooting Scenario Questions questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Related Consul 1.15 topic practice pages

Scenario questions usually connect to one or more exam topics. Use these links to review the underlying concepts behind the scenario.

Service Discovery practice questions

Practise Consul 1.15 questions linked to Service Discovery.

Multi Datacenter Federation practice questions

Targeted Consul 1.15 practice covering Multi Datacenter Federation.

Health Checking practice questions

Targeted Consul 1.15 practice covering Health Checking.

Service Mesh With Consul Connect practice questions

Practise Consul 1.15 questions linked to Service Mesh With Consul Connect.

Key Value Store practice questions

Sharpen your Consul 1.15 knowledge of Key Value Store.

Consul 1.15 fundamentals practice questions

Sharpen your Consul 1.15 knowledge of Consul 1.15 fundamentals.

Consul 1.15 scenario practice questions

Consul 1.15 scenario practice questions for Consul 1.15.

Consul 1.15 troubleshooting practice questions

Consul 1.15 troubleshooting practice questions for Consul 1.15.

Practice set

Practice scenarios

Question 1hardmultiple choice

Full question →

An operator registers a service with a TTL health check. The service is responsible for updating the check status via the HTTP API. The service fails to send updates for 90 seconds. The check is configured with 'DeregisterCriticalServiceAfter' set to 10 minutes. What is the current health status of the service, and what will happen after 10 minutes?

A
The service is critical; it will be deregistered after 10 minutes.
TTL checks transition to critical if not updated within the TTL interval. After 90 seconds without an update, the check is critical. The 'DeregisterCriticalServiceAfter' setting specifies that if the check remains critical for 10 minutes, the service instance is automatically deregistered from the catalog. This matches the scenario, making this the correct answer.
B
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.
C
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.
D
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.

Full breakdown with real-world context →

Question 2mediummultiple choice

Full question →

You are troubleshooting a health check that seems to be hanging. Which flag, if available, would provide more information about the check's execution within the agent logs?

A
-verbose
Why it fails: -verbose is not a Consul agent flag; verbosity is set through log_level, so it cannot reveal a hanging check's execution. It is tempting because verbose output feels diagnostic, and it would be correct for CLI commands that accept it, such as some consul CLI subcommands, not the agent.
B
-log-level=debug
Raising the agent's log verbosity to debug makes Consul emit detailed health-check execution output, including script invocations and timing, which reveals where a hanging check stalls. The -log-level=debug flag therefore exposes the check's internal behaviour in the agent logs.
C
-monitor-checks
Why it fails: -monitor-checks is not a Consul agent flag; check monitoring is exposed through the /v1/agent/checks HTTP endpoint, so it cannot surface execution detail in agent logs. It is tempting because it names checks directly, and it would suit querying check status via the API, not log-level debugging.
D
-trace
Why it fails: Consul has no -trace flag for agent logging; log levels stop at trace only via log_level configuration, not a CLI switch, so it cannot expose check execution. It is tempting because tracing sounds like the deepest diagnostic, and it would be right for instrumenting code paths, not for a hanging check's agent logs.

Full breakdown with real-world context →

Question 3hardmultiple choice

Full question →

When troubleshooting a service that fails to start its Envoy proxy, which service definition field should you check for incorrect configuration?

A
proxy
The `proxy` block configures the sidecar's Envoy settings, including upstreams, listeners and bootstrap options. Incorrect values here directly prevent the proxy from starting, so it is the field to inspect first when diagnosing startup failure.
B
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.
C
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.
D
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.

Full breakdown with real-world context →

Question 4hardmultiple choice

Study the full ACL explanation →

An operator is troubleshooting a Consul datacenter that was recently federated with another datacenter. They notice that cross-datacenter service discovery works, but ACL tokens created in the primary datacenter are not being recognized in the secondary datacenter. What is the most likely cause?

A
The primary datacenter's servers are not configured with retry_join_wan pointing to the secondary.
Why it fails: retry_join_wan is used for WAN gossip federation, not ACL replication. While WAN federation is necessary for cross-datacenter communication, ACL replication specifically requires a replication token. The primary datacenter does not need retry_join_wan to the secondary for ACL replication to work; the secondary initiates the replication connection.
B
The secondary datacenter's servers have a different gossip encryption key than the primary.
Why it fails: A mismatched gossip encryption key would prevent WAN gossip federation entirely, which would also break cross-datacenter service discovery. Since the operator reports that service discovery works, the gossip key is likely correct. ACL replication uses RPC over the WAN and is not directly affected by the gossip encryption key.
C
The secondary datacenter is configured with primary_datacenter set to its own name instead of the primary's name.
Why it fails: If primary_datacenter is set incorrectly, the secondary may not know which datacenter to replicate from, but this would typically cause broader issues with ACL replication and CA management. However, the most direct cause of tokens not being replicated is a missing or invalid acl_replication_token. Setting primary_datacenter incorrectly is a configuration error, but the replication token is the specific mechanism that enables ACL data transfer.
D
The secondary datacenter's servers are not configured with a valid acl_replication_token.
ACL replication requires the secondary datacenter to authenticate to the primary using a token with replication permissions. If acl_replication_token is missing, expired, or lacks the necessary policies, the secondary cannot pull token and policy updates. As a result, tokens created in the primary will not be replicated, and the secondary will not recognize them for authorization.

Full breakdown with real-world context →

Question 5easymultiple choice

Full question →

You are troubleshooting a Consul Connect service mesh and need to verify which intentions are currently configured. Which Consul CLI command lists all intentions?

A
consul connect intentions
Why it fails: There is no 'consul connect intentions' subcommand. The 'consul connect' command has subcommands like 'envoy', 'proxy', and 'ca', but not 'intentions'. Intentions are managed under the top-level 'consul intention' command. Therefore, this command does not exist and would produce an error.
B
consul intention get -all
Why it fails: The 'consul intention get' command is used to retrieve a specific intention by its ID or source/destination pair. It does not support an '-all' flag to list all intentions. To list all, you use the 'list' subcommand. Thus, this command is incorrect for listing all intentions.
C
consul intention list
The 'consul intention list' command queries Consul and displays all intentions that have been created. It shows the source and destination services, the action (allow or deny), and other metadata. This is the correct command to verify the current intentions in the mesh. It is a straightforward and commonly used command for auditing Connect authorization.
D
consul catalog intentions
Why it fails: The 'consul catalog' command is used to interact with the catalog of registered services and nodes. It does not have an 'intentions' subcommand. Intentions are separate from the catalog and are managed via the 'consul intention' command. Therefore, this command does not exist and is not correct.

Full breakdown with real-world context →

Question 6hardmultiple choice

Full question →

A service mesh operator is troubleshooting a connectivity issue between two services in a Consul 1.15 datacenter. The sidecar proxy for the 'frontend' service cannot reach the 'backend' upstream. The operator has confirmed that intentions allow the traffic. Which log should they inspect first to diagnose the issue on the sidecar proxy?

A
The systemd journal for the 'backend' service.
Why it fails: The backend service's systemd journal would show logs from the application itself, not from the frontend sidecar proxy. The issue is that the frontend proxy cannot reach the backend, so the problem could be in the frontend proxy's configuration or network path. Backend application logs might show incoming requests if they arrive, but they won't explain why the frontend proxy fails to connect. Therefore, this is not the most relevant log.
B
The Consul agent logs on the node running the frontend service.
Why it fails: Consul agent logs primarily show agent-level events such as membership, anti-entropy, and intention updates. While they may contain some proxy-related messages, they do not provide detailed connection-level debugging for the Envoy sidecar proxy. The sidecar proxy's own logs are more granular for network issues. Therefore, agent logs are not the first place to look for proxy connectivity failures.
C
The Envoy proxy logs for the frontend sidecar.
Envoy proxy logs contain detailed information about connection attempts, including upstream cluster selection, TLS handshakes, and errors such as connection refused or timeout. Since the sidecar proxy is Envoy, its logs are the most direct source for diagnosing why it cannot reach the 'backend' upstream. These logs are typically written to a file or stdout depending on the proxy configuration. Inspecting them first will reveal specific failure reasons.
D
The Consul server logs on the leader.
Why it fails: Consul server logs track Raft, catalog, and intention operations, but they do not record individual service-to-service connection attempts. They might show intention evaluations, but if intentions are confirmed to allow traffic, the issue is likely in the data plane. Server logs would not provide the granular proxy-level errors needed to diagnose a sidecar connectivity problem. Thus, they are not the best starting point.

Full breakdown with real-world context →

Question 7mediummulti select

Full question →

When troubleshooting a failing health check, which tools are recommended? (Select TWO)

A
Consul UI
The Consul UI displays each service's health check status, output and last-updated timestamp, letting you identify which check is failing and why. This directly satisfies the troubleshooting scenario by exposing the check's current state without command-line inspection.
B
Agent logs
Agent logs record health check execution results, including failures and their error output, on the node running the check. Reviewing them reveals the specific cause of a failing check, satisfying the troubleshooting requirement for diagnostic evidence.
C
DNS query
Why it fails: A DNS query tests name resolution, not the HTTP or TCP health check Consul performs against the service, so it cannot show why the check returns a critical status. It is tempting because service discovery relies on DNS, making resolution failures a plausible suspicion worth ruling out.
D
Consul key-value store
Why it fails: The key-value store holds configuration and coordination data; it does not execute or report the health check, so it cannot show why the check is failing. It is tempting because service registration data lives there, and inspecting it would be correct when verifying whether a service registered at all.
E
System metrics
Why it fails: System metrics report host CPU, memory and disk usage, which do not reveal whether Consul's health check request itself reached the service or what status it returned. They are tempting because resource exhaustion is a common cause of failing services, and metrics would be the right tool for diagnosing that specific symptom.

Full breakdown with real-world context →

Question 8hardmultiple choice

Full question →

You are troubleshooting a partition between two datacenters. The WAN gossip shows high latency. Which Consul CLI tool provides the best insight into the WAN gossip state?

A
consul operator raft list-peers
Why it fails: consul operator raft list-peers reports the Raft consensus peer set and leadership within a single datacenter, not WAN gossip membership or latency between datacenters. It is the right tool for diagnosing Raft quorum, leader elections and peer health inside one cluster.
B
consul members -wan
`consul members -wan` queries the WAN gossip pool directly, listing every datacenter's server agents with their gossip status and round-trip latency. That satisfies the stem's need for insight into WAN gossip state under high latency, unlike LAN-scoped commands or RPC-based tooling that bypass the gossip layer entirely.
C
consul monitor
Why it fails: consul monitor streams the agent's log output, which records gossip-related messages but gives no direct view of WAN member health or latency between datacenters. It suits watching live agent logs during general troubleshooting rather than inspecting gossip membership state.
D
consul kv get
Why it fails: consul kv get reads a key-value entry from the KV store and exposes nothing about gossip membership, datacenter reachability or latency. It is the correct choice when retrieving stored configuration or application data from Consul's KV store.

Full breakdown with real-world context →

Question 9hardmultiple choice

Full question →

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?

A
Increase the `deregister_critical_service_after` value in the agent configuration
The `deregister_critical_service_after` setting controls how long a service can be critical before being automatically deregistered. By default, it is 30 minutes. If the service is intermittently failing health checks, increasing this value gives more time for the service to recover before being removed. This is the correct approach to prevent deregistration due to temporary failures.
B
Set the `status` field of the service to `passing` in the service definition
Why it fails: Manually setting the status to `passing` would override the health check results and could mask real issues. It is not a recommended practice and does not prevent deregistration if the check later fails. It also does not solve the intermittent failure problem.
C
Disable the health check by removing the `check` block from the service definition
Why it fails: Removing the health check would prevent the service from being marked critical, but it also removes health monitoring, which is not desirable. The service would always be considered healthy, but the operator would lose visibility into its actual health. This is not a proper solution for intermittent failures.
D
Change the health check to a script check that runs every 30 seconds
Why it fails: Switching to a script check would not prevent deregistration if the check fails. The issue is that the service is marked critical, and the deregistration is based on the critical timeout. A script check might still fail, and the service would still be deregistered after the timeout. It does not address the root cause.

Full breakdown with real-world context →

Question 10mediummultiple choice

Full question →

A platform team runs a Consul 1.15 cluster where a critical payment service is registered with a TTL health check. The service owner wants Consul to mark the check as critical if the application fails to renew the TTL for more than one minute. Which configuration field should be set in the service definition to enforce this behavior?

A
ttl
For a TTL check, the ttl field specifies the duration after which the check becomes critical if no successful update is received. Setting it to 1m ensures that if the application does not renew the TTL within one minute, Consul marks the check critical, exactly matching the requirement.
B
deregister_critical_service_after
Why it fails: This field controls how long Consul waits before deregistering a service after its check becomes critical; it does not define the timeout for TTL renewals. Setting it would remove the service entirely instead of marking it critical after one minute of missed renewals, which is not the requested behavior.
C
interval
Why it fails: The interval field applies to script, HTTP, and TCP checks and determines how often Consul executes the check. TTL checks are passive and do not run on an interval; they rely on the application to renew them. Setting interval would not enforce a one-minute critical timeout for TTL renewals.
D
timeout
Why it fails: The timeout field is used by script, HTTP, and TCP checks to define how long Consul waits for a response before considering the check failed. TTL checks do not use timeout; they depend on the interval between renewals. Using timeout here would not affect TTL expiry behavior.

Full breakdown with real-world context →

Question 11mediummulti select

Full question →

Which TWO of the following are valid ways to troubleshoot inter-datacenter communication issues?

A
Change the datacenter name in the config.
Why it fails: Changing the datacenter name alters the local agent's identity and breaks its existing federation membership, worsening the issue rather than diagnosing it. It is tempting because datacenter naming appears in configuration, but inter-datacenter troubleshooting relies on inspecting WAN federation and server connectivity instead.
B
Inspect server logs for RPC errors between datacenters.
Inspecting server logs surfaces RPC errors that reveal failed cross-datacenter RPCs, directly satisfying the need to diagnose inter-datacenter communication faults. Consul's server-to-server RPC traffic carries replication and forwarding requests, so logged RPC failures pinpoint connectivity or TLS problems between datacenters.
C
Restart all clients in the datacenter.
Why it fails: Restarting all clients disrupts the datacenter without isolating the cause of the communication failure. It is tempting because restarts often clear transient faults, but effective troubleshooting examines WAN federation, ports, and server health rather than blindly cycling agents.
D
Use 'consul members -wan' to verify remote server visibility.
The 'consul members -wan' command lists all WAN gossip pool members and their status, exposing whether remote datacenter servers are visible and healthy. This directly verifies inter-datacenter gossip connectivity, making it a valid troubleshooting method.
E
Use 'consul kv export' to sync data.
Why it fails: Key-value export merely serialises the KV store for backup or migration; it neither queries datacentre peer health nor surfaces WAN, gossip or RPC failures. It tempts because KV data is replicated across datacentres, so operators assume exporting it verifies that replication, but the correct tools are 'consul members -wan' and 'consul operator raft list-peers'.

Full breakdown with real-world context →

Question 12hardmultiple choice

Full question →

When a health check is failing, which Consul API endpoint would you call to investigate the specific error message provided by the check?

A
/v1/agent/services
Why it fails: The agent/services endpoint lists services registered with the local agent and their tags and ports, but omits health-check status and output. It is tempting because it enumerates services, and would be the right call when confirming which services an agent knows about rather than retrieving a check's failure detail.
B
/v1/agent/self
Why it fails: The agent/self endpoint returns the local agent's configuration and member details, not the status or output of registered health checks. It is tempting because it exposes agent-level diagnostics, and would be correct when verifying datacenter, ACL tokens or agent version rather than reading a check's error message.
C
/v1/catalog/nodes
Why it fails: The catalog endpoint returns registered nodes and their service mappings, but no health-check output or error text. It is tempting because it lists node-level information, and would be the right call when auditing which nodes are registered or checking node metadata rather than diagnosing a failing check.
D
/v1/health/checks/<service>
The /v1/health/checks/<service> endpoint returns each check's status plus its Output field, which carries the exact error text the check script produced. That message pinpoints why the check is failing, unlike the aggregated node or service health endpoints.

Full breakdown with real-world context →

These Consul 1.15 practice questions are part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style Consul 1.15 questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.