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

Question 1

An SRE is tuning a Consul 1.15 service mesh for a latency-sensitive application. They want to reduce connection overhead between two services that communicate constantly, and they also want outbound calls from the client proxy to reach an internal upstream that is not registered as a Consul service. Which two configuration changes should they make? (Choose two.)

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

Accepted Answer

Define the upstream with an explicit 'local_bind_port' and point the client at that loopback port.. Two goals are in play: reducing handshake overhead for frequent calls, and letting the client reach a non-Consul endpoint. Enlarging the connection pool with keep-alives reuses established mTLS sessions, while binding the upstream to a local loopback port gives the client a stable dial target that the sidecar forwards to the internal service. Together these satisfy both requirements without requiring the endpoint to be registered in the catalog.

Answer

Set 'destination_type' to 'prepared_query' so the unregistered service can be discovered dynamically.

Answer

Configure an upstream with a 'destination_type' of 'service' and rely on the default connection pooling.

Answer

Set the upstream's 'destination_type' to 'service' with a 'destination_name' and configure 'destination_peer' for the internal endpoint.

Question 2

A Consul operator is configuring an explicit intention to allow traffic from a frontend service to a backend service. The intention is created with the command `consul intention create -allow frontend backend`. Shortly after, the operator notices that traffic from frontend to backend is still being denied. The operator verifies that the sidecar proxies are running and connected. What is the most likely reason for the continued denial?

Accepted Answer

The intention was created in the wrong namespace or partition.. Intentions are the mechanism to authorize connections between services in a Consul service mesh. In Consul Enterprise, they are scoped by namespace and partition. If the intention is created in a different scope than the services, it will not be enforced. The operator must ensure the intention is created in the same namespace and partition as the services.

Answer

The frontend service must be registered with a service tag that matches the intention's source.

Answer

The intention requires a restart of the Consul client agents to take effect.

Answer

The intention must be created with the `-deny` flag to explicitly allow traffic.

Question 3

A platform team is deploying Consul Connect in a multi-datacenter environment. They need to ensure that services in different datacenters can communicate securely through mesh gateways. Which TWO of the following are required to enable cross-datacenter service-to-service communication with mesh gateways? (Choose two.)

Accepted Answer

Intentions must be created in the destination datacenter to allow traffic from the source datacenter.. Cross-datacenter communication with mesh gateways requires that mesh gateways be deployed in each datacenter and that intentions be configured in the destination datacenter to authorize traffic. Mesh gateways bridge the datacenters, but authorization is still enforced by intentions at the destination. Without both, traffic will not flow.

Answer

The `primary_datacenter` must be set to the same value on all servers in all datacenters.

Answer

All sidecar proxies must be configured with the `-mesh-gateway` flag in their service definition.

Answer

The `connect.enable_mesh_gateway` configuration must be set to true on all client agents.

Question 4

A developer is deploying a new service named 'payments' with a sidecar proxy in a Consul Connect mesh. The service must be able to accept connections from the 'checkout' service. The developer has created an intention allowing traffic from 'checkout' to 'payments'. However, when testing, the 'checkout' service cannot connect to 'payments'. The developer checks the sidecar proxy logs and sees no errors. What is the most likely missing configuration?

Accepted Answer

The 'payments' service must be registered with a sidecar proxy and the proxy must be running.. For a service to receive traffic in a Consul Connect mesh, it must have a sidecar proxy registered and running. The sidecar proxy is responsible for enforcing intentions and handling mTLS. Even with a correct intention, if the destination service lacks a sidecar proxy, connections will fail. Thus, the missing configuration is the sidecar proxy for 'payments'.

Answer

The intention must be created with the `-allow` flag and specify the source and destination namespaces.

Answer

The 'checkout' service must have an upstream configuration pointing to 'payments'.

Answer

The 'payments' service must be configured with `connect.enable_sidecar` set to true in its service definition.

Question 5

An operator manages a Consul 1.15 datacenter with Connect enabled and a default deny intention. A new service 'ledger' is registered with a sidecar proxy. The operator creates an intention allowing 'billing' to reach 'ledger', but traffic from 'billing' is still denied. The billing service's sidecar proxy is healthy and registered. Which condition most likely explains the continued denial?

Accepted Answer

The intention was created without specifying a source namespace, and the services are in different namespaces under Consul Enterprise.. Intentions in Consul Enterprise are scoped by namespace. A source namespace that does not match the caller's actual namespace causes the intention to be ignored, so the default deny continues to block traffic. The intention must name the correct source namespace (or use a wildcard appropriately) to authorize billing to reach ledger.

Answer

