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

Question 1

Which TWO of the following are features of Consul Connect native integration?

Accepted Answer

The app handles its own mTLS handshake.. Consul Connect native integration means the application itself participates directly in the service mesh rather than relying on a sidecar proxy, so option A is correct: the app performs its own mTLS handshake to establish mutually authenticated, encrypted connections with other services. Option B is also correct because a natively integrated app uses the Consul agent's local HTTP API (e.g., the /v1/agent/connect/ca/leaf/ endpoint) to obtain its leaf certificate and CA roots for that mTLS handshake. Option C is wrong because native integration is language-agnostic — Consul provides client libraries for multiple languages and the API can be called from any runtime, not just Go. Option D is wrong because the whole point of native integration is that no sidecar proxy is required for routing or encryption. Option E is wrong because native integration specifically enables secure mTLS traffic, not merely non-secure traffic.

Answer

The app must be written in Go.

Answer

The sidecar proxy is still required for routing.

Answer

It supports only non-secure traffic.

Question 2

Which TWO are common use cases for Consul Connect?

Accepted Answer

Zero-trust networking.. Consul Connect is HashiCorp's service mesh feature within Consul, and option C (Zero-trust networking) is correct because Connect enforces identity-based authorization via mutual TLS (mTLS) between services, so no service is trusted by default based on network location. Option D (Secure service-to-service communication) is also correct because Connect provides automatic mTLS encryption, sidecar proxies (Envoy), and intention-based access control for east-west traffic between services. Options A (Managing server hardware), B (Creating virtual machines), and E (Configuring network switches) are incorrect because those are infrastructure provisioning and physical/virtual network device tasks handled by tools like Terraform, hypervisors, or switch management software, not by Consul Connect's service mesh capabilities.

Answer

Managing server hardware.

Answer

Creating virtual machines.

Answer

Configuring network switches.

Question 3

You are configuring Consul Connect for a service named 'payments'. You want to allow incoming connections only from services that present a valid client certificate from a specific CA and also enforce that the source service is 'checkout'. What combination of Consul features should you use?

Accepted Answer

Configure an intention with source 'checkout' and action 'allow', and enable mutual TLS in the mesh.. To restrict incoming connections to a specific source service, Consul intentions are the correct mechanism. They define which services are allowed to connect based on service identity. Enabling mTLS ensures that connections are authenticated with certificates issued by Consul's CA, providing encryption and identity verification. Together, they enforce that only 'checkout' can connect to 'payments' and that the connection is secure.

Answer

Enable ACLs with a token that has 'service:write' for 'payments' and distribute it only to 'checkout'.

Answer

Configure a service resolver with a subset that includes only 'checkout' and set the default subset to that.

Answer

Use a network segment to isolate 'payments' and a firewall rule to allow only 'checkout'.

Question 4

A platform team runs Consul 1.15 with Connect enabled in a single datacenter. They register a new service 'payments' with a sidecar proxy, but when the application team tries to reach 'payments' through its local proxy, the connection is refused. Running 'consul intention check web payments' returns 'Result: denied'. No intentions have been created yet. What should the team do to allow the traffic while following Consul's default security model?

Accepted Answer

Create an intention that allows 'web' to 'payments' and apply it to the datacenter with 'consul intention create web payments'.. Connect evaluates intentions for every proxied connection and, absent a match, defaults to deny. The 'consul intention check' output confirms denial. Creating an allow intention between the source service 'web' and destination 'payments' establishes the required authorization. Environment toggles, re-registration, and explicit deny intentions do not open the path under the default-deny posture.

Answer

Modify the 'payments' service definition to include 'connect: { sidecar_service: {} }' under the service stanza and reregister it.

Answer

Set the environment variable CONSUL_ALLOW_INSECURE_TRAFFIC=true on the 'payments' sidecar and restart it.

Answer

Run 'consul intention create -deny web payments' and then restart the 'web' sidecar proxy.

Question 5

A platform team is deploying a new service 'payments' on a Consul 1.15 cluster with Connect enabled. They want to ensure that only the 'checkout' service can initiate connections to 'payments', and all other services are denied by default. Which intention should they create?

Accepted Answer

An intention from '*' to 'payments' with action 'deny', and an intention from 'checkout' to 'payments' with action 'allow'.. Consul intentions are evaluated based on specificity, with exact matches taking precedence over wildcards. A wildcard deny intention sets a default deny posture for the destination service, while a specific allow intention grants access to the authorized source. This pattern enforces least privilege and is a common security practice in Consul Connect.

