Knowledge + Practice

CCNA Service Discovery Questions

43 questions · Service Discovery topic · All types, answers revealed

Practice these questions Exam hub All questions

1

MCQeasy

Which interface would you use to register a service dynamically using standard tools like 'curl'?

A.HTTP API

B.DNS interface

C.Gossip protocol

D.CLI agent command

AnswerA

The HTTP API exposes REST endpoints that accept service definitions via PUT requests, so standard tools like curl can register services without installing the Consul CLI or agents. This directly satisfies the stem's requirement for dynamic registration using generic HTTP clients rather than Consul-specific tooling.

Why this answer

The HTTP API is the primary programmatic interface for Consul and exposes RESTful endpoints such as PUT /v1/agent/service/register, which can be invoked with standard tools like curl. This makes it the correct choice for dynamically registering a service without using the CLI or configuration files. The DNS interface is read-only for service discovery, and gossip is an internal membership protocol, not a registration mechanism.

Exam trap

The trap here is confusing the DNS interface (read-only discovery) with the HTTP API (read-write management), leading candidates to pick DNS because it is a familiar Consul feature.

How to eliminate wrong answers

Option B is wrong because the DNS interface only resolves service names to IP addresses and cannot register or modify services. Option C is wrong because the gossip protocol is used for Serf-based cluster membership and failure detection, not for service registration. Option D is wrong because the CLI agent command (e.g., consul services register) is a wrapper around the HTTP API and is not the interface itself; the question asks for the interface usable with standard tools like curl.

Practice this question →

2

Multi-Selectmedium

A DevOps engineer is configuring a Consul service `payment-processor` that must be discoverable only when its health check is passing. The service is registered with a script health check that runs every 10 seconds. The engineer wants to ensure that DNS queries for `payment-processor` return only healthy instances. Which two actions should the engineer take? (Choose two.)

Select 2 answers

A.Include the `passing` parameter in the DNS query.

B.Use the `?near` parameter in the DNS query to prioritize local instances.

C.Set the `"status": "passing"` field in the service registration.

D.Register the service with a health check that is associated with the service.

E.Configure the service with `"enable_tag_override": true`.

AnswersA, D

The `passing` parameter in a DNS query explicitly filters results to only instances with passing health checks. For `payment-processor`, using `payment-processor.service.consul?passing` ensures that only healthy instances are returned. This is a direct way to enforce health-based filtering in DNS queries, which is exactly what the engineer needs.

Why this answer

To ensure DNS queries return only healthy instances of `payment-processor`, the service must have an associated health check, and the DNS query must include the `passing` parameter. The health check association allows Consul to track the service's health, while the `passing` parameter filters results to only passing instances. Together, these actions guarantee that only healthy instances are discoverable via DNS.

Exam trap

The trap here is assuming that simply registering a health check is enough, or that other parameters like `near` or `enable_tag_override` affect health filtering, when in fact the `passing` parameter and proper health check association are required.

Practice this question →

3

MCQmedium

A Consul operator observes that a web service registered on two nodes is only reachable through the DNS interface on one node. The service definition on both nodes is identical, including the same service name and port. What is the most likely cause?

A.The node that is not returning results has not been configured with the correct datacenter.

B.The service definition is missing the 'tags' field, causing the DNS query to return only one instance.

C.The DNS interface requires the 'passing' parameter to be set to true to return all instances.

D.The service on the unreachable node is failing its health check, so it is excluded from DNS results.

AnswerD

Consul's DNS interface by default returns only healthy instances of a service. If the health check on one node's service is failing, that instance is omitted from DNS responses. This is the most common reason for a service appearing on one node but not another when definitions are identical. The operator should verify the health check status using the HTTP API or Consul UI.

Why this answer

Consul's DNS interface only returns service instances that are passing their health checks. When two identical service definitions exist but only one appears in DNS results, the most probable cause is that the other instance is failing its health check. The operator should inspect the health check status for that service instance using the Consul UI or the /health/service API endpoint.

Exam trap

The trap here is assuming that identical service definitions guarantee both instances are healthy and discoverable, overlooking the impact of health check status on DNS results.

Practice this question →

4

MCQmedium

You need to register a health check that triggers an alert when memory usage is high. Which type of check is most appropriate?

A.gRPC Check

B.HTTP Check

C.Script Check

D.TCP Check

AnswerC

A script check runs an external command on the node and evaluates its exit code, so a script reading memory usage can return non-zero when a threshold is exceeded. This suits alerting on high memory, unlike TCP or HTTP checks.

Why this answer

A Script check runs an arbitrary executable on the Consul client at a defined interval and interprets its exit code (0 = passing, 1 = warning, other = critical), making it the only check type that can inspect local system metrics like memory usage. HTTP, TCP, and gRPC checks only verify reachability or protocol-level responses and cannot read OS-level resource counters.

Exam trap

Consul 1.15 often tests check-type selection by describing a metric (memory, disk, CPU) that only a Script check can observe — the trap is picking HTTP or TCP because they sound more 'standard' or 'lightweight'.

How to eliminate wrong answers

Option A is wrong because a gRPC check only performs a gRPC health-check probe against a service endpoint; it has no visibility into host memory. Option B is wrong because an HTTP check merely issues a GET and evaluates the status code or body match — it cannot measure memory. Option D is wrong because a TCP check only confirms a socket can be opened on a port, which says nothing about resource consumption.

Practice this question →

5

MCQmedium

A Consul operator is using the HTTP API to register a web service with an external health check script. The operator wants to ensure that if the service process fails but the node remains up, the service is marked unhealthy and removed from DNS query results. Which of the following API endpoints should the operator use to register the service and its check together?

A.PUT /v1/agent/service/deregister

B.PUT /v1/agent/service/register

C.PUT /v1/catalog/register

D.PUT /v1/agent/check/register

AnswerB

This endpoint registers a service with the local agent and allows including a check definition in the same payload. The check can be an external script that the agent executes periodically. If the script fails, the service is marked critical, and DNS queries will not return it. This is the correct way to atomically register a service and its health check.

Why this answer

The agent service register endpoint accepts a JSON payload that can include both the service definition and an associated check. This allows the agent to manage the check and update the service's health status. When the external script fails, the check becomes critical, and the service is excluded from DNS results.

Other endpoints either register checks separately or bypass the agent's health monitoring.