The intention must be created as a service-resolver config entry instead of a standard intention.

Answer

The ledger service must be registered with a 'connect' block that lists billing as an allowed client.

Answer

The billing sidecar proxy needs to be restarted so it can download the new intention.

Question 6

A security engineer is reviewing a Consul 1.15 Connect deployment and wants to understand which statements accurately describe how sidecar proxies enforce and secure mesh communication. (Choose two.)

Accepted Answer

Sidecar proxies use mutual TLS with certificates issued by the Connect CA to authenticate both ends of a connection.. Connect secures traffic with mutual TLS using certificates from the Connect CA, giving each proxy a verifiable identity. The destination proxy enforces intentions against that identity, allowing or denying the connection before it reaches the application. Together, mutual authentication at both ends and destination-side authorization form the basis of mesh security.

Answer

Intentions are enforced only at the ingress gateway and not by individual sidecar proxies.

Answer

Intentions are evaluated by the source sidecar before the connection leaves the client application.

Answer

Sidecar proxies encrypt traffic using a shared symmetric key distributed by the servers to all services.

Question 7

What does the 'kind' field in a service definition specify for a Consul Connect service?

Accepted Answer

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.

Answer

The service version.

Answer

The datacenter location.

Answer

The language of the application.

Question 8

Which component acts as the default sidecar proxy for Consul Connect?

Accepted Answer

Envoy. Envoy is the default and recommended sidecar proxy for Consul Connect.

Answer

Nginx

Answer

HAProxy

Answer

Linkerd

Question 9

When using 'Consul Connect native' integration, how does the application handle mTLS?

Accepted Answer

The application uses the local Consul agent API to fetch identity certificates.. In native integration, the application uses the Consul API to retrieve certificates and handles the mTLS handshake itself.

Answer

mTLS is disabled by default for native apps.

Answer

The sidecar proxy handles all mTLS.

Answer

The Consul agent performs the TLS handshake on behalf of the app.

Question 10

You have a service that needs to talk to a service in a different datacenter. What configuration is required?

Accepted Answer

A mesh gateway deployment.. To allow services in different datacenters to communicate over Consul's service mesh, you must deploy a mesh gateway in each datacenter. Mesh gateways proxy mTLS traffic between datacenters, enabling sidecar proxies to reach services in remote datacenters without direct network peering. Without a mesh gateway, cross-datacenter service-to-service traffic cannot traverse the WAN through Consul's mesh.

Answer

Direct VPC peering.

Answer

An external service definition.

Answer

A global intention.

Question 11

You need to deny all traffic between 'service-a' and 'service-b' using intentions. What is the most efficient way to achieve this?

Accepted Answer

consul intention create -deny service-a service-b. Intentions can be set to 'deny' explicitly, which overrides any 'allow' rules.

Answer

consul intention create -allow-none service-a service-b

Answer

consul intention set -action=drop service-a service-b

Answer

consul intention delete service-a service-b

Question 12

Which command displays all active intentions in the Consul mesh?

Accepted Answer

consul intention list. The command 'consul intention list' displays all active intentions in the Consul mesh. Intentions define which services are allowed to communicate with which other services when Connect is enabled. The list command shows the source, destination, action (allow/deny), and precedence.

Answer

consul connect intentions

Answer

consul kv get intentions

Answer

consul services intentions

Question 13

What is the primary role of the Consul Connect 'upstream' configuration?

Accepted Answer

To define the services that a local service can connect to.. The Consul Connect 'upstream' configuration defines the services that a local service can connect to through the mesh. It specifies the destination service name, optional datacenter, and local port that the sidecar proxy listens on to forward traffic to the upstream. This is the core mechanism for establishing service-to-service connections in Consul Connect.

Answer

To set intention priority.

Answer

To register external services.

Answer

To define health check ports.

Question 14

What is the function of the 'consul connect envoy' command?

Accepted Answer

To launch and manage the Envoy proxy sidecar for a service.. This command bootstraps and manages the lifecycle of the Envoy sidecar process.

Answer

To generate TLS certificates for Envoy.

Answer

To verify the Envoy binary installation.

Answer

To update the Envoy configuration via CLI.

Question 15

How are intentions applied to services in different partitions or namespaces?

Accepted Answer

You must specify the namespace in the intention definition.. In Consul Enterprise, intentions are applied to services in different partitions or namespaces by specifying the namespace (and partition, if applicable) in the intention definition. This allows fine-grained control over which services can communicate across these boundaries. Intentions are not limited to the default namespace, nor are they always global.

Answer

Intentions only work within the 'default' namespace.

Answer

Intentions are always global.

Answer

They must be created via API only.