Answer

An intention from '*' to 'payments' with action 'allow', and an intention from 'checkout' to 'payments' with action 'deny'.

Answer

An intention from 'payments' to 'checkout' with action 'deny', and an intention from 'checkout' to 'payments' with action 'allow'.

Answer

An intention from 'checkout' to 'payments' with action 'allow', and no other intentions.

Question 6

An operator is configuring a Connect sidecar proxy in a service definition so that outbound calls to a dependency are routed through the mesh. The dependency is registered as 'redis' in the same datacenter, listening on port 6379. The application expects to reach it at localhost:6379. Which upstream block in the sidecar_service definition achieves this?

Accepted Answer

upstreams = [{ destination_name = "redis", local_bind_port = 6379 }]. Upstreams in a sidecar_service definition require a destination_name and a local_bind_port. The local_bind_port is what the application dials on localhost, and the sidecar handles discovery, mTLS, and load balancing to the destination. Fields such as destination_port or service/port are not valid in this context, and a datacenter field is only needed for cross-datacenter upstreams.

Answer

upstreams = [{ destination_name = "redis", datacenter = "dc1", local_bind_port = 6379 }]

Answer

upstreams = [{ destination_name = "redis", destination_port = 6379 }]

Answer

upstreams = [{ service = "redis", port = 6379 }]

Question 7

You are using Consul 1.15 with Connect and want to enable Layer 7 traffic management for a service 'api' to perform HTTP path-based routing. Which configuration is required in the service definition?

Accepted Answer

Set 'protocol' to 'http' in the service definition and configure a service-router config entry.. Consul's L7 traffic management requires the service to declare an HTTP-based protocol and use config entries such as service-router, service-splitter, or service-resolver. The service-router specifically supports path-based routing by matching on HTTP path, header, or query parameters. Without the correct protocol, Envoy operates in L4 mode and cannot inspect HTTP requests.

Answer

Set 'protocol' to 'grpc' and configure a service-splitter config entry.

Answer

Set 'protocol' to 'tcp' and use a service-resolver config entry with subsets.

Answer

Set 'protocol' to 'http' and create an intention with a path-based rule.

Question 8

A Consul 1.15 operator is configuring a service mesh with Connect and needs to ensure that the sidecar proxy for 'frontend' can establish mTLS connections to the 'backend' service. The operator has already registered both services with Connect sidecars. Which two actions are required to allow this communication? (Choose two.)

Accepted Answer

Configure the 'frontend' service registration with an upstream stanza pointing to 'backend'.. To allow 'frontend' to communicate with 'backend' through Connect, two things are needed: an intention that authorizes the traffic, and an upstream configuration in the 'frontend' service registration so its sidecar knows where to forward requests. Intentions enforce authorization, while the upstream stanza provides the necessary listener and routing information for the sidecar to initiate the mTLS connection.

Answer

Set the 'connect.enabled' parameter to true in the service definition for both services.

Answer

Enable TLS on the Consul agents in both datacenters.

Answer

Manually generate and distribute leaf certificates to both services.

Question 9

You are deploying a new service 'api' in a Consul Connect mesh. You want to ensure that all incoming connections to 'api' are logged for auditing purposes. Which Consul feature should you configure?

Accepted Answer

Enable access logs on the sidecar proxy for 'api'.. To log incoming connections to a service in Consul Connect, you should enable access logs on the sidecar proxy. The proxy handles all incoming traffic and can be configured to write logs that include details such as the source service, destination, and timestamp. This is the correct approach for auditing service-to-service communication.

Answer

Use Consul's built-in traffic capture feature to record all connections to 'api'.

Answer

Set the intention action to 'allow' and enable audit logging in Consul's ACL system.

Answer

Configure a service mesh gateway to log all traffic passing through it.

Question 10

You are deploying a Consul Connect service mesh in a single datacenter. A developer asks how service-to-service authorization is enforced when two services communicate through their sidecar proxies. What is the primary mechanism that controls whether the connection is allowed?

Accepted Answer

Consul intentions define whether a connection between a source and destination service is permitted.. Consul intentions are the authorization mechanism in Consul Connect. They evaluate the source service identity against the destination service and determine whether the connection is allowed. While mTLS provides authentication and encryption, it is the intention that enforces authorization. Network ACLs and static proxy configurations do not fulfill this role. Therefore, intentions are the correct answer.

Answer

Network ACLs on the Consul servers filter traffic between sidecar proxies.

Answer

mTLS certificates alone determine if a connection is permitted.