Exam trap

The trap here is assuming that any registration endpoint can associate a check with a service, but only the agent service register endpoint allows atomic registration of both.

Practice this question →

6

MCQmedium

A service definition includes a 'meta' block. What is the intended use of this block?

A.To configure service discovery timeouts.

B.To define arbitrary key/value metadata for the service.

C.To override the default health check interval.

D.To store authentication credentials.

AnswerB

The meta block stores arbitrary user-defined key/value pairs attached to a service, such as version, owner or environment labels. It is purely descriptive metadata, not configuration, and does not affect health checking, routing or service discovery behaviour.

Why this answer

The 'meta' block in a service definition is used to define arbitrary key/value metadata for the service. This metadata is not used by Consul for routing or health checks but can be used by external tools, for filtering in the UI, or for custom logic in service discovery. It is a flexible way to attach additional information to a service.

Exam trap

Consul 1.15 often tests the purpose of the 'meta' block versus 'tags' or 'check' settings; candidates may incorrectly assume it configures timeouts or health checks.

How to eliminate wrong answers

Option A is wrong because service discovery timeouts are configured via DNS or agent settings, not the 'meta' block. Option C is wrong because health check intervals are defined in the 'check' block, not 'meta'. Option D is wrong because storing authentication credentials in 'meta' is insecure and not the intended use; Consul provides ACLs and Connect for security.

Practice this question →

7

MCQhard

A Consul cluster has three server nodes and multiple client agents. A service 'db' is registered on two nodes, each with a health check that includes 'DeregisterCriticalServiceAfter' set to '1h'. One of the nodes experiences a network partition and becomes unreachable. After 2 hours, the node rejoins the cluster. What happens to the service instance on that node?

A.The service instance is deregistered after 1 hour of the check being critical, even if the node is still unreachable.

B.The service instance is only deregistered if the node is permanently removed from the cluster.

C.The service instance remains registered indefinitely because the node is part of the Consul cluster.

D.The service instance is immediately deregistered when the node becomes unreachable.

AnswerA

The 'DeregisterCriticalServiceAfter' field on the health check causes Consul to deregister the service instance if the check remains critical for the specified duration. Once the node becomes unreachable, the check will eventually be marked critical (after the check interval and timeout). After 1 hour of critical status, Consul will deregister the service instance, regardless of whether the node has rejoined. When the node rejoins, it will re-register the service if it is still configured to do so.

Why this answer

When a node becomes unreachable, the health check for the service will eventually be marked critical. With 'DeregisterCriticalServiceAfter' set to 1h, Consul will deregister the service instance after it has been critical for that duration. This happens even if the node is still partitioned.

When the node rejoins, if the service is still running and registered with the local Consul agent, it may be re-registered. The other options are incorrect because they misstate the timing or conditions for deregistration.

Exam trap

The trap here is thinking that a node rejoining the cluster prevents deregistration, when the timer is based solely on the check's critical duration.

Practice this question →

8

Multi-Selecteasy

Which THREE of the following are valid check types in Consul?

Select 3 answers

D.Script

AnswersA, B, D

A TCP check opens a socket to the registered address and port, succeeding only if the connection completes. This satisfies the stem by being a genuine Consul check type, distinct from script-based checks that execute local commands and report status via exit codes.

Why this answer

Consul supports HTTP, TCP, and Script (external) health checks.

Practice this question →

9

MCQmedium

You need to verify if a node has successfully joined the cluster for service discovery. Which tool confirms this?

A.consul members

B.consul catalog nodes

C.consul info

D.consul services

AnswerA

The consul members command queries the gossip protocol on the local agent and returns every node the cluster currently recognises, along with its status and role. A node appearing in this output confirms it has successfully joined and is participating in service discovery.

Why this answer

The `consul members` command queries the gossip protocol (LAN/WAN) and lists all nodes that are currently part of the Consul cluster, showing their status (alive, left, failed) and role. This directly confirms whether a node has successfully joined the cluster, as it relies on the Serf gossip layer that manages cluster membership. Other commands like `consul catalog nodes` query the catalog, which may not reflect real-time membership status if the node is unreachable or has not synced.

Exam trap

Consul 1.15 often tests the distinction between gossip membership (real-time) and catalog data (eventually consistent), so candidates may incorrectly choose `consul catalog nodes` thinking it shows live cluster members.

How to eliminate wrong answers

Option B is wrong because `consul catalog nodes` returns nodes registered in the Consul catalog, which is populated by the anti-entropy sync and may include nodes that are not currently active or have failed, so it does not confirm live membership. Option C is wrong because `consul info` provides runtime metrics and configuration details about the local agent, not a list of cluster members. Option D is wrong because `consul services` lists services registered in the catalog, not nodes, and does not indicate whether a specific node has joined the cluster.

Practice this question →

10

Multi-Selecthard

Which THREE of the following are valid ways to register a service in Consul?

Select 3 answers

A.Kubernetes Custom Resource Definitions.

B.Configuration files in the agent's config directory.

C.HTTP API 'v1/agent/service/register'.

D.Directly modifying the Consul database file.

E.Manual editing of the Raft log.

AnswersA, B, C

The Consul Kubernetes controller watches Kubernetes Custom Resource Definitions such as ServiceDefaults and ServiceResolver, syncing them into Consul's catalog. This makes CRDs a supported registration path in Kubernetes environments, alongside agent config and the HTTP API.

Why this answer

Option A is correct because Consul supports Kubernetes Custom Resource Definitions (CRDs) such as ServiceRegistration (and previously ServiceDefaults/ServiceResolver via CRDs) as a declarative way to register services when running Consul on Kubernetes with the official Helm chart and CRDs enabled. Option B is correct because services can be defined in agent configuration files (HCL or JSON) placed in the agent's config directory, using a service block or services array, and Consul loads them at agent startup or reload. Option C is correct because the Consul HTTP API exposes the endpoint PUT /v1/agent/service/register, which accepts a JSON service definition and registers the service with the local agent.

Option D is not valid because Consul stores state in a Raft-replicated log and snapshot files, not in a directly editable database file; modifying internals would corrupt state and is unsupported. Option E is not valid because the Raft log is an internal replicated log managed by the Raft consensus protocol, and manually editing it would break consistency and is not a supported registration method.

Exam trap

