Consul 1.15 Service Mesh With Consul Connect Practice Test 2 — 15 Questions

Question 1

You have a Consul datacenter with Connect enabled. A service 'frontend' needs to communicate with 'backend' over the mesh. You notice that traffic is not being encrypted even though mTLS is enabled globally. Which of the following is the most likely cause?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

The 'frontend' service is not configured to use a sidecar proxy, so it connects directly without mTLS.. mTLS in Consul Connect is enforced by the sidecar proxies. For traffic to be encrypted, both the source and destination services must route through their proxies. If a service is not using a proxy, its traffic does not traverse the mesh and remains unencrypted. Therefore, the most likely cause is that 'frontend' is not configured with a sidecar proxy, so its connections to 'backend' are direct and not secured by mTLS.

Answer

The 'backend' service is not registered with a Connect-enabled service definition.

Answer

The CA root certificate has expired, causing mTLS to fall back to plaintext.

Answer

The intention between 'frontend' and 'backend' is set to 'allow', which disables encryption.

Question 2

A platform team is running Consul 1.15 with Connect enabled across two datacenters. They need to allow a service named 'payments' in datacenter 'dc1' to communicate with a service named 'ledger' in datacenter 'dc2' over the mesh, while denying all other cross-datacenter traffic to 'ledger'. Which two configuration elements are required to achieve this? (Choose two.)

Accepted Answer

Enable Connect on both datacenters and ensure that the Consul servers in dc1 and dc2 are federated.. To allow cross-datacenter traffic, you must enable Connect and federate the datacenters, then create an intention in the source datacenter that permits the specific service pair. The intention is evaluated where the source service is registered, so it must be in dc1 with source 'payments' and destination 'ledger'. Mesh gateways are also needed for the data plane, but the question asks for configuration elements; federation and the intention are the essential control plane requirements.

Answer

Configure a mesh gateway in each datacenter and set the 'connect' block for both services to use the mesh gateway mode 'local'.

Answer

Define an intention in dc2 with source 'payments' and destination 'ledger', and set the action to allow.

Answer

Create a service-resolver configuration that maps 'ledger' to a specific subset in dc2 and set the default subset to 'v1'.

Question 3

You are deploying a new service 'payments' in a Consul 1.15 datacenter. Security policy requires that all service-to-service communication be encrypted with mTLS and authenticated via intentions. You have already registered the service and its sidecar proxy. What must you do next to enforce mTLS for this service's inbound connections?

Accepted Answer

Enable Connect in the service definition with 'connect { sidecar_service {} }' and ensure intentions allow the traffic.. To enforce mTLS for a service's inbound connections, the service must be registered with Connect and have a sidecar proxy. This is done by including a 'connect' block with 'sidecar_service {}' in the service definition. Consul then automatically provisions mTLS certificates and enforces intentions. Other options either affect agent-level TLS or routing, not service mesh mTLS.

Answer

Configure the service's upstreams to use 'mesh_gateway' mode to force mTLS.

Answer

Create a service intention that explicitly allows traffic from all sources, which automatically enables mTLS.

Answer

Set 'verify_incoming = true' in the Consul agent configuration on the node where the service runs.

Question 4

A security engineer needs to permit traffic from any service in the 'frontend' namespace to 'backend' services in the 'default' namespace, while denying all other cross-namespace traffic. Consul 1.15 Enterprise is in use with admin partitions and namespaces enabled. Which intention configuration accomplishes this with the least administrative overhead?

Accepted Answer

Create an intention with source '*' in the 'frontend' namespace and destination 'backend' in the 'default' namespace, action allow.. In Consul Enterprise, intentions are namespace-aware. A single allow intention whose source is the wildcard service in the 'frontend' namespace and whose destination is 'backend' in the 'default' namespace permits all frontend services to reach backend. Other namespaces have no matching intention and therefore remain denied under the default-deny model, minimizing administrative effort.

Answer

Create a service-resolver configuration that maps 'frontend' to 'backend' and set the default subset to allow.

Answer

Create an intention with source 'frontend/*' and destination 'default/backend', action allow.

Answer

Enable the built-in 'allow-namespace' ACL policy on the default namespace and attach it to the frontend token.

Question 5

A platform team runs Consul 1.15 with Connect enabled. They want every service in the datacenter to enforce mutual TLS automatically, without adding 'connect' blocks to each service definition. Which configuration should they apply?

Accepted Answer

Set 'enable_central_service_config = true' in the agent configuration, then run 'consul config write' with a service-defaults entry containing 'Mesh: true'.. Centralized service configuration lets operators define default Connect behavior once and have it applied to all services in the datacenter. Enabling the agent option and writing a service-defaults entry with Mesh set to true causes agents to inject sidecars and enforce mTLS without per-service connect blocks. Intention changes and auto-encrypt affect authorization or agent RPC security, not mesh enrollment.

Answer

Enable 'auto_encrypt' on all client agents and set 'verify_outgoing = true'.

Answer

Create a global intention with action 'allow' for every service pair.

Answer

