Consul 1.15 Multi Datacenter Federation Practice Test 2 — 15 Questions

Question 1

Which THREE features are critical for maintaining ACL consistency across datacenters?

Accepted Answer

Configuring an ACL replication token.. Option B is correct because configuring an ACL replication token (via acl.tokens.replication_token or the replication token in the ACL bootstrap) is required so secondary datacenters can authenticate and receive ACL updates from the primary. Option C is correct because enabling ACL replication on secondary servers (acl.enable_token_persistence and acl.replication enabled in the server configuration) allows those servers to actually pull and apply replicated ACL data. Option D is correct because designating a primary datacenter (primary_datacenter in the agent configuration) establishes the authoritative source from which ACLs are replicated to all other datacenters. Option A is wrong because disabling ACLs in the primary datacenter would break enforcement and prevent consistent replication, not maintain it. Option E is wrong because local KV store mirroring is unrelated to ACL replication and does not synchronize ACL policies, tokens, or roles across datacenters.

Answer

Disabling ACLs in the primary datacenter.

Answer

Configuring local KV store mirroring.

Question 2

Which TWO of the following are consequences of a primary datacenter outage in a federated environment?

Accepted Answer

Secondary datacenters cannot receive new ACL updates.. In a Consul federated environment, ACL updates are propagated from the primary datacenter to secondary datacenters, so when the primary datacenter suffers an outage, secondary datacenters can no longer receive new ACL updates (option A) and ACL policy updates cannot be performed at all (option C), since the primary datacenter is the authoritative source for ACL replication and token/policy changes. Service discovery does not stop immediately in all datacenters (option B) because secondary datacenters maintain their own local catalog and can continue resolving services for their local agents. Consul agents in the federation do not all crash (option D); agents continue running and serving local queries, only replication-dependent operations are affected. Existing cross-datacenter traffic routes do not automatically fail (option E) because established network paths and local service discovery remain functional; only new ACL-related updates are blocked.

Answer

Service discovery in all datacenters stops immediately.

Answer

All Consul agents in the federation crash.

Answer

Existing cross-datacenter traffic routes fail.

Question 3

A company is setting up a new secondary datacenter (dc2) to federate with an existing primary datacenter (dc1). They want to ensure that the WAN federation is secure and that services in dc2 can discover services in dc1. Which two configurations are required to enable WAN federation and cross-datacenter service discovery? (Choose two.)

Accepted Answer

Use retry_join_wan in the secondary datacenter's server agents to point to the primary datacenter's servers.. WAN federation requires the secondary datacenter's servers to join the primary's WAN gossip pool using retry_join_wan. Secure communication is ensured by enabling TLS verification (verify_outgoing and verify_server_hostname) on servers. These two configurations allow the datacenters to exchange catalog information, enabling cross-datacenter service discovery. Other options like Connect or primary_datacenter are not required for basic federation.

Answer

Configure the secondary datacenter's servers with the same encryption key for gossip as the primary datacenter.

Answer

Enable Connect in both datacenters and configure a mesh gateway in each datacenter to route cross-datacenter traffic.

Answer

Set the primary_datacenter configuration in the secondary datacenter's agents to the name of the primary datacenter.

Question 4

A Consul operator wants to join a new datacenter named 'dc2' to an existing datacenter 'dc1' using WAN federation. The servers in dc2 are started with retry_join_wan pointing to the LAN addresses of dc1's servers. However, the join fails and the logs show 'No installed keys could decrypt the message'. What is the most likely cause?

Accepted Answer

The gossip encryption key configured on dc2's servers does not match the key used by dc1's servers for WAN gossip.. WAN federation relies on a shared gossip encryption key across all datacenters. When the key on the joining datacenter's servers differs from the key used by the existing datacenter, the receiving servers cannot decrypt the gossip messages, leading to the 'No installed keys could decrypt the message' error. Verifying and synchronizing the gossip encryption key resolves the join failure.

Answer

The retry_join_wan addresses must use the Serf WAN port 8302 instead of the LAN port 8301.

Answer

The ACL replication token is missing from the dc2 server configuration, preventing secure communication.

Answer

The dc2 servers are not configured with a unique node name, causing conflicts during the join.

Question 5

A Consul operator is planning to federate three datacenters: dc1, dc2, and dc3. They want to ensure that the WAN gossip encryption key is consistent across all datacenters. Where should the WAN gossip encryption key be configured?

Accepted Answer

In the agent configuration of every server in each datacenter, using the encrypt_wan parameter.. The WAN gossip encryption key is set with the encrypt_wan parameter in the server agent configuration. All servers across federated datacenters must use the same key to securely communicate over the WAN gossip protocol. This ensures that only trusted servers can join the WAN pool. The LAN gossip key (encrypt) is separate and is used within each datacenter.

Answer

In the agent configuration of every client agent in each datacenter, using the encrypt parameter.

Answer

In the server's configuration using the primary_datacenter parameter, which propagates the key to all datacenters.

Answer

In the Consul KV store under the key 'wan/encrypt', which is automatically read by all servers.

Question 6