The trap is including plausible-sounding but unsupported methods like editing the database or Raft log; candidates must recognize that Consul only accepts registration through agents, the HTTP API, or Kubernetes CRDs — never direct datastore manipulation.

Practice this question →

11

MCQhard

What is the impact of setting 'enable_tag_override' to true in a service definition?

A.It allows tags to be modified via the API without updating the config file.

B.It ignores all tags in the catalog.

C.It forces all nodes to update their tags.

D.It prevents tags from being used in DNS lookups.

AnswerA

Tag override decouples tags from the service definition's configuration file, permitting registration or catalog updates to alter them through the API. Without it, any tag change requires editing and reloading the config, so this setting enables API-driven tag modification.

Why this answer

Setting 'enable_tag_override' to true in a service definition allows tags to be modified via the API without updating the service's configuration file. This is useful for dynamic tag changes, such as adding a tag for maintenance mode. By default, this is false, meaning tags are managed by the config file and API changes are overwritten on restart.

Exam trap

Consul 1.15 often tests the misconception that 'enable_tag_override' affects all nodes or disables tags, when it actually allows per-instance API tag modifications.

How to eliminate wrong answers

Option B is wrong because 'enable_tag_override' does not ignore tags in the catalog; it allows API overrides. Option C is wrong because it does not force all nodes to update their tags; it only permits API modifications. Option D is wrong because it does not prevent tags from being used in DNS lookups; tags are still used for filtering.

Practice this question →

12

MCQhard

When using Consul DNS for a service, what happens if no instances are healthy?

A.It returns a 500 error.

B.It redirects to a standby service.

C.It returns an empty response (NXDOMAIN or empty set).

D.It returns all instances regardless of health.

AnswerC

Consul DNS suppresses unhealthy instances from service lookups, so when every instance fails its health check, the query yields no records — NXDOMAIN or an empty answer set — rather than stale addresses. This satisfies the stem's requirement by preventing clients from receiving unreachable endpoints, letting them fail fast instead of timing out.

Why this answer

Consul DNS returns only healthy service instances. If no instances are healthy, the query returns an empty response — typically NXDOMAIN for the service name or an empty answer set — rather than an error or unhealthy instances. This signals to clients that no healthy backend is available.

Exam trap

Consul 1.15 often tests the misconception that Consul DNS returns all instances or an error code, when it actually returns an empty/NXDOMAIN response for no healthy instances.

How to eliminate wrong answers

Option A is wrong because DNS does not return HTTP 500 errors; Consul DNS returns DNS response codes such as NXDOMAIN or NOERROR with no records. Option B is wrong because Consul has no built-in standby service redirection; failover must be implemented by the client or via prepared queries. Option D is wrong because Consul deliberately filters out unhealthy instances; returning all instances regardless of health would defeat the purpose of health-aware discovery.

Practice this question →

13

Multi-Selectmedium

Which TWO of the following are true regarding the Consul Service Catalog?

Select 2 answers

A.It provides a unified view of all services in the cluster.

B.It is replicated across the cluster using Raft.

C.It is strictly read-only.

D.It is only accessible via the CLI.

E.It is stored in the local disk of every agent.

AnswersA, B

The catalog is the source of truth.

Why this answer

The catalog is replicated via Raft and can be queried via API or DNS.

Practice this question →

14

MCQhard

When a service check transitions to 'critical', what does Consul do with the service's DNS entry?

A.It marks the record as 'stale'.

B.It removes the instance from the DNS response.

C.It returns the IP but with a low TTL.

D.It returns a 503 status code.

AnswerB

Consul's DNS interface only returns instances whose health checks are passing. A check transitioning to critical marks the instance unhealthy, so it is omitted from the service's DNS response, preventing clients from resolving to the failed node.

Why this answer

When a service check transitions to 'critical', Consul's DNS interface automatically removes that service instance from DNS query results. This is because Consul's DNS server only returns instances that are considered healthy (passing checks). The DNS entry for the service as a whole may still exist if other instances are healthy, but the critical instance is excluded.

This behavior ensures that clients using DNS for service discovery do not route traffic to unhealthy instances.

Exam trap

The trap here is confusing Consul's DNS behavior with HTTP API behavior or assuming that DNS can convey health status via TTL or status codes; candidates might think Consul returns the IP with a low TTL to indicate issues, but it actually removes the instance entirely.

How to eliminate wrong answers

Option A is wrong because Consul does not mark DNS records as 'stale'; staleness in Consul refers to potentially outdated information due to network partitions or stale reads, not to health status. Option C is wrong because Consul does not return the IP with a low TTL for critical services; it removes the instance entirely from DNS responses. Option D is wrong because DNS does not use HTTP status codes like 503; Consul's DNS interface returns standard DNS responses (e.g., NXDOMAIN or empty answer sections) and does not include HTTP status codes.

Practice this question →

15

MCQmedium

An operator wants to query the Consul catalog for all nodes that provide a service named `api` in the `us-east` datacenter. They need to retrieve the node names and addresses. Which Consul HTTP API endpoint should they use?

A.`GET /v1/agent/services`

B.`GET /v1/catalog/nodes?dc=us-east`

C.`GET /v1/health/service/api?dc=us-east`

D.`GET /v1/catalog/service/api?dc=us-east`

AnswerD

The `/v1/catalog/service/:service` endpoint returns the nodes and service instances for a given service. Adding `?dc=us-east` specifies the datacenter. The response includes node names, addresses, and service details. This is the correct endpoint to retrieve all nodes providing the `api` service in the specified datacenter.

Why this answer

The `/v1/catalog/service/:service` endpoint is designed to return all nodes and service instances for a specific service, optionally filtered by datacenter using the `dc` parameter. The health endpoint is more focused on health status, while the nodes endpoint lists all nodes. The agent services endpoint is local only.

Exam trap

The trap here is confusing the catalog service endpoint with the health service endpoint, which also returns node information but is filtered by health status.

Practice this question →

16

MCQmedium

A developer runs `dig @127.0.0.1 -p 8600 web.service.consul SRV` and receives no records, even though `consul catalog services` lists `web` and `consul members` shows the node as alive. A health check for the `web` service is registered and currently shows a critical status. What is the most likely cause of the empty SRV response?

A.The Consul DNS interface only returns records for services that have at least one passing health check.

