Reinforce Consul 1.15 concepts with active-recall study cards covering all 5 blueprint domains. Each card shows the question on the front and the correct answer with a full explanation on the back.
Flashcards work through active recall — the process of retrieving information from memory rather than passively re-reading it. Research consistently shows that active recall produces stronger, longer-lasting memory than re-reading study guides. For Consul 1.15 preparation, this means flashcards are one of the highest-return study tools available.
Attempt recall first
Read the Consul 1.15 question on each card, pause, and attempt to formulate the answer in your own words before revealing. This retrieval attempt — even if wrong — dramatically strengthens memory compared to immediately reading the answer.
Review wrong cards again
When you get a card wrong, note it and add it back to your review pile. Spaced repetition — seeing difficult cards more frequently — is the mechanism that makes flashcard study far more efficient than linear reading.
Study by domain
Group your Consul 1.15 flashcard sessions by domain for the first 3–4 weeks. Master one domain before moving to the next. In the final week, shuffle all cards together to test cross-domain recall — which is what the real Consul 1.15 exam requires.
Short sessions beat marathon reviews
20–30 flashcard cards per session, done daily, produces better retention than a single 200-card marathon session. Five short daily sessions per week over 4 weeks gives you over 400 total card reviews — enough to reliably pass Consul 1.15.
Sample cards from the Consul 1.15 flashcard bank. Read the question, think of the answer, then read the explanation below.
You have a service that requires specific routing logic based on the environment. How can you distinguish between 'production' and 'staging' instances of the same service name using metadata?
Apply 'production' or 'staging' tags to the service definition.
Consul tags are arbitrary key-value-like labels attached to a service registration and are the standard mechanism for distinguishing instances of the same service across environments. By registering production instances with the tag 'production' and staging instances with 'staging', you can use service discovery queries (e.g., via DNS SRV or the HTTP API with tag filters) to route traffic to the correct environment. This preserves a single service name while enabling environment-aware routing.
Which protocol do Consul servers use to maintain the WAN gossip pool?
Serf (SWIM)
Consul servers use the Serf library, which implements the SWIM gossip protocol, to maintain the WAN gossip pool across datacenters. Serf handles membership, failure detection, and lightweight message dissemination over UDP/TCP. This is distinct from Raft, which handles consensus for the replicated state.
You are monitoring service health using Consul and want to ensure that a service is automatically removed from the catalog if it remains in a 'critical' state for more than 24 hours. Which configuration key supports this?
deregister_critical_service_after
The deregister_critical_service_after setting in a Consul service definition tells Consul to automatically deregister a service instance if its health check remains in the critical state for longer than the specified duration (e.g., '24h'). This is exactly the built-in mechanism for automatic removal of persistently unhealthy services.
What does the 'kind' field in a service definition specify for a Consul Connect service?
The proxy type (e.g., 'connect-proxy').
In a Consul Connect service definition, the `kind` field declares the type of service registration — most commonly `connect-proxy` for a sidecar proxy, but also `connect-native`, `terminating-gateway`, `ingress-gateway`, and `mesh-gateway`. It tells Consul how to treat the service in the service mesh, not what version or language it is. This is required for proxies and gateways so Consul can wire them into the mesh correctly.
When using the Consul KV store, what is the maximum size allowed for a single value in a key?
512 KB
The Consul KV store enforces a maximum value size of 512 KB per key. This limit is a hard constraint imposed by the Raft consensus protocol, which replicates all writes across the cluster. Values larger than 512 KB are rejected by the server to prevent excessive memory usage and network overhead during replication. This is documented in the official Consul limits and is consistent across versions, including 1.15.
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?
The service is critical; it will be deregistered after 10 minutes.
TTL health checks require periodic updates from the service. If no update is received within the TTL period, the check becomes critical. The 'DeregisterCriticalServiceAfter' field, when set, schedules deregistration of the service instance after the check has been critical for the specified duration. In this case, after 90 seconds the check is critical, and after 10 minutes of being critical, the service is deregistered.
A platform team operates two Consul datacenters, dc1 (primary) and dc2 (secondary), with ACLs enabled. They have configured token replication using a replication token in dc2. After rotating the replication token in dc1, they update the configuration in dc2 and restart the Consul agents. However, ACL replication stops working and dc2 logs show 'Permission denied'. What is the most likely cause?
The new replication token must be created in the primary datacenter and have read permissions on ACLs, then configured in dc2.
ACL token replication in Consul allows secondary datacenters to mirror ACL data from the primary. The replication token must be created in the primary datacenter with read permissions on ACL resources. After rotating the token, the old token becomes invalid, leading to permission errors in the secondary. Updating the secondary's configuration with a valid token from the primary restores replication.
If a KV operation returns a 403 Forbidden status, what is the most common cause?
The ACL token lacks sufficient permissions.
A 403 Forbidden response from Consul's HTTP API indicates the request was authenticated but the associated ACL token does not have the required policy permissions for the target resource. Consul returns 403 specifically when an ACL is enforced and the token lacks the necessary 'read', 'write', or 'list' capability on the KV prefix being accessed. This is distinct from 401 (missing/invalid token) and 404 (key not found).
You have a Consul 1.15 cluster with two datacenters, dc1 and dc2, federated via WAN gossip. You want to use a prepared query to automatically failover to a service in dc2 if the service in dc1 becomes unhealthy. Which configuration in the prepared query is required to achieve this?
A `Failover` block with `Datacenters` set to `["dc2"]`.
Prepared queries support a `Failover` block that can list datacenters to try when local instances are unhealthy. By setting `Datacenters` to `["dc2"]`, the query will automatically attempt to find healthy instances in dc2 if none are available in the local datacenter. This is the standard method for cross-datacenter failover in Consul. Other options either misuse fields or do not provide the required failover behavior.
You are using Consul 1.15 with Connect enabled. A service 'web' needs to communicate with an upstream service 'api' in a different datacenter. You have configured a mesh gateway in each datacenter. The 'web' service's sidecar proxy is configured with an upstream for 'api'. However, traffic is failing. You check the sidecar proxy logs and see 'no healthy upstream'. What is the most likely cause?
The upstream service 'api' is not registered in the remote datacenter or has no healthy instances.
The error 'no healthy upstream' means the sidecar proxy cannot find any healthy instances of the upstream service. In a cross-datacenter setup with mesh gateways, this typically occurs when the upstream service is not registered or has no healthy instances in the remote datacenter. Other issues like missing gateway registration or deny intentions would produce different errors.
A service has a TTL check configured with a 30-second TTL. If the application crashes and stops sending heartbeats, when will the service status change to 'critical'?
After 30 seconds
A TTL check in Consul marks the service as critical when the TTL interval elapses without a heartbeat update. Since the TTL is set to 30 seconds, the check will transition to critical exactly 30 seconds after the last successful heartbeat. The application crashing means no further heartbeats are sent, so the timer expires and Consul updates the service status to critical.
You are deploying a Consul Connect service mesh in a single datacenter. A developer asks how service-to-service authorization is enforced when two services communicate through their sidecar proxies. What is the primary mechanism that controls whether the connection is allowed?
Consul intentions define whether a connection between a source and destination service is permitted.
Consul intentions are the authorization mechanism in Consul Connect. They evaluate the source service identity against the destination service and determine whether the connection is allowed. While mTLS provides authentication and encryption, it is the intention that enforces authorization. Network ACLs and static proxy configurations do not fulfill this role. Therefore, intentions are the correct answer.
An operator writes a feature flag to `app/features/new-ui` using `consul kv put app/features/new-ui true`. Later, a health-check script reads that key and receives an error instead of the value. The operator confirms the key exists with `consul kv get app/features/new-ui`. Which command should the operator run to inspect the metadata that would reveal a problem such as a missing or expired session on the key?
consul kv get -detailed app/features/new-ui
Metadata such as the attached session and lock index is only exposed when the detailed view is requested. A key can be readable while still being held by a session, and a health script that attempts to acquire the lock will fail in that case. Requesting the detailed output surfaces the session identifier needed to investigate further.
You need to perform a write operation to the Consul KV store that only succeeds if the current ModifyIndex of the key is zero. Which parameter should you include in your API call?
cas=0
The Consul KV write API supports a 'cas' (Check-And-Set) parameter that performs an atomic compare-and-swap against the key's ModifyIndex. Setting cas=0 means the write only succeeds if the key does not currently exist (ModifyIndex is zero), which is the standard way to implement create-if-not-exists semantics.
What is the purpose of the 'datacenter' field in the Consul agent configuration?
To segment the cluster into logical datacenters.
The 'datacenter' field in the Consul agent configuration assigns the agent to a named logical datacenter, which segments the cluster into independent failure domains. Each datacenter has its own LAN gossip pool, its own Raft consensus group of servers, and its own catalog and KV store. Agents in different datacenters communicate only through the WAN gossip pool and cross-datacenter RPC, not through the LAN pool.
You observe a 'warning' status for a service. What is the most common reason for this?
The service is operating but with performance issues
In Consul, a 'warning' status means the check is returning a warning result — typically the service is up and responding but is degraded or experiencing performance issues. This is distinct from 'critical', which indicates failure. The most common cause of warning is a service that is operational but not fully healthy.
Which of the following is a valid method to update a TTL health check?
HTTP PUT to the /agent/check/pass endpoint
TTL checks are updated by calling the Consul HTTP API's agent check endpoints — specifically an HTTP PUT to /v1/agent/check/pass/<check_id> (or /warn and /fail) — which resets the TTL timer and marks the check healthy. This is the canonical heartbeat mechanism for TTL checks.
You need to retrieve the session information for a specific session ID. Which endpoint should you query?
/v1/session/info/:id
The Consul HTTP API exposes session information through the /v1/session/info/:id endpoint, which returns the full session object (ID, node, checks, behavior, TTL, lock-delay) for the specified UUID. This is the documented read endpoint for a single session, distinct from /v1/session/list (all sessions) and /v1/session/node/:node (sessions on a node).
Which status indicates that a health check is successfully passing according to Consul?
passing
In Consul, a health check status of 'passing' means the check is succeeding — the service is healthy according to that check. This is the positive status that indicates the check's success condition is met, whether it's an HTTP 200, a script exit code 0, or a TTL being renewed.
An operator registers a web service with Consul using the HTTP API. The registration includes a TTL health check with a 30-second interval, but the application code does not yet call the pass endpoint. Shortly after registration, the service disappears from healthy DNS results. What is the most likely reason?
The TTL check entered the critical state because no pass heartbeat was received before the TTL expired.
TTL checks require the service to actively report health by calling the pass endpoint within the configured TTL. Until that heartbeat arrives, Consul considers the check critical and omits the instance from healthy DNS responses. The described behavior is the expected outcome of a TTL check that was registered but never fed, so the fix is to implement the heartbeat or use an active check type.
A Consul cluster spans multiple datacenters. A service `user-auth` is registered in both `dc1` and `dc2`. A client in `dc1` queries the DNS interface for `user-auth.service.consul`. By default, which instances will be returned?
Only instances from `dc1`.
By default, Consul DNS queries are limited to the local datacenter of the agent that receives the query. A client in `dc1` querying `user-auth.service.consul` will only get instances from `dc1`. To discover instances in other datacenters, the query must explicitly include the datacenter, such as `user-auth.service.dc2.consul`. This design promotes locality and avoids unintended cross-datacenter traffic.
Which command is used to check the status of a registered service?
consul health service
The 'consul health service' command queries the health of all instances of a named service, returning the nodes, their health check statuses, and associated metadata. It is the standard CLI way to inspect whether a registered service is passing its checks and is reachable through the catalog.
The Consul 1.15 flashcard bank covers all 5 official blueprint domains published by HashiCorp. Cards are distributed proportionally, so domains with higher exam weight have more cards.
Domain Coverage
Service Discovery
Multi Datacenter Federation
Health Checking
Service Mesh With Consul Connect
Key Value Store
Both flashcards and practice questions are evidence-based study tools. The difference is in what they train:
Flashcards — concept retention
Best for memorising definitions, acronyms, protocol behaviours, command syntax, and conceptual distinctions. Use flashcards to build the foundational vocabulary that Consul 1.15 questions assume you know.
Best in: weeks 1–3
Practice tests — application
Best for applying concepts to realistic scenarios, eliminating distractors, and building exam stamina.Consul 1.15 questions test scenario reasoning — not just recall — so practice tests are essential.
Best in: weeks 3–6
The most effective Consul 1.15 study plan combines both: use flashcards for the first 2–3 weeks to build conceptual foundations, then shift to practice tests and mock exams in the final 2–3 weeks to apply and benchmark that knowledge. Most candidates who pass on their first attempt use both tools.
Yes. Courseiva provides free Consul 1.15 flashcards across all official exam domains. Every card includes the correct answer and a full explanation of why it is right and why the distractors are wrong. The platform also includes topic-based practice, mock exams, and readiness tracking — no account required.
Courseiva has 265+ original Consul 1.15 flashcards across all 5 exam blueprint domains. New cards are added regularly as the question bank grows. All cards are checked against the official HashiCorp exam objectives, with editorial oversight from an experienced network and security engineer.
Courseiva flashcards are purpose-built for IT certification exams. Unlike generic flashcard platforms where content quality varies, every Courseiva card is mapped to the official Consul 1.15 exam blueprint, written by engineers who hold the certification, and includes a full explanation of the correct answer and why the distractors are wrong. This explanation quality is what separates genuine learning from rote memorisation.
Courseiva is a web platform — an internet connection is required. For offline study, we recommend creating free Courseiva account, using the platform in your browser, and using your device's offline capabilities if your browser supports offline web apps.
Save your results, see which domains need more work, and get spaced repetition recommendations — all free.
Sign Up FreeFree forever · Every certification included