Your organization runs Consul in two datacenters: dc1 (primary) and dc2 (secondary). ACLs are enabled with default_policy = "deny". You need to allow a service in dc2 to read a KV path that exists in dc1. Cross-datacenter KV reads are not working. What is the most likely cause?

Accepted Answer

The service token lacks a policy that grants read access to the KV path in dc1.. In a federated Consul deployment with ACLs enabled, a token created in the secondary datacenter is local and is not replicated to the primary. To allow a service in dc2 to read a KV path in dc1, the token used must exist in dc1 and have a policy granting read access to that path. The policy must be replicated from the primary to the secondary if the token is used in dc2. The most likely cause is that the token lacks the necessary policy in dc1.

Answer

The service token in dc2 has not been replicated to dc1, so the ACL check fails.

Answer

The KV path must be explicitly exported from dc1 using a mesh gateway before it can be read from dc2.

Answer

The secondary datacenter must be promoted to primary before it can read KV data from the primary.

Question 7

You are deploying a new Consul secondary datacenter that must be able to forward DNS queries for the 'global' service to the primary datacenter. Which configuration on the servers in the new datacenter enables this behavior?

Accepted Answer

Set 'primary_datacenter' to the name of the primary datacenter and configure 'retry_join_wan' with the address of at least one server in the primary datacenter.. To enable a secondary datacenter to forward DNS queries for global services to the primary, the servers must know which datacenter is primary via 'primary_datacenter' and must be able to communicate over the WAN with at least one primary server using 'retry_join_wan'. This establishes the necessary federation for cross-datacenter service discovery.

Answer

Configure 'retry_join_wan' with the LAN addresses of the primary datacenter servers and set 'acl_datacenter' to the primary datacenter name.

Answer

Enable 'recursors' pointing to the primary datacenter's DNS servers and set 'domain' to the primary datacenter's domain.

Answer

Set 'datacenter' to 'global' on the new servers and enable 'translate_wan_addrs' on the primary datacenter.

Question 8

A Consul 1.15 operator is configuring a new datacenter to join an existing WAN federation. The existing datacenter has ACLs enabled, and the operator wants the new datacenter to replicate ACLs from the primary. Which two configuration items must be set on the new datacenter's servers to enable ACL replication? (Choose two.)

Accepted Answer

primary_datacenter. To enable ACL replication in a secondary datacenter, you must set primary_datacenter to identify the primary and acl_replication_token to authenticate to the primary. These two parameters allow the secondary to pull ACL data. The other options relate to gossip encryption, WAN joining, or ACL default policy, which are not sufficient for replication.

Answer

encrypt

Answer

acl_default_policy

Answer

retry_join_wan

Question 9

You are operating a Consul 1.15 cluster with three datacenters: dc1 (primary), dc2, and dc3. ACLs are enabled and replication is configured from dc1 to dc2 and dc3. You need to rotate the ACL replication token used by dc2 and dc3 without causing an outage. Which sequence of actions is correct?

Accepted Answer

On dc1, create a new replication token, then on dc2 and dc3 use the /v1/acl/token/self endpoint to update the replication token, or update the acl.tokens.replication configuration and reload the agents.. Rotating the ACL replication token without downtime involves creating the new token in the primary datacenter, then updating the secondary datacenters either via the ACL replication token API or by updating acl.tokens.replication and reloading the agents. This ensures continuous replication with the new token.

Answer

On dc1, create a new replication token, then update acl.tokens.replication_token in dc2 and dc3's server configurations, and restart the servers one at a time.

Answer

On dc2 and dc3, set acl.tokens.replication to the new token obtained from dc1, then use consul reload on each server to apply the change without restarting.

Answer

On dc1, delete the old replication token and create a new one, then on dc2 and dc3 set acl.tokens.replication to the new token and restart all servers simultaneously.

Question 10

A company operates Consul datacenters in three regions: us-east, eu-west, and ap-south. They want to enable ACL replication so that tokens and policies are consistent across all datacenters. The primary datacenter is us-east. Which configuration must be set on the servers in eu-west and ap-south to enable ACL replication?

Accepted Answer

Provide acl_replication_token with a token that has acl:read permissions, and ensure the servers can communicate with the primary datacenter's servers.. To enable ACL replication in secondary datacenters, you must configure acl_replication_token with a token that has acl:read permissions on the primary datacenter. The secondary servers also need network connectivity to the primary, which is typically established via WAN federation. Other parameters like primary_datacenter are not required for replication; they are used for other features such as intentions and CA management.

Answer

Set primary_datacenter to 'us-east' and configure acl_replication_token with a token that has acl:read permissions.

Answer

Set primary_datacenter to 'us-east' and provide acl_replication_token with a token that has acl:write permissions.

Answer

Set acl_datacenter to 'us-east' and provide acl_replication_token with a token that has acl:write permissions.

Question 11

You are designing a Consul deployment with a primary datacenter in us-east-1 and a secondary datacenter in eu-west-1. The operations team wants to ensure that if the primary datacenter becomes unreachable, the secondary datacenter can still authenticate services using ACLs and continue serving traffic. The secondary datacenter has been configured with acl_replication_token and is successfully replicating ACL data. However, after a primary failure, the secondary datacenter's ACLs stop working for new tokens. What is the most likely reason for this behavior?