B.The DNS query must use the `ANY` type to return SRV records for services with critical checks.

C.The SRV record requires a `tcp` prefix in the query, such as `_tcp.web.service.consul`.

D.The `web` service is registered in a different datacenter, so the local DNS server cannot resolve it.

AnswerA

Consul's DNS interface filters out service instances whose health checks are not passing. Since the `web` service check is critical, no healthy instances exist, so the SRV query returns no records. This is expected behavior and explains why the service appears in the catalog but not in DNS results.

Why this answer

Consul's DNS interface only returns records for service instances that have at least one passing health check. When the `web` service check is critical, Consul considers the instance unhealthy and omits it from DNS responses. This behavior ensures that clients only discover healthy endpoints, which is a core feature of Consul's service discovery.

Exam trap

The trap here is assuming that a service listed in the catalog will always appear in DNS results, forgetting that health status filters DNS responses.

Practice this question →

17

Multi-Selecteasy

Which TWO of the following are standard DNS records returned by Consul for service discovery?

Select 2 answers

A.NS

B.SRV

C.A

D.SOA

E.PTR

AnswersB, C

SRV records expose both host and port for a service, plus priority and weight for selection. Consul returns them so clients can discover not just where a service runs but on which port, satisfying the stem's service discovery requirement.

Why this answer

Consul's DNS interface returns SRV records (option B) to advertise the port and target host of a registered service instance, which is essential because service discovery must convey both the address and the port the service listens on. Consul also returns A records (option C) that map a service name to the IP address(es) of the healthy instances, allowing clients to resolve a service directly to an IP. These two record types are the core of Consul's service discovery responses, with SRV providing host+port and A providing the IPv4 address.

The other options are standard DNS record types but are not the service-discovery answers Consul returns for a service lookup: NS (option A) delegates zones to name servers, SOA (option D) holds zone authority metadata, and PTR (option E) is used for reverse DNS lookups.

Exam trap

Consul 1.15 often tests the distinction between DNS record types used for service discovery versus those used for zone administration or reverse lookups, causing candidates to confuse SRV and A records with NS, SOA, or PTR records.

Practice this question →

18

MCQmedium

When multiple agents are in a cluster, how does Consul ensure that service discovery information is consistent across all nodes?

A.Using a centralized database like PostgreSQL.

B.By polling the leader every second.

C.Via the Raft consensus protocol for catalog changes.

D.By broadcasting all service updates to every node.

AnswerC

Catalog changes are replicated through the Raft consensus protocol, which elects a leader and commits entries only once a quorum of servers acknowledges them. This guarantees all nodes converge on identical service discovery data despite concurrent writes or failures.

Why this answer

Consul uses the Raft consensus protocol to replicate catalog changes across server nodes, ensuring that service discovery information is consistent and fault-tolerant. Raft elects a leader that handles writes and replicates log entries to followers, guaranteeing that all servers converge on the same state. This is how Consul maintains a consistent service catalog across the cluster.

Exam trap

The trap is confusing Consul's internal consistency mechanism (Raft) with external databases or gossip-based broadcast; candidates must know that Raft handles catalog consistency while gossip handles membership.

How to eliminate wrong answers

Option A is wrong because Consul does not rely on an external centralized database like PostgreSQL; it uses its own embedded Raft-based state store. Option B is wrong because polling the leader every second is not how Consul achieves consistency; it uses log replication, not polling. Option D is wrong because broadcasting updates to every node is not the mechanism; Raft replicates through the leader to followers in an ordered log, not via broadcast.

Practice this question →

19

MCQmedium

A platform engineer is adding a new service to Consul. The service must appear in the catalog with the name 'billing', be reachable over DNS at billing.service.consul, and be associated with the tag 'prod'. Which registration block correctly achieves this when using the HTTP API?

A.{"Service": "billing", "Tag": "prod", "IP": "10.0.0.5", "Port": 8080}

B.{"Name": "billing", "Tags": "prod", "Address": "10.0.0.5", "Port": 8080}

C.{"Name": "billing", "Tags": ["prod"], "Host": "10.0.0.5", "Port": 8080}

D.{"Name": "billing", "Tags": ["prod"], "Address": "10.0.0.5", "Port": 8080}

AnswerD

The /v1/agent/service/register endpoint accepts a JSON body where Name sets the catalog service name, Tags is an array of strings, and Address/Port define the reachable endpoint. Consul uses Name to build billing.service.consul and exposes the tags for filtering. This body registers the service on the local agent, making it discoverable via DNS and catalog queries immediately.

Why this answer

The agent service registration API requires a JSON object with Name for the catalog service identifier, Tags as an array of strings, and Address plus Port for the reachable endpoint. That combination makes the service resolvable at billing.service.consul and allows tag-based filtering such as prod. Any deviation in field naming or tag type causes registration failure or missing discovery data.

Exam trap

The trap here is assuming the registration JSON accepts singular or alternative field names like Service, Tag, or Host instead of the exact Consul schema fields Name, Tags, and Address.

Practice this question →

20

MCQhard

A Consul operator needs to deregister a specific service instance named 'web-01' from a node without affecting other instances of the same service. The service was registered with the ID 'web-01'. Which action accomplishes this?

A.Run consul services deregister -id=web-01

B.Send a PUT request to /v1/agent/service/deregister with the service name 'web' in the body

C.Send a PUT request to /v1/catalog/deregister with the service name 'web'

D.Send a PUT request to /v1/agent/service/deregister/web-01

AnswerD

The agent service deregister endpoint accepts the service ID in the path and removes only that instance from the local agent and catalog. Because web-01 is the unique service ID, other instances remain registered. This is the precise, targeted way to remove a single instance without impacting the rest of the service's endpoints.

Why this answer

Deregistering a single instance requires the unique service ID, which is web-01. The agent endpoint /v1/agent/service/deregister/<serviceID> removes exactly that instance from the local agent and propagates the change to the catalog. Targeting the service name or using a nonexistent command leaves other instances intact but fails to remove the intended one.

Exam trap

The trap here is confusing the service name with the service ID and assuming that the deregister endpoint accepts a name in the body rather than the unique ID in the URL path.

Practice this question →

21

MCQeasy

A developer needs to register a service named 'api' with Consul and ensure that it is only discoverable by consumers that explicitly request the 'v2' tag. Which Consul feature should be used?