Answer

The Envoy proxy configuration includes a static list of allowed upstream services.

Question 11

A security engineer is configuring intentions for a service mesh. They want to allow traffic from 'frontend' to 'backend' only when the connection is encrypted with mTLS and originates from a specific namespace in Consul Enterprise. Which intention attribute should they use to enforce the namespace constraint?

Accepted Answer

SourceNamespace. In Consul Enterprise, intentions support namespace and partition attributes to provide fine-grained authorization. To allow traffic only from a specific namespace, the SourceNamespace attribute must be set. This ensures that only service instances registered in that namespace can establish connections. Other attributes like SourceName or SourcePartition do not fulfill the namespace-specific requirement.

Answer

SourcePartition

Answer

SourceType

Answer

SourceName

Question 12

A service 'inventory' is registered in Consul 1.15 with Connect enabled. You need to verify that the sidecar proxy for 'inventory' is running and healthy. Which command should you use?

Accepted Answer

consul health service inventory-sidecar-proxy. Consul registers a sidecar proxy for each Connect-enabled service with a naming convention of '<service>-sidecar-proxy'. The 'consul health service' command retrieves the health checks and status for that proxy, confirming it is running and passing checks. This is the standard way to verify sidecar health in Consul.

Answer

consul connect proxy -sidecar-for inventory

Answer

consul services status inventory

Answer

consul intention check inventory

Question 13

You are using Consul 1.15 with Connect enabled. A service 'web' needs to communicate with an upstream service 'api' in a different datacenter. You have configured a mesh gateway in each datacenter. The 'web' service's sidecar proxy is configured with an upstream for 'api'. However, traffic is failing. You check the sidecar proxy logs and see 'no healthy upstream'. What is the most likely cause?

Accepted Answer

The upstream service 'api' is not registered in the remote datacenter or has no healthy instances.. The error 'no healthy upstream' means the sidecar proxy cannot find any healthy instances of the upstream service. In a cross-datacenter setup with mesh gateways, this typically occurs when the upstream service is not registered or has no healthy instances in the remote datacenter. Other issues like missing gateway registration or deny intentions would produce different errors.

Answer

The 'web' service's sidecar proxy is not configured with the correct CA certificate.

Answer

The intention between 'web' and 'api' is set to 'deny'.

Answer

The mesh gateway is not registered as a service in Consul.

Question 14

A platform team runs a Consul 1.15 datacenter with Connect enabled. They deploy a new service called 'payments' and register it with a sidecar proxy. Security policy requires that only the 'checkout' service may initiate connections to 'payments', and all other services must be denied, even if they present a valid service token. No intentions exist yet for this pair. Which action should the team take to enforce this requirement with the least operational overhead?

Accepted Answer

Create an allow intention from 'checkout' to 'payments' and rely on the default deny behavior for all other sources.. Intentions are the Connect authorization mechanism, and Consul denies any connection that does not match an allow intention. Creating a single allow intention from checkout to payments satisfies the requirement because all other sources are denied by default. Adding a wildcard deny is redundant and complicates the intention set, while ACLs and proxy upstream settings address different concerns.

Answer

Configure the 'payments' sidecar proxy with a restrictive upstream and set 'protocol' to 'tcp' in the service registration.

Answer

Create a deny intention from '*' to 'payments' and a separate allow intention from 'checkout' to 'payments'.

Answer

Enable ACLs in default-deny mode and grant the 'payments' service token only to 'checkout'.

Question 15

A platform team is running Consul Connect with Envoy sidecar proxies. They need to ensure that a service named 'payments' can only be accessed by services in the 'frontend' namespace, and all other access must be denied. They have Consul Enterprise with namespaces enabled. Which intention configuration achieves this requirement with the least administrative overhead?

Accepted Answer

Create an intention that allows 'frontend/*' to 'payments' and set the default intention behavior to deny.. The most efficient way to allow only services from the 'frontend' namespace to access 'payments' is to create a single intention that allows 'frontend/*' to 'payments', and set the default intention behavior to deny. This leverages Consul Enterprise namespaces and wildcard intentions to minimize the number of intentions required. Other options either require many intentions, use the wrong feature, or are not supported.

Answer

Use a service-resolver configuration to restrict access to 'payments' based on the source namespace.

Answer

Configure the Envoy proxy for 'payments' with a network filter that allows only traffic from the 'frontend' namespace.

Answer

Create an intention that denies all sources to 'payments', then create individual allow intentions for each service in the 'frontend' namespace.