Set 'connect.enabled = true' in the agent configuration on every client agent.

Question 6

You are troubleshooting a Consul Connect mesh where a service 'orders' cannot connect to its upstream 'inventory'. Which TWO of the following commands would help you diagnose the issue? (Choose two.)

Accepted Answer

consul intention list. To diagnose why 'orders' cannot connect to 'inventory', you should check the intentions that govern their communication. The 'consul intention check' command specifically tests whether a connection is allowed, while 'consul intention list' shows all intentions so you can inspect for missing or incorrect rules. Together, they provide the necessary information to identify authorization problems.

Answer

consul connect envoy -sidecar-for orders -admin-bind localhost:19000

Answer

consul services register orders

Answer

consul catalog services -tags

Question 7

A Consul 1.15 cluster uses an external CA with Vault as the Connect CA provider. An operator notices that leaf certificates for sidecar proxies are not being rotated before expiration. The operator confirms that Vault is reachable and the root certificate is valid. Which configuration setting should the operator verify to ensure automatic rotation occurs?

Accepted Answer

The Vault provider's 'LeafCertTTL' and the 'RotationPeriod' in the CA configuration, along with ensuring the Vault token has not expired.. When using Vault as the Connect CA, Consul relies on a Vault token to request leaf certificates. If that token expires or lacks necessary policies, Consul cannot obtain new certificates, and rotation fails even though Vault is reachable. The operator should check the Vault token's validity and permissions, as well as the LeafCertTTL and RotationPeriod settings, to ensure the rotation process can complete.

Answer

The 'RotationPeriod' in the Connect CA configuration.

Answer

The 'LeafCertTTL' in the Connect CA configuration.

Answer

The 'IntermediateCertTTL' in the Connect CA configuration.

Question 8

You are configuring a Consul Connect sidecar proxy for a service 'frontend'. The service needs to connect to a database service 'db' that is running outside the Consul service mesh. You want to enable secure communication to this external service. What should you configure in the sidecar proxy's upstream configuration?

Accepted Answer

Configure a terminating gateway and reference it in the upstream as a 'gateway' with the external service's address.. To connect a mesh service to an external service, you must deploy a terminating gateway. The terminating gateway acts as a proxy for external services, and the sidecar proxy's upstream configuration points to the gateway. This enables mTLS from the sidecar to the gateway, and the gateway forwards traffic to the external service. Other options do not provide the necessary secure bridge.

Answer

Add the external service as a Consul service with a fake health check, then configure the upstream normally.

Answer

Set the upstream's 'destination_type' to 'service' and provide the external service's address.

Answer

Set the upstream's 'mesh_gateway' mode to 'remote' and provide the external service's address.

Question 9

A Consul operator needs to enable mTLS globally for all Connect-enabled services in a datacenter. They want to ensure that all service-to-service communication is encrypted and authenticated. Which configuration change is required?

Accepted Answer

Enable Connect and ensure that all services are registered with a sidecar proxy; mTLS is automatically enforced for all Connect traffic.. Consul Connect inherently uses mTLS for all service-to-service communication between sidecar proxies. To enable mTLS globally, you must enable Connect on all agents and ensure services are registered with sidecar proxies. There is no separate global mTLS toggle; it is a fundamental property of Connect. The other options either do not enforce mTLS or refer to non-existent settings.

Answer

Set 'connect.ca_provider' to 'consul' in the server configuration.

Answer

Set 'connect.enable_mesh_tls' to true in the Consul server configuration.

Answer

Set 'connect.enabled' to true in the Consul agent configuration on all nodes.

Question 10

A platform engineer is diagnosing intermittent failures where applications cannot reach upstream services through their Connect sidecar proxies in a Consul 1.15 datacenter. They want to gather evidence about proxy behavior and intention enforcement. Which TWO actions provide the most relevant diagnostic information? (Choose two.)

Accepted Answer

Query the Envoy admin interface for the sidecar on its admin port to inspect cluster health and listener configuration.. Effective troubleshooting separates authorization from connectivity. Checking the intention decision confirms whether the proxy should permit the call, while the Envoy admin interface reveals listener binding, cluster health, and stats that explain connection failures. Server restarts, registration changes, and gossip key inspection do not produce targeted evidence and may disrupt the environment.

Answer

Delete the sidecar service registration and re-register it with a new local_bind_port to clear any stale configuration.

Answer

Inspect the Consul agent's gossip encryption key to confirm that proxies can decrypt intention updates.

Answer

Restart the Consul servers one at a time to force a full re-sync of the service catalog to all proxies.

Question 11

A service named 'web' is registered with Consul Connect and uses an Envoy sidecar proxy. You need to allow 'web' to communicate with two upstream services: 'api' and 'db'. Which two configuration steps are required to enable this communication? (Choose two.)

Accepted Answer