A.Service tags

B.ACLs

C.Health checks

D.Service meta

AnswerA

Service tags are used to attach metadata to a service instance for filtering during discovery. By registering the service with the tag 'v2', consumers can query for 'v2.api.service.consul' to retrieve only instances with that tag. This allows for version-based routing. Tags are not automatically applied; they must be specified in the service definition and can be used in DNS queries or API calls.

Why this answer

Service tags are the correct mechanism to allow consumers to filter service instances by a specific label such as 'v2'. By registering the service with the tag 'v2', the developer enables discovery queries that include that tag to return only the desired instances. This is a common pattern for versioned services or canary deployments.

Exam trap

The trap here is confusing service meta with service tags; meta is for descriptive metadata, while tags are used for filtering in discovery.

Practice this question →

22

Multi-Selecthard

Which TWO of the following statements are true about the 'passing' parameter in DNS queries?

Select 2 answers

A.It requires manual service registration.

B.It returns only services with passing health checks.

C.It forces the DNS server to restart.

D.It is a permanent configuration setting.

E.It can be used in the DNS query URL.

AnswersB, E

The passing parameter filters DNS results to endpoints whose Consul health checks currently report passing status, excluding any critical or warning instances. This satisfies the stem's requirement for returning only services with passing health checks, rather than all registered instances regardless of health.

Why this answer

Option B is correct because the 'passing' parameter filters DNS query results so that only service instances whose health checks are currently passing are returned, which is essential for service discovery in tools like Consul. Option E is correct because 'passing' is appended as a query string parameter in the DNS query URL, for example when querying a service name with ?passing to restrict results to healthy instances. Option A is incorrect because the 'passing' parameter does not require manual service registration; services are registered through the service registry or API, not through this query parameter.

Option C is incorrect because 'passing' is a query-time filter and has no effect on restarting the DNS server. Option D is incorrect because 'passing' is a per-query parameter, not a permanent configuration setting.

Exam trap

The trap is thinking that 'passing' is a permanent setting or requires manual registration, but it's a query parameter for filtering DNS results.

Practice this question →

23

MCQhard

A Consul cluster is used for service discovery across multiple datacenters. A service named 'api' is registered in both datacenter 'dc1' and 'dc2'. A client in 'dc1' needs to discover instances of 'api' in 'dc2' using DNS. Which DNS query format should the client use?

A.api.service.dc2.consul

B.api.service.consul?dc=dc2

C.api.dc2.service.consul

D.api.service.consul.dc2

AnswerA

Consul DNS supports datacenter-specific queries by inserting the datacenter name as a subdomain before 'consul'. The format 'api.service.dc2.consul' resolves to instances of 'api' in 'dc2'. This is the correct way to query a remote datacenter via DNS.

Why this answer

Consul DNS allows querying services in other datacenters by including the datacenter name in the domain. The correct format is '<service>.service.<datacenter>.consul'. For example, 'api.service.dc2.consul' returns instances of 'api' in 'dc2'.

Other formats either misplace the datacenter or use unsupported query parameters. This feature enables cross-datacenter service discovery without direct API calls.

Exam trap

The trap here is assuming that datacenter selection is done via a query parameter or by placing the datacenter in the wrong position in the domain name.

Practice this question →

24

MCQeasy

An administrator needs to query service information. Which DNS record type is commonly used by Consul to return service addresses?

A.TXT

B.MX

C.CNAME

D.SRV

AnswerD

Consul's DNS interface publishes SRV records that carry both the target hostname and the service port, letting clients discover where a service listens. A records return only addresses, so SRV is the record type that answers service-address queries.

Why this answer

Consul's DNS interface primarily uses SRV records to return service addresses because SRV records include both the hostname and the port number of the service instances. This allows clients to discover not just the IP address but also the port on which the service is listening, which is essential for dynamic service discovery. While A records can return IP addresses, they lack port information, making SRV the preferred record type for querying service information in Consul.

Exam trap

The trap here is confusing DNS record types: candidates might think A records are used because they return IP addresses, but Consul specifically uses SRV records to include port information, which is crucial for service discovery.

How to eliminate wrong answers

Option A is wrong because TXT records are used for arbitrary text data, not for returning service addresses; Consul may use TXT records for metadata but not for the primary service address query. Option B is wrong because MX records are for mail exchange servers, which are unrelated to Consul's service discovery. Option C is wrong because CNAME records are used for aliasing one domain name to another, not for returning service addresses with port information; Consul does not use CNAME for service queries.

Practice this question →

25

MCQeasy

What is the purpose of the 'service-tag' in a Consul service definition?

A.To provide additional categorization or versioning for services.

B.To define the physical location of the server.

C.To set the priority of the service in DNS.

D.To encrypt communication between services.

AnswerA

Service tags supply arbitrary metadata labels that Consul exposes through the catalog and DNS interface, enabling categorisation, versioning and filtered queries. This satisfies the stem's requirement to describe the tag's purpose: attaching non-functional identifiers to a service registration for discovery and grouping, rather than configuring health checks or routing behaviour.

Why this answer

Service tags in Consul are arbitrary string labels attached to a service registration that enable additional categorization, versioning, and filtering. They are commonly used with DNS queries (e.g., tag.service.consul) and in prepared queries or Connect intentions to select subsets of service instances. Tags do not affect the service's network location, DNS priority, or encryption.

Exam trap

The trap here is confusing service tags with other service definition fields like address, port, or meta, or assuming tags control DNS priority or encryption.

How to eliminate wrong answers

Option B is wrong because the physical location of a server is defined by the service's address and port fields, not by tags. Option C is wrong because Consul DNS does not use tags to set priority; DNS SRV records may include priority and weight, but these are separate fields in the service definition, not tags. Option D is wrong because encryption between services is handled by Consul Connect (mTLS) and is unrelated to service tags.

Practice this question →

26

MCQhard

A service is intermittently failing to resolve via DNS because it has multiple health checks, some of which are 'warning'. How do you ensure it is only returned when all checks are 'passing'?

A.Configure 'service_prefix' in DNS settings.

B.Use the 'stale' query parameter.

C.Set 'enable_tag_override' to true.

D.Use the 'passing' query parameter in the DNS request.

AnswerD