Accepted Answer

The secondary datacenter cannot create new ACL tokens when the primary is unreachable because token creation requires forwarding to the primary datacenter.. ACL token creation and modification requests are always forwarded to the primary datacenter in a federated Consul environment. When the primary is unreachable, the secondary datacenter cannot create new tokens, though existing replicated tokens remain valid. This explains why new tokens fail while existing ACLs continue to work, matching the scenario's behavior.

Answer

The secondary datacenter's Consul servers have not been configured with the primary_datacenter setting, causing them to reject ACL tokens after failover.

Answer

The secondary datacenter's Consul servers have lost their WAN gossip connectivity to the primary datacenter, preventing ACL token validation.

Answer

The acl_replication_token used by the secondary datacenter was created with a limited TTL and has expired, causing replication to stop and new tokens to be rejected.

Question 12

You are using Consul 1.15 with ACLs enabled and have a primary datacenter (dc1) and a secondary datacenter (dc2). You want to replicate ACL policies and tokens from dc1 to dc2. Which configuration must be set on the Consul servers in dc2 to enable ACL replication?

Accepted Answer

`acl_replication_token` set to a token with `acl:read` permissions in dc1.. ACL replication in Consul is configured by setting `acl_replication_token` on the servers in the secondary datacenter. This token must be created in the primary datacenter with read access to ACLs (e.g., a token with `acl:read` policy). The `primary_datacenter` must also be set to the primary datacenter's name. Once configured, the secondary servers will periodically fetch ACL data from the primary, ensuring consistent ACL enforcement across datacenters.

Answer

`acl_replication_enabled` set to true and `acl_replication_token` set to a token with `acl:read` permissions.

Answer

`acl_replication_token` set to a token with `acl:write` permissions in dc1.

Answer

`primary_datacenter` set to dc1 and `acl_replication_token` set to a token with `acl:write` permissions.

Question 13

An operator is configuring a secondary datacenter that must replicate ACL tokens and policies from a primary datacenter. The primary uses a bootstrap token stored in Vault, and the secondary's servers are provisioned by an automated pipeline. Which approach correctly supplies the replication credentials on the secondary servers?

Accepted Answer

Set 'acl.tokens.replication' in the secondary servers' agent configuration files with a token that has 'acl:write' on the primary, or provide it via the 'CONSUL_ACL_REPLICATION_TOKEN' environment variable.. ACL replication is initiated and authenticated from the secondary side using a replication token that has privileges to read ACL data on the primary. On current Consul the token is set with 'acl.tokens.replication' in the server configuration, or supplied through the 'CONSUL_ACL_REPLICATION_TOKEN' environment variable, which suits automated provisioning where secrets come from a vault.

Answer

Set 'acl.tokens.agent' on the secondary servers to the primary's bootstrap token and enable 'acl.enable_token_persistence'.

Answer

Configure 'primary_datacenter' and 'retry_join_wan' on the secondary, since joining the WAN automatically replicates ACLs without any token.

Answer

Enable 'acl.replication.enabled' on the primary servers and let them push tokens to any joined secondary automatically.

Question 14

You are configuring a Consul agent in a new datacenter to join the existing WAN gossip pool. The existing datacenter's servers are listening on port 8302. You set retry_join_wan to a list of those server addresses. After starting the agent, you notice that the WAN gossip pool is not forming. Which configuration parameter must also be set correctly?

Accepted Answer

encrypt must be set to the same gossip encryption key used by the existing datacenter.. For WAN gossip to form, all participating agents must use the same gossip encryption key. The encrypt parameter must be set to the same base64-encoded key across all datacenters. While retry_join_wan provides the addresses to contact, without the correct encryption key the gossip messages are rejected. Other parameters like verify_outgoing or server are not substitutes for the shared key.

Answer

retry_join_wan must be set to the LAN addresses of the existing servers, not the WAN addresses.

Answer

verify_outgoing must be enabled to allow TLS verification for WAN gossip.

Answer

server must be set to true on the new agent to join the WAN gossip pool.

Question 15

You are setting up a new Consul datacenter that will join an existing WAN federation. Which TWO of the following are required to ensure secure and functional WAN gossip communication between the new datacenter and the existing one? (Choose two.)

Accepted Answer

The 'retry_join_wan' setting must be configured on at least one server in the new datacenter with the WAN address of a server in the existing datacenter.. For WAN gossip to function securely, all servers must share the same gossip encryption key ('encrypt'), and at least one server in the new datacenter must be configured with 'retry_join_wan' pointing to a WAN address of a server in the existing datacenter. These two settings enable the new datacenter to join the WAN gossip pool and communicate securely.

Answer

The 'datacenter' name must be unique across all datacenters in the federation.

Answer

The 'verify_outgoing' and 'verify_incoming' settings must be enabled with the same CA certificate on all servers.

Answer

The 'primary_datacenter' must be set to the name of the existing datacenter on all servers in the new datacenter.