Define an upstream in the 'web' service registration that points to 'db'.. To enable 'web' to communicate with 'api' and 'db' through Connect, you must define an upstream for each service in the 'web' service registration. This configures the sidecar proxy to route traffic to those upstreams. While intentions are also required for authorization, the question specifically asks for two configuration steps to enable communication, and the upstream definitions are the direct configuration for connectivity. Enabling Connect and mesh gateways are either prerequisites or not applicable.

Answer

Enable Connect on the 'web' service by setting 'connect { sidecar_service {} }' in its registration.

Answer

Configure a mesh gateway to route traffic between 'web' and the upstream services.

Answer

Create an intention that allows 'web' to 'api' and another that allows 'web' to 'db'.

Question 12

A Consul 1.15 operator is troubleshooting a Connect-enabled service whose sidecar proxy reports connection failures to an upstream. The operator wants to gather diagnostic data that reveals the proxy's view of the mesh, including its listeners, clusters, and endpoints. (Choose two.)

Accepted Answer

Run 'consul connect envoy -admin-bind' to expose the Envoy admin interface and query '/clusters' and '/listeners'.. Effective troubleshooting combines proxy-level and policy-level diagnostics. The Envoy admin interface exposes listeners, clusters, and endpoints, showing how the proxy sees the mesh. The intention check command verifies whether authorization permits the connection. Together they isolate whether the failure is in proxy configuration or in intention policy, which are the two most common causes of Connect connection errors.

Answer

Run 'consul catalog services -tags' to list all services and their tags in the datacenter.

Answer

Run 'consul monitor -log-level=trace' to stream all Consul agent logs and search for the service name.

Answer

Run 'consul kv get -recurse connect/' to inspect the Connect configuration stored in the KV store.

Question 13

A platform team runs a Consul 1.15 datacenter where every service in the 'payments' namespace is registered with Connect sidecar proxies. Security requires that the 'ledger' service accept inbound connections only from 'checkout', regardless of which datacenter or partition the caller originates from. Which intention definition should the operator create?

Accepted Answer

A service-to-service intention with source 'checkout' and destination 'ledger', scoped to the 'payments' partition.. Intention matching is scoped: the source identity that a proxy presents includes partition and namespace, and the intention must be defined at a scope that covers that identity. Defining the checkout-to-ledger rule in the payments partition authorizes the intended caller wherever it runs inside that partition while continuing to deny all other services, which is exactly the least-privilege outcome security demanded.

Answer

A service-to-service intention with source 'checkout' and destination 'ledger', scoped to the 'default' partition.

Answer

A service-to-service intention with source 'checkout' and destination 'ledger', scoped to the 'payments' namespace.

Answer

A wildcard intention using source '*' and destination 'ledger' with action 'allow'.

Question 14

A Consul 1.15 datacenter spans two federated datacenters, 'dc1' and 'dc2'. A service 'frontend' in dc1 must call 'backend' in dc2 through the mesh. Mesh gateways are deployed in both datacenters. The operator configures an upstream for 'frontend' with the destination 'backend' and sets the datacenter to 'dc2'. However, connections fail and the sidecar logs show that no healthy endpoints are found. Which configuration issue is the most likely cause?

Accepted Answer

The upstream is missing the 'mesh_gateway' configuration or the sidecar's mesh gateway mode is not set to 'remote' or 'local', so the proxy cannot route to dc2.. Cross-datacenter Connect traffic requires the sidecar to route through a mesh gateway. The upstream must specify a mesh gateway mode, and the proxy needs to know which gateway to use. Without this, the sidecar attempts direct discovery and fails to find remote endpoints. Setting the mode to remote or local, and ensuring gateways are registered, enables the sidecar to forward traffic to the remote datacenter.

Answer

The mesh gateway in dc1 is not registered with the 'mesh-gateway' tag and therefore not discoverable by the sidecar.

Answer

The upstream's mesh gateway mode is set to 'none' or 'local' instead of 'remote', causing the sidecar to look for endpoints locally in dc1.

Answer

The upstream's destination datacenter is set, but the service 'backend' is not registered with Connect enabled in dc2, so no mesh endpoints exist.

Question 15

A retail company runs Consul 1.15 in two datacenters connected by a mesh gateway. The 'orders' service in dc1 must call 'inventory' in dc2 over the mesh. An operator has created an intention allowing orders to reach inventory and configured the upstream. Calls still fail at the remote proxy with a certificate validation error. Which configuration step was most likely missed?

Accepted Answer

Setting up a cross-datacenter CA federation so both datacenters share a common root and the certificate's trust domain matches the remote proxy's expectation.. Cross-datacenter Connect traffic requires a shared trust anchor. When each datacenter uses its own unshared CA, the remote proxy cannot validate the incoming leaf certificate and the handshake fails regardless of intentions. Federating the CAs, or configuring trust-domain mappings so the presented trust domain is accepted, restores the chain of trust and lets the authorized call proceed through the mesh gateway.

Answer

Registering the inventory service with a sidecar proxy in dc1 as well as dc2.

Answer

Enabling connect.enable_serverless_plugin in the server configuration.

Answer

Configuring the mesh gateway in remote datacenters with the same CA and ensuring the leaf certificate's trust domain matches.