The 'passing' query parameter filters DNS responses so only instances whose health checks are all passing are returned, excluding any with warning or critical states. This satisfies the requirement that the service resolve only when every check passes.

Why this answer

Consul DNS supports a 'passing' query parameter that filters results to only those service instances whose health checks are all passing — warning and critical instances are excluded. Appending ?passing to the DNS query (e.g., 'dig @127.0.0.1 web.service.consul SRV?passing') ensures the service is returned only when every check is green. This is the standard mechanism for strict health-based DNS filtering.

Exam trap

Consul 1.15 often tests DNS query parameters by offering plausible-sounding but unrelated options ('stale', 'service_prefix', 'enable_tag_override') to see if candidates know that 'passing' is the health filter.

How to eliminate wrong answers

Option A is wrong because 'service_prefix' is not a DNS setting that controls health filtering — it relates to service name prefixing in DNS/HTTP configurations, not check status. Option B is wrong because the 'stale' query parameter allows reads from non-leader servers for scalability; it affects consistency, not health filtering. Option C is wrong because 'enable_tag_override' is an agent configuration that lets services override their own tags via the API — it has nothing to do with DNS health filtering.

Practice this question →

27

Multi-Selectmedium

Which THREE of the following are valid ways to categorize services in Consul?

Select 3 answers

A.IP subnets

B.Metadata (meta)

C.Namespaces

D.Tags

E.Port ranges

AnswersB, C, D

Metadata is a valid categorisation axis because Consul's service registration accepts arbitrary key-value pairs under the `meta` block, letting operators tag services by team, version, environment or tier. This satisfies the stem's requirement for a supported categorisation method, since meta is stored with the service definition and surfaced in catalog and health API responses.

Why this answer

Consul supports categorizing services by metadata (meta), which are arbitrary key/value pairs attached to a service registration and can be used to filter services via the catalog API (e.g., ?filter=ServiceMeta.Key==value). Namespaces are a Consul Enterprise feature that logically partitions services and other resources within a single datacenter, so services are effectively categorized by namespace. Tags are string labels attached to a service (and optionally to individual checks) that can be used to filter and query services, such as with the /v1/catalog/service/:name?tag=... endpoint.

IP subnets (A) are not a Consul service categorization mechanism; Consul does not group services by subnet. Port ranges (E) are likewise not a categorization feature, since a service's port is just a registration attribute and Consul provides no grouping or filtering by port range.

Exam trap

The trap is including infrastructure concepts like IP subnets or port ranges as categorization methods — candidates must distinguish Consul's native grouping primitives (tags, metadata, namespaces) from generic networking attributes.

Practice this question →

28

MCQhard

An operator registers a service 'cache' with an HTTP health check pointing to https://10.0.0.5:8443/health. The service appears in the catalog, but DNS queries for cache.service.consul return no records, and the check status shows critical with the message 'Get https://10.0.0.5:8443/health: x509: certificate signed by unknown authority'. Which action resolves the issue while keeping the check functional?

A.Set tls_skip_verify to true in the check definition.

B.Add the CA certificate to the agent's ca_file or ca_path configuration and reload the agent.

C.Re-register the service with a TCP check on port 8443 instead of an HTTP check.

D.Change the check to use HTTP instead of HTTPS.

AnswerB

The error indicates the Consul agent does not trust the certificate presented by the HTTPS endpoint. Configuring the agent's TLS verification with the correct CA via ca_file or ca_path allows the HTTP check to validate the server certificate and transition to passing. Once the check passes, the instance is included in DNS answers. This addresses the root cause without disabling security.

Why this answer

The critical status is caused by the agent's inability to verify the HTTPS endpoint's certificate. Supplying the issuing CA through the agent's ca_file or ca_path configuration lets the HTTP check complete TLS validation and report passing, which restores the instance to DNS answers. This corrects the trust configuration rather than disabling verification or weakening the check.

Exam trap

The trap here is reaching for tls_skip_verify or an HTTP downgrade to silence the certificate error, when the proper fix is to give the agent the CA it needs to trust the endpoint.

Practice this question →

29

MCQmedium

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?

A.Use different service names for every environment.

B.Modify the service's port number.

C.Apply 'production' or 'staging' tags to the service definition.

D.Assign different Consul datacenters.

AnswerC

Consul tags are arbitrary key-value metadata attached to a service registration, so tagging instances 'production' or 'staging' lets upstream routing, such as prepared queries or intentions, select the correct subset by tag rather than by service name alone.

Why this answer

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.

Exam trap

Consul 1.15 often tests whether candidates confuse tags (used for DNS/API filtering and routing) with Meta (used for arbitrary non-routing metadata), leading them to pick a wrong option.

How to eliminate wrong answers

Option A is wrong because using different service names for every environment defeats the purpose of Consul's service discovery — it fragments the service catalog and prevents clients from using a consistent name with tag-based filtering. Option B is wrong because modifying the port number is not a metadata mechanism; ports are transport-level endpoints and do not convey environment semantics for routing logic. Option D is wrong because assigning different Consul datacenters separates environments at the infrastructure level, which is a heavier architectural decision and does not use metadata to distinguish instances within the same service name.

Practice this question →

30

MCQeasy

A DevOps engineer needs to register an external service that runs outside the Consul datacenter, such as a third-party API. The service has a static IP address and a known port. Which Consul feature should be used to make this service discoverable within Consul?

A.Consul's intention-based access control

B.Consul's prepared queries with failover

C.Consul's external service registration with a static address

D.Service mesh with sidecar proxies

AnswerC

Consul allows registering external services by specifying a node name and address that are not part of the Consul cluster. This is done by registering a service with an address and port, and optionally a health check. The service appears in the catalog and DNS, enabling discovery. This is the appropriate method for external endpoints with static IPs.

Why this answer

To register an external service in Consul, you can use the service registration API or configuration files to define a service with a static address and port. Consul treats it as a regular service in the catalog, and it can be discovered via DNS or HTTP API. This is the correct approach for integrating external endpoints into Consul's service discovery.

Exam trap

The trap here is confusing service mesh or prepared queries with the actual registration mechanism for external services.

Practice this question →

31

MCQhard

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.

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

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

D.The service is critical; it will be deregistered immediately.

AnswerA

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.

Why this answer

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.

Exam trap

The trap here is assuming that a missed TTL update results in a warning state, but TTL checks only support passing, critical, and maintenance states.

