HashiCorp Consul is a key tool for cloud engineers to demonstrate their skills in networking automation. The Consul Associate certification validates your understanding of the core principles involved in building, securing, and managing open-source Consul instances. With the knowledge of key concepts, you can ensure the secure and efficient deployment of distributed applications.
In this article, you will find a set of free practice questions designed to assess your readiness for the HashiCorp Consul Associate exam. These questions will help you gauge your understanding and prepare for the exam effectively.
Domain 1: Setting Up a Single Datacenter
Understanding the Configuration of Consul Client and the Role of Environment Variables
Consul, an open-source tool developed by HashiCorp, is widely used for service discovery, configuration management, and orchestration in modern infrastructure. One common question among users of Consul is how to configure the Consul client effectively. In particular, there is often confusion about whether environment variables can be used to configure the Consul client while executing CLI (Command Line Interface) commands to connect to a Consul agent.
To clarify this concept, let’s dive deeper into the role of environment variables in configuring a Consul client and distinguish between the configuration of the client itself and other operations like connecting to a running agent.
The Role of Environment Variables in Consul Operations
It is crucial to differentiate between configuring the Consul client and using environment variables for other purposes in Consul’s operations. While environment variables play a vital role in customizing certain aspects of Consul’s behavior, they are not directly used to configure the Consul client itself.
Environment variables in the context of Consul are typically used for configuring aspects like authentication tokens, address details of a running agent, or setting default values that can be accessed by Consul during the execution of CLI commands. These variables allow users to adjust how they interact with a Consul agent but do not alter the configuration of the Consul client directly.
What Are Environment Variables Used for in Consul?
In the Consul ecosystem, environment variables serve as a mechanism to define specific parameters when interacting with a Consul agent or performing specific actions within the environment. Here are a few examples of how environment variables can be used:
- Consul Address and Port: Environment variables can be set to specify the address and port where the Consul agent is running. For instance:
- CONSUL_HTTP_ADDR can be used to set the address for HTTP communication with the Consul agent.
- CONSUL_AGENT_PORT specifies the port on which the agent is available.
- Token Authentication: For security purposes, tokens can be defined in environment variables to authenticate CLI operations with a Consul agent. The environment variable CONSUL_HTTP_TOKEN can store the authentication token that the client will use when interacting with Consul.
- TLS Configuration: Consul supports secure communication, and environment variables can be used to specify TLS certificates and keys needed for secure connections, such as CONSUL_CACERT, CONSUL_CERT, and CONSUL_KEY.
- Consul Datacenter: When working in a multi-datacenter setup, the CONSUL_DATACENTER environment variable can be used to specify which datacenter the client should connect to.
These variables do not directly affect the internal configuration of the Consul client but are essential for ensuring smooth and secure interactions between the client and the agent. The client, which is typically installed and initialized on a local machine or server, may also rely on other configuration files, like consul.hcl, for further tuning and customization.
Why Environment Variables Do Not Configure the Consul Client
The core configuration of the Consul client, including aspects like the client’s behavior, storage backends, and other low-level settings, is primarily handled through configuration files (such as consul.hcl or JSON files) and through command-line flags when starting Consul. Environment variables are intended to provide flexibility in adjusting runtime parameters, but they are not meant to fundamentally alter how the client itself operates.
Thus, when running Consul CLI commands, the environment variables facilitate the connection and communication between the client and an agent, but they do not define the core parameters or behavior of the Consul client.
Key Takeaways
- Environment variables play a significant role in setting parameters like agent addresses, authentication tokens, and TLS configurations, but they are not used to configure the Consul client itself.
- The configuration of the Consul client is typically done via configuration files or command-line flags, not environment variables.
- Environment variables are especially helpful for connecting to a running Consul agent or defining runtime preferences, but they don’t affect the internal workings of the Consul client.
In summary, the statement that environment variables can be used to configure the Consul client while running CLI commands to connect to an agent is False. Instead, environment variables are mainly employed for facilitating the connection between the Consul client and agent or adjusting certain operational parameters, not for altering the client’s internal configuration.
By understanding the correct usage of environment variables in the context of Consul, users can make more informed decisions when setting up and managing their Consul environment, ensuring they utilize the correct tools and practices to optimize their infrastructure.
Running a Consul Agent in Development Mode: A Detailed Explanation
Consul, a widely used tool in the domain of service discovery, infrastructure management, and microservices orchestration, offers various operational modes to simplify its deployment and usage. One such mode is the development mode, which is especially useful for developers who need a lightweight, easy-to-use Consul setup for testing or development purposes.
In this article, we will dissect a specific Consul CLI command:
consul agent -data-dir=/tmp/consul -dev
This command is used to run a Consul agent in development mode, and understanding its various components and functionality is key to using it correctly. Let’s break down what each part of the command does and which statements are correct based on its usage.
Breaking Down the Command
The given command has two primary components:
- consul agent: This tells Consul to start an agent process, which is a core component that handles service discovery and management tasks in a Consul cluster.
- -data-dir=/tmp/consul: This option specifies the directory where the agent should store its state and other data files.
- -dev: This flag tells the Consul agent to run in development mode, which simplifies the setup for testing purposes.
Now let’s take a closer look at the individual statements to see which ones are true.
A. Starts the Agent on the Local Instance
This statement is True. When the command is run, it initializes a Consul agent process on the local instance. In development mode, Consul runs in a single-node setup, which is typically used for testing, local development, and other lightweight environments. Therefore, the agent is started locally, and it does not require any external or remote infrastructure for operation.
B. The Agent Reads Configuration Files from /tmp/consul
This statement is False. The command specifies the directory for storing agent data (-data-dir=/tmp/consul), but it does not indicate that the agent is reading configuration files from this directory. In development mode, Consul does not require or use external configuration files. It uses built-in defaults for configuration, meaning that any custom configuration files (such as .hcl or .json files) are not needed or read by the agent.
The /tmp/consul directory is purely for storing runtime data, including logs and state information, but it does not serve as a configuration directory.
C. Runs the Agent in Development Mode
This statement is True. The -dev flag is what triggers Consul to run in development mode. In this mode, Consul behaves in a simplified, single-node configuration, where it automatically joins a default cluster. This is ideal for testing, development, and other non-production use cases where a full multi-node cluster is not necessary.
In development mode, Consul skips certain production-oriented features like clustering and multi-datacenter configurations, making it easier to spin up a working instance for quick tests or demonstrations.
D. Stores Agent Data in /tmp/consul
This statement is True. The -data-dir option specifies the directory where the Consul agent will store its local data. In this case, it is set to /tmp/consul. This directory will contain the agent’s state files, logs, and other necessary data that the Consul agent uses during its operation. This storage is temporary and typically used for testing or short-lived setups in development environments.
E. Saves Agent Details in the Local Instance
This statement is False. The command does not save agent details in the “local instance” in the sense that it persists permanent information about the agent outside of the /tmp/consul directory. The use of /tmp implies that the data is temporary and is not meant to be retained long-term.
Furthermore, in development mode, the Consul agent operates as a single-node instance, and while it maintains state within its local directory (/tmp/consul), the agent does not save permanent details about the instance that would survive across different sessions or environments. Once the agent is stopped or the machine is restarted, the data in /tmp/consul is often cleared out.
Correct Answers: A, C, D
- A. Starts the agent on the local instance. – Correct. The agent runs locally in a development environment.
- C. Runs the agent in development mode. – Correct. The -dev flag ensures that Consul runs in development mode, which is ideal for testing and experimentation.
- D. Stores agent data in /tmp/consul. – Correct. The -data-dir flag specifies the directory where agent data, such as state files and logs, is stored.
Understanding Script-Based Health Checks in Consul and the Correct Configuration Option
Consul is widely known for its health checking capabilities, which allow for monitoring and managing the health of services in real-time. One of the most versatile and customizable types of health checks is the script-based health check. This enables users to define custom scripts that can run on the local system, ensuring that the Consul agent is aware of the state of a service or application. However, to enable these health checks locally, there are specific configuration settings that must be adjusted.
In this article, we will explore the correct option for enabling script-based health checks and explain the significance of this feature in maintaining service reliability.
Script-Based Health Checks in Consul
A health check in Consul refers to a mechanism that allows the system to determine whether a service is up and running as expected. Consul supports several types of health checks, such as HTTP, TCP, and script-based checks. The script-based health checks are highly flexible because they allow you to write custom scripts that will execute on the local agent and provide the results that the agent can use to assess the health of a service.
These checks can be used to evaluate a wide variety of conditions, such as checking whether a particular process is running, verifying the existence of files, or running specific diagnostic commands. They are defined locally on the machine where the Consul agent is running and can be an essential tool in environments with complex, non-standard service health requirements.
Enabling Script-Based Health Checks: The Correct Option
To enable script-based health checks in local configurations, Consul provides a configuration option that must be set to true. Below are the available options and their meanings.
A. enable_script_checks
This option is incorrect because enable_script_checks does not exist as a valid configuration option in Consul for enabling local script-based health checks. There is no such setting in the Consul documentation for script-based health checks.
B. enable_local_script_checks
This option is correct. The enable_local_script_checks configuration option is specifically used to enable script-based health checks defined locally. When this option is set to true, the Consul agent will allow the execution of custom script-based checks that are defined in its configuration. This is the correct way to enable such checks in a local environment.
C. allow_script_checks
This option is incorrect because allow_script_checks is not a valid configuration option in Consul. There is no option with this name in the Consul documentation for enabling script-based checks.
D. allow_local_script_checks
This option is also incorrect because allow_local_script_checks is not a valid configuration option in Consul either. There is no such setting in the current version of Consul for enabling script-based health checks.
Correct Answer: B. enable_local_script_checks
The correct answer to this question is B. enable_local_script_checks. This is the option that enables the execution of script-based health checks defined locally within a Consul agent’s configuration.
Why enable_local_script_checks?
The reason enable_local_script_checks is the correct answer is that it directly corresponds to a configuration setting in Consul that governs the execution of local script-based health checks. By setting this option to true, you inform the Consul agent to run the specified script and use its output as the health status for the service being monitored.
This feature is particularly useful when you need to monitor services that may not have a native HTTP or TCP interface to check but can be verified using shell scripts or other local system tools.
Example Usage in Configuration
To enable script-based health checks in Consul, you would typically include the following line in your Consul configuration file (consul.hcl):
enable_local_script_checks = true
Once this setting is enabled, you can define a script-based health check in your service definition. For instance:
check {
id = “my-script-check”
name = “Script Check”
script = “/path/to/your/script.sh”
interval = “10s”
}
In this example:
- script points to the custom script you want to execute.
- interval defines how often Consul will run the script to check the health of the service.
In Consul, enabling local script-based health checks is an important step when dealing with complex or custom service health verification that cannot be easily captured by basic HTTP or TCP checks. The configuration option enable_local_script_checks is the correct way to allow these types of checks. By setting this option in your Consul configuration, you ensure that the Consul agent can execute and interpret the results of custom scripts, enabling you to maintain reliable and customized health monitoring for your services.
Thus, the correct configuration option is B. enable_local_script_checks, and understanding this setting will help ensure that your Consul-based health checks are appropriately set up to handle non-standard service verification scenarios.
Troubleshooting Consul Agent Connection Error: Resolving the Malformed HTTP Response
When working with Consul in a distributed environment, network connectivity and configuration issues can occasionally cause errors that impede communication between agents. One such error occurs when trying to connect to a Consul agent configured for HTTPS using an HTTP connection, leading to a malformed HTTP response. This can cause the following error:
Error querying agent: malformed HTTP response
Net/http: HTTP/1.x transport connection broken: malformed HTTP response “\x15\x03\x01\x00\x02\x02”
This error is typically caused by attempting to communicate with a Consul agent over an insecure connection (HTTP) while the agent is set up to use a secure connection (HTTPS). Let’s break down the possible causes and the fixes to resolve this issue.
Understanding the Error Message
The error message indicates that there was an issue with the HTTP response from the Consul agent. The string \x15\x03\x01\x00\x02\x02 is part of the TLS (Transport Layer Security) handshake, which is typical when trying to establish a secure HTTPS connection but mistakenly using an insecure HTTP protocol.
In simple terms, this error arises when:
- A secure connection (HTTPS) is required, but an insecure connection (HTTP) is being used.
- Consul agents or clients configured for HTTPS cannot respond correctly to HTTP requests, causing the malformed response error.
Troubleshooting Steps and Fixes
The main issue here is that the connection is trying to use HTTP to communicate with an agent that expects HTTPS. To resolve this, you need to ensure that the connection uses HTTPS, both in the command-line flags and environment variables. Here are the possible fixes:
A. Use “https” in the -http-addr Flag
This fix is correct. The -http-addr flag is used to specify the address for Consul’s HTTP API. If your Consul agent is configured to use HTTPS, you need to ensure that you specify the https:// scheme in this flag.
For example, if the agent is running on port 8501 (typically the default HTTPS port for Consul), you would use the following command:
consul agent -http-addr=https://127.0.0.1:8501
By explicitly specifying https:// in the -http-addr flag, you ensure that the agent communicates over a secure HTTPS connection, avoiding the malformed response error.
B. Use “https” in the CONSUL_HTTP_ADDR Environment Variable
This fix is also correct. The CONSUL_HTTP_ADDR environment variable is used by the Consul client to specify the HTTP address of the Consul agent. If the agent is running with HTTPS, you need to set this environment variable to use the https:// scheme.
For example:
export CONSUL_HTTP_ADDR=”https://127.0.0.1:8501″
This will configure your Consul client to connect to the agent using a secure connection (HTTPS), which will resolve the issue of trying to connect using HTTP.
C. Use “https” in the CONSUL_HTTP_SSL Environment Variable
This fix is incorrect. The CONSUL_HTTP_SSL environment variable does not exist in Consul’s documentation. There is no specific environment variable for setting SSL or HTTPS via the CONSUL_HTTP_SSL variable. Therefore, using this variable will not resolve the issue.
Instead, the correct variables to use are CONSUL_HTTP_ADDR (for the address) and -http-addr (for the command-line flag).
D. Change the URI Scheme to “https”
This fix is correct. Changing the URI scheme to https:// is the key step in resolving this issue. If you are manually configuring the agent or the client, ensure that the URL or address used to communicate with the agent specifies HTTPS. This can be done by using https:// in the address or URI for both the client and the agent.
For example, ensure your Consul command, configuration file, or environment variable references https:// instead of http:// when specifying the address.
E. Use “https” in the CONSUL_HTTP_AUTH Environment Variable
This fix is incorrect. The CONSUL_HTTP_AUTH environment variable is not used to configure HTTPS connections. Instead, authentication-related settings are typically handled through CONSUL_HTTP_TOKEN or other authentication mechanisms in Consul, but they do not affect the protocol (HTTP vs. HTTPS). Therefore, changing the CONSUL_HTTP_AUTH variable will not resolve the malformed HTTP response error.
Correct Answers: A, B, D
To summarize, the correct fixes for this error are:
- A. Use “https” in the -http-addr flag.
- B. Use “https” in the CONSUL_HTTP_ADDR environment variable.
- D. Change the URI scheme to “https”.
The error occurs because the Consul agent is configured to use HTTPS, but the connection attempt is made over HTTP. To fix this, you must ensure that the address and scheme used in the connection are set to HTTPS. This can be done by adjusting the following:
- Command-line flags like -http-addr should specify https:// in the address.
- Environment variables like CONSUL_HTTP_ADDR should include the https:// scheme to ensure that the client uses HTTPS to connect to the agent.
By implementing these changes, you ensure that the connection is made securely over HTTPS, thus preventing the malformed HTTP response error from occurring.
Domain 2: Service Registration and Discovery
Joining a Consul Datacenter with Cloud Metadata: A Detailed Explanation
Consul, developed by HashiCorp, is widely used for service discovery, configuration management, and orchestrating microservices in distributed systems. In environments where resources are dynamically provisioned (such as in cloud environments), it is often beneficial for Consul agents to automatically discover and join a datacenter based on cloud metadata.
The ability to use cloud metadata for automatic joining of a Consul datacenter helps to streamline the setup and maintenance of Consul agents in cloud-native environments. This reduces the need for manually specifying IP addresses or hardcoding cluster details, as the Consul agent can leverage metadata provided by the cloud infrastructure to automatically join the correct datacenter.
Let’s break down the correct approach to achieving this, and identify the right command to enable a Consul agent to automatically join a datacenter using cloud metadata.
Understanding Cloud Metadata and the retry-join Flag
In cloud environments like AWS, Azure, and Google Cloud, each instance or resource (such as a VM or container) is typically associated with metadata that provides details about the instance, such as its IP address, region, and other configuration settings. Consul leverages this metadata to automatically join the appropriate datacenter.
The key option that facilitates this automatic joining is the -retry-join flag. As of Consul 0.9.1, this flag was enhanced to support automatic cloud metadata joining. When using this feature, you specify a key-value pair format in the -retry-join argument that contains cloud-specific metadata, allowing the Consul agent to find and join the correct datacenter.
Review of the Command Options
Now, let’s review each of the given options and see which one correctly enables a Consul agent to join a datacenter using cloud metadata.
A. consul join <ip_address> -metadata=”provider=my-cloud config=val”
This command is incorrect. The consul join command is used to join an existing Consul agent by specifying its IP address or hostname. However, the -metadata flag is not part of the consul join command syntax. The metadata and cloud-specific information should be included with the -retry-join flag, not -join.
B. consul agent -retry-join “consul.domain.internal” -retry-join “<ip_address>”
This command is incorrect. While it uses the correct -retry-join flag, it does not incorporate the cloud metadata for automatic joining. The -retry-join flag here is simply specifying an address or hostname for joining, not cloud metadata. Additionally, using multiple -retry-join flags is redundant and does not align with the expected syntax.
C. consul agent -retry-join ‘provider=my-cloud config=val config2=some other val’
This command is correct. As of Consul 0.9.1, the -retry-join flag supports the use of key-value pairs for cloud metadata, which enables the Consul agent to automatically join a datacenter based on cloud configuration. The correct syntax for specifying cloud metadata is indeed in the key-value format (e.g., provider=my-cloud config=val). This allows Consul to query cloud APIs or metadata services to discover the proper datacenter and join it accordingly.
D. consul agent -join <ip_address> -metadata=”provider=my-cloud config=val”
This command is incorrect. The -join flag is used for specifying a specific Consul agent to join a datacenter, but it does not support cloud metadata in the way described. Cloud metadata should be provided using the -retry-join flag with the appropriate key-value format, not the -join flag.
Correct Answer: C. consul agent -retry-join ‘provider=my-cloud config=val config2=some other val’
Explanation of the Correct Command
The correct command is:
consul agent -retry-join ‘provider=my-cloud config=val config2=some other val’
Here’s why this is the correct approach:
- The -retry-join flag is designed for specifying cloud metadata to automatically discover and join a Consul datacenter.
- The key-value pair format (provider=my-cloud config=val config2=some other val) is used to specify cloud-specific configuration options.
- This enables the Consul agent to retrieve the necessary metadata, often from cloud APIs or metadata services, and join the appropriate datacenter based on the cloud provider’s metadata (e.g., AWS, Azure, GCP).
This syntax is supported from Consul 0.9.1 onward, which introduced enhanced capabilities for automatically joining a datacenter using cloud metadata.
Key Takeaways
- The -retry-join flag is essential for automatic joining of a Consul agent to a datacenter, especially in cloud environments.
- Cloud metadata, such as provider-specific configurations, is provided in a key-value format within the -retry-join flag.
- The correct command uses the key-value pair format in the -retry-join flag to enable automatic joining based on cloud metadata.
In summary, option C is the correct command because it leverages the enhanced -retry-join flag introduced in Consul 0.9.1 for joining a datacenter using cloud metadata. This command helps streamline Consul agent setup in dynamic cloud environments, where the datacenter joining process can be automated using metadata provided by the cloud provider.
Joining a Consul Agent to an Existing Cluster: Correct Configuration Options
When setting up a new Consul agent to join an existing cluster, proper configuration is key to ensuring that the agent can successfully connect to other servers in the datacenter. One of the most important configuration options in this process is the retry-join flag, which allows the agent to attempt to connect to a list of existing Consul servers (specified by their IP addresses or hostnames). This is a common practice for deploying new agents into a running Consul cluster.
Available Configuration Options and Analysis
Let’s examine the given options and explain why some of them are correct and others are not.
A. consul agent -retry-join=52.10.110.11 -retry-join=52.10.110.12 -retry-join=52.10.110.13
This command is correct. The -retry-join flag is used to specify the IP addresses of the existing Consul servers that the new agent should attempt to join. Each IP address provided after the -retry-join flag is a target for the agent to connect to, and it will keep retrying to join those addresses until it successfully connects.
Here’s how it works:
- -retry-join specifies the list of Consul servers the agent should try to join.
- The command uses multiple -retry-join flags, each specifying a different server IP address (52.10.110.11, 52.10.110.12, 52.10.110.13).
- The agent will continuously try to connect to these IP addresses in case of failure.
This is a valid configuration for joining a cluster via the command line.
B. bootstrap = false, bootstrap_expect = 3, server = true, retry_join = [“52.10.110.11”, “52.10.110.12”, “52.10.110.13”]
This option is correct. This configuration appears to be part of a Consul agent configuration file (likely consul.hcl). Here’s the breakdown:
- bootstrap = false: This setting indicates that the agent is not the first server in the cluster and thus does not need to bootstrap the datacenter.
- bootstrap_expect = 3: This setting specifies that there should be 3 servers in the cluster. This is important for Consul to know when it has enough servers to form a quorum.
- server = true: This marks the agent as a server in the Consul cluster, which is required for it to participate in consensus and maintain cluster state.
- retry_join = [“52.10.110.11”, “52.10.110.12”, “52.10.110.13”]: This specifies the IPs of the existing Consul servers that the new agent will try to join. It is written in the correct HCL (HashiCorp Configuration Language) format for Consul’s configuration file.
This option is correct for setting up a Consul agent to join an existing cluster via the configuration file.
C. retryjoin = [“52.10.110.11”, “52.10.110.12”, “52.10.110.13”]
This option is incorrect. The flag retryjoin is not a valid configuration key in Consul. The correct key for this purpose is retry_join (note the underscore). This could be a typo, and because of this, it will not work as expected. Therefore, this option is not valid.
D. consul agent -join=52.10.110.11 -join=52.10.110.12 -join=52.10.110.13
This command is incorrect. While -join is a valid flag, it is used to specify a Consul agent that should be joined directly, and it does not support multiple values. You would typically use -join to connect to a single existing Consul agent. The -retry-join flag, on the other hand, is used when you want to attempt joining multiple servers, which is more appropriate in this case.
Using -join in this way is not ideal for trying to connect to multiple servers, as it would only allow the agent to connect to the first server and would not retry the connection automatically if the initial server is unavailable.
Correct Answers: A, B
The correct configurations for joining a Consul agent to an existing cluster using the given IP addresses are:
- A. consul agent -retry-join=52.10.110.11 -retry-join=52.10.110.12 -retry-join=52.10.110.13: This is correct for the CLI approach, specifying multiple -retry-join flags for different server IP addresses.
- B. bootstrap = false, bootstrap_expect = 3, server = true, retry_join = [“52.10.110.11”, “52.10.110.12”, “52.10.110.13”]: This is correct for the configuration file approach, where the retry_join option is used with the proper HCL syntax.
Final Explanation
When configuring a Consul agent to join an existing cluster, you can use the -retry-join flag to specify multiple Consul server IPs to connect to. This flag can either be provided in the CLI or in the configuration file.
- In the CLI, use -retry-join multiple times, one for each IP address.
- In the configuration file, use the retry_join option with a list of IPs (in JSON-like syntax, i.e., [“ip1”, “ip2”, “ip3”]).
This ensures that the new agent will attempt to connect to any of the provided IPs, retrying if necessary until it successfully joins the cluster.
Option C is incorrect due to a typo in the flag name (retryjoin instead of retry_join), and option D is incorrect because -join is not suited for specifying multiple addresses in this context.
Domain 3: Access Control Lists (ACLs) and Security
Question 7: Endpoint to Retrieve ACL Replication Status
Given the following request:
curl –request GET http://127.0.0.1:8500/v1/acl/_________
Which endpoint returns the replication status?
- A. replicate
- B. replication
- C. replica
- D. auth/replicate
Correct Answer: B
Explanation: The /acl/replication endpoint retrieves the status of the ACL replication process in the datacenter.
Question 8: Methods to Pass Consul Token in API Requests
Which of the following methods can be used to send the Consul token in HTTP requests?
- A. Consul-Token : <consul token>
- B. Authorization : Bearer <consul token>
- C. ?token = query parameter
- D. X-Consul-Token : <consul token>
- E. Authorization : Token <consul token>
Correct Answers: B, C, D
Explanation: The correct ways to send a Consul token are via the Authorization header using Bearer token format, the X-Consul-Token header, or the ?token query parameter. Option E is syntactically incorrect.
Question 9: Storing Consul Token in an Environment Variable
Which environment variable is used to store the Consul token?
- A. CONSUL_HTTP_TOKEN_FILE
- B. CONSUL_SECRET_TOKEN
- C. CONSUL_HTTP_AUTH
- D. CONSUL_HTTP_TOKEN
Correct Answer: D
Explanation: The CONSUL_HTTP_TOKEN environment variable is used to store the Consul API access token when ACLs are enabled.
Question 10: Default Privileges of the Bootstrap Token
By default, the bootstrap token in Consul is assigned the global-management policy, which has limited privileges that cannot be modified.
- True
- False
Correct Answer: False
Explanation: The bootstrap token is assigned the global-management policy with unrestricted privileges, not limited ones. It is intended for emergency situations.
Question 11: Persisting ACL Tokens in Consul
What must be enabled to ensure ACL tokens are saved permanently?
- A. By setting the flag acl_token_replication to true.
- B. By setting the flag enable_token_replication to true.
- C. By setting the flag enable_token_persistence to true.
- D. By setting the flag acl_token_persistence to true.
Correct Answer: C
Explanation: The enable_token_persistence flag ensures that ACL tokens are persisted to disk, so they are reloaded when the agent restarts.
Domain 4: Secure Agent Communication
Question 12: Troubleshooting TLS Certificate Errors
You encounter errors like tls: bad certificate and X509: certificate signed by unknown authority. What steps would you take to resolve them?
- A. Check that the clients and servers are using the correct certificates.
- B. Verify that certificates are in the /etc/consul/directories directory with proper permissions.
- C. Use the consul tls cert verify command to check certificate details.
- D. Ensure that the certificates are signed by the same CA.
- E. Verify the server certificates include the server.dc1.consul in the SAN field.
Correct Answers: A, D, E
Explanation: To resolve certificate issues, you must ensure the certificates are correctly signed by the same CA and include the proper SAN fields.