Practice this question →

32

Multi-Selecthard

Which TWO of the following actions occur when a node fails in a Consul cluster?

Select 2 answers

A.All services on the node are marked critical.

B.The node is immediately deleted from the cluster.

C.The node is automatically rebooted.

D.Services on the node are removed from DNS results.

E.The entire cluster shuts down.

AnswersA, D

When a node fails, Consul's health checks for its services fail, so the catalog marks every service on that node as critical. This reflects the stem's node-failure scenario, where the failed node's services transition to critical health status.

Why this answer

Option A is correct because when a Consul node fails, its health checks stop passing and Consul marks all services registered on that node as critical, reflecting their unhealthy state in the catalog. Option D is correct because Consul's DNS interface only returns healthy service instances by default, so services on the failed node are removed from DNS results until the node recovers. Option B is incorrect because a failed node is not immediately deleted; it remains in the catalog and is only removed after being marked as failed or explicitly deregistered.

Option C is incorrect because Consul does not reboot nodes; it only detects and reports failures. Option E is incorrect because Consul is a distributed, fault-tolerant system and a single node failure does not shut down the entire cluster.

Practice this question →

33

MCQeasy

A developer registers a service 'web-frontend' with Consul using the HTTP API. The service registration includes a health check with a TCP check on port 8080 and an interval of '15s'. After registration, the developer queries the service using the DNS interface: 'dig @127.0.0.1 -p 8600 web-frontend.service.consul'. The query returns no results. Which of the following is the most likely reason?

A.The service is not passing its health check, so Consul DNS returns no records.

B.The DNS query must include the datacenter, e.g., 'web-frontend.service.dc1.consul'.

C.The DNS interface requires the 'passing' parameter to return results for services with checks.

D.The service name must be prefixed with an underscore, e.g., '_web-frontend.service.consul'.

AnswerA

Consul DNS returns only healthy service instances by default. If the TCP check on port 8080 is failing, the service instance is marked critical, and DNS queries will not return its IP address. This is the most likely reason for no results. The developer should verify the health check status using the HTTP API or the Consul UI.

Why this answer

Consul DNS returns only service instances that are passing their health checks. If the TCP check on port 8080 is failing, the instance is marked critical and excluded from DNS results. The developer should check the health status via the HTTP API or UI.

The other options are incorrect because the DNS query format is valid, the 'passing' parameter is not required, and service names do not need underscores.

Exam trap

The trap here is forgetting that Consul DNS by default filters out unhealthy instances, so a failing health check leads to no DNS results.

Practice this question →

34

MCQeasy

Which of the following best describes the 'consul agent -dev' mode in relation to service discovery?

A.It disables DNS interfaces.

B.It forces the service catalog to be stored in Redis.

C.It is suitable for production clusters.

D.It provides a single-node Consul environment for testing.

AnswerD

The -dev flag starts an in-memory, single-node agent that acts as both server and client, with no persistence or clustering. It is intended purely for local testing and development of service registration and discovery, not production use.

Why this answer

The 'consul agent -dev' flag starts a single-node Consul agent configured as a server and client in one process, with an in-memory datastore, no persistence, and no cluster join. It is explicitly designed for local development, testing, and demos — not for production — and it still exposes the DNS interface, HTTP API, and service catalog so you can exercise service discovery locally.

Exam trap

The trap is assuming dev mode is a lightweight production option or that it disables interfaces — candidates should remember it is strictly a single-node, in-memory, non-persistent environment intended only for testing.

How to eliminate wrong answers

Option A is wrong because dev mode does not disable the DNS interface; DNS is enabled by default on port 8600, which is one of the reasons dev mode is useful for testing service discovery. Option B is wrong because Consul never stores its catalog in Redis — the catalog lives in Consul's own Raft-backed state store, and dev mode simply keeps that state in memory. Option C is wrong because dev mode has no persistence, no redundancy, and no security hardening, making it unsuitable for production clusters.

Practice this question →

35

MCQeasy

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?

A.The service was deregistered because Consul automatically removes services after 30 seconds without traffic.

B.The TTL check entered the critical state because no pass heartbeat was received before the TTL expired.

C.The DNS interface only returns services registered with a script-based check, so TTL checks are ignored.

D.The service was never added to the catalog because the HTTP API requires a separate catalog registration call.

AnswerB

A TTL check starts in a critical state and only becomes passing when the service calls the /v1/agent/check/pass/<check_id> endpoint, or when the check is registered with a non-critical initial status. If the application never sends the heartbeat within the TTL window, Consul marks the check critical and excludes the instance from healthy DNS answers. This matches the observed behavior exactly.

Why this answer

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.

Exam trap

The trap here is confusing a service being absent from healthy DNS results with the service being deregistered from the catalog, when in fact the instance remains registered but its TTL check is critical.

Practice this question →

36

MCQhard

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?

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

B.Only instances from `dc1`.

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

D.Instances from all datacenters, sorted by latency.

AnswerB

By default, Consul DNS queries are scoped to the local datacenter of the agent handling the query. A client in `dc1` querying `user-auth.service.consul` will receive only instances registered in `dc1`. To query other datacenters, the client must explicitly specify the datacenter, such as `user-auth.service.dc2.consul`. This default behavior ensures locality and reduces cross-datacenter traffic.

Why this answer

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.

Exam trap

The trap here is assuming that Consul automatically aggregates results from all datacenters or fails over to another datacenter, when in fact DNS queries are strictly scoped to the local datacenter unless specified otherwise.

Practice this question →

37

MCQeasy

Which command is used to check the status of a registered service?

A.consul check

B.consul health service

C.consul status

D.consul list

AnswerB

The consul health service command queries Consul's health endpoint for a registered service, returning its instances and passing or failing checks. This directly reports service status, matching the requirement to verify a registered service's health.

Why this answer

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.

Exam trap

The trap is picking a plausible-sounding but nonexistent command like 'consul status' or 'consul check' — candidates must recall that health inspection is namespaced under 'consul health' with subcommands service, node, checks, and state.

How to eliminate wrong answers

Option A is wrong because 'consul check' is not a valid Consul CLI subcommand — health checks are inspected via 'consul health checks' or through the health service/node commands. Option C is wrong because 'consul status' does not exist; agent status is viewed with 'consul info' or 'consul members'. Option D is wrong because 'consul list' is not a Consul command — listing services is done with 'consul catalog services' or 'consul services'.

Practice this question →

38

Multi-Selecthard

Which THREE of the following are key components of a service definition?

Select 3 answers

A.Secret Key

B.Node BIOS version

C.Check/Health Check

D.Port

E.Service Name

AnswersC, D, E

A health check defines how Consul probes a service instance's availability, determining whether it is registered as passing or failing in the catalogue. It is a core service-definition block, alongside name and port, controlling readiness and DNS or load-balancing eligibility.

Why this answer

In a service definition (as used by service discovery/registry tools such as Consul), the Service Name (E) is the fundamental identifier that registers the service and lets other services and DNS/API lookups discover it, so it is a required key component. The Port (D) is also essential because it tells clients and the registry on which TCP/UDP port the service is listening, enabling correct routing and connection. A Check/Health Check (C) is likewise a core part of the definition, since it defines how the registry verifies the instance is healthy (e.g., an HTTP, TCP, or script check with an interval and timeout) and removes unhealthy instances from discovery.

By contrast, a Secret Key (A) is a credential/security artifact, not a structural element of a service definition, and a Node BIOS version (B) is hardware/firmware inventory data that has no role in describing or discovering a service.

Exam trap

Consul 1.15 often tests the distinction between required and optional fields in a service definition; candidates may incorrectly include unrelated items like secret keys or BIOS versions, or omit the health check as a key component.

Practice this question →

39

MCQmedium

A service is registered with Consul using the HTTP API, but it is not appearing in DNS queries. The service definition includes a health check that is currently critical. What is the most likely reason for the DNS query failure?

A.The service's health check is critical, so Consul excludes it from DNS results.

B.The service is registered in a different datacenter than the DNS query.

C.The service name contains uppercase letters, which are not allowed in DNS queries.

D.The DNS interface is disabled by default and must be enabled in the agent configuration.

AnswerA

Consul DNS only returns healthy instances by default. If a service's health check is critical, it is considered unhealthy and is omitted from DNS responses. This is the most likely reason the service does not appear in DNS queries, even though it is registered in the catalog.

Why this answer

Consul DNS returns only healthy service instances. When a service's health check is critical, the service is considered unhealthy and is excluded from DNS responses. Even though the service is registered and visible in the catalog, it will not resolve via DNS until the health check passes.

This behavior ensures that clients only receive addresses of healthy instances, which is a core principle of service discovery in Consul.

Exam trap

The trap here is assuming that registration alone guarantees DNS visibility, ignoring that health status filters DNS results.

Practice this question →

40

MCQmedium

What is the effect of changing the 'interval' parameter in a service health check?

A.It changes the frequency at which the check runs.

B.It changes the DNS TTL.

C.It changes the weight of the service.

D.It changes the timeout of the check.

AnswerA

The interval parameter defines the duration between consecutive health check executions, so altering it changes how often Consul probes the service. Shorter intervals detect failures faster; longer intervals reduce probe traffic but delay status updates.

Why this answer

The `interval` parameter in a Consul health check definition controls how often the check is executed — for example, `interval = "10s"` runs the check every 10 seconds. It directly governs the polling frequency of the check script, HTTP endpoint, or TCP probe, and therefore how quickly Consul detects a state change.

Exam trap

The trap here is confusing `interval` with `timeout` — both are timing parameters in the same health check block, and candidates who don't read carefully may pick the timeout option.

How to eliminate wrong answers

Option B is wrong because DNS TTL is controlled by the `dns_config.ttl` setting in the Consul agent configuration, not by a health check's interval. Option C is wrong because service weights are set via the `weights` block in the service definition (used for load balancing in prepared queries and DNS SRV), unrelated to check interval. Option D is wrong because the check timeout is governed by the separate `timeout` parameter, which specifies how long to wait for the check to respond before marking it critical.

Practice this question →

41

Multi-Selectmedium

Which THREE of the following are benefits of using the Consul DNS interface?

Select 3 answers

A.No application code changes required.

B.Provides advanced traffic shifting.

C.Platform-agnostic discovery.

D.Encrypts all traffic between services.

E.Easy integration with existing service discovery tools.

AnswersA, C, E

Consul's DNS interface resolves services through standard DNS queries, so existing applications discover services without any code modification or SDK integration. This satisfies the stem's benefit criterion by removing development effort entirely from the discovery path.

Why this answer

Ease of use, platform-agnostic, and no application changes are benefits.

Practice this question →

42

Multi-Selectmedium

A developer registers a service named 'orders' on a Consul node and wants DNS queries for orders.service.consul to return the service's SRV records so clients can discover both the address and the port. The developer is verifying that the registration contains everything needed for SRV resolution. Which two registration elements must be present for SRV queries to return usable records? (Choose two.)

Select 2 answers

A.A port value in the service definition

B.An explicit tag on the service

C.A health check attached to the service

D.A DNS-friendly service name with no underscores

E.A service address or a node address that Consul can resolve

AnswersA, E

SRV records include the service port as part of their data, so Consul cannot synthesize a meaningful SRV answer without a port. The service registration must therefore include a port field; if it is omitted or zero, Consul either omits the SRV record or returns a record with port 0, which clients cannot use to connect. This is why the port is essential for SRV-based discovery.

Why this answer

SRV answers combine a target host and a port, so Consul needs both a port from the service definition and a resolvable address, taken from the service address or inherited from the node. Health checks, tags, and naming conventions affect filtering or presentation but are not prerequisites for generating SRV records. The two required elements are therefore the port and the address.

Exam trap

The trap here is assuming a health check or a tag is required for SRV records, when the only structural requirements are a port and a resolvable target address.

Practice this question →

43

MCQhard

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

B.Set the `status` field of the service to `passing` in the service definition

C.Disable the health check by removing the `check` block from the service definition

D.Change the health check to a script check that runs every 30 seconds

AnswerA

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.

Why this answer

The `deregister_critical_service_after` setting defines the duration a service can remain critical before automatic deregistration. Increasing this value allows more time for the service to recover from transient failures. The other options either mask the problem or remove health monitoring, which is not advisable.

Exam trap

The trap here is thinking that changing the health check type or manually setting status will prevent deregistration, when the actual control is the critical service deregistration timeout.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Service Discovery questions.

Start 20-question session