Watches can be configured as part of the agent's configuration, causing them to run once the agent is initialized. Reloading the agent configuration allows for adding or removing watches dynamically.

https://developer.hashicorp.com/consul/docs/dynamic-app-config/watches

The configuration provided in the question is a prepared query. The name of the prepared query is retail-app, therefore the DNS record used to query this prepared query is retail-app.query.consul since all prepared queries use the query namespace.

Technically, you could access the service directly by using inventory-app.service.consul and it would connect the user directly to the inventory-app without taking the prepared query into account.

https://developer.hashicorp.com/consul/api-docs/query

You can register services either by providing a service definition, which is the most common way to register services, or by making a call to the HTTP API. While there are "other ways" to register a service, they are using either the API (such as defining a service with Terraform or Spring) or through the CLI using a service definition.

https://developer.hashicorp.com/consul/tutorials/get-started-vms/virtual-machine-gs-service-discovery#define-a-service

Create a new Consul service called app1 is permitted by the following rule since it's explicitly permitting it by name and the rule is allowing a write.

1. service "app1" {
2. policy = "write"
3. }

Run the consul members command to view server and client nodes in the cluster is permitted by the following command since consul members would require you to read information from any node in the cluster

1. node_prefix "" {
2. policy = "read"
3. }

Query any service registered to Consul to list the active clients for the service is permitted by the following rule since it permits a read on any service registered to Consul. If the rule was written as service_prefix ="web", you'd only be able to query a service named web.

1. service_prefix "" {
2. policy = "read"
3. }

Incorrect Answer:

Register any service on Consul would not be permitted unless there was a rule that allowed a write on service_prefix. This would likely be a bad idea since you wouldn't want just anybody to register a service with Consul. Bad actors with this permission could register a node with an existing service as an attempt to direct traffic to a compromised host.

Running the restore process should be straightforward. However, there are a couple of actions you can take to ensure the process goes smoothly. First, make sure the datacenter you are restoring is stable and has a leader. You can see this using consul operator raft list-peers and checking server logs and telemetry for signs of leader elections or network issues.

You will only need to run the process once, on the leader. The Raft consensus protocol ensures that all servers restore the same state.

https://developer.hashicorp.com/consul/tutorials/production-deploy/backup-and-restore#restore-from-backup

The Raft operator command is used to interact with Consul's Raft subsystem. Specifically, the list-peers command will display the current Raft peer configuration, which shows the state of each node, being either a leader or a follower.

https://developer.hashicorp.com/consul/commands/operator/raft#list-peers

By default, Consul will use the consul namespace unless changed in the configuration file. Any services that are registered with Consul are accessed via DNS using the standard <name>.service.consul.

https://developer.hashicorp.com/consul/tutorials/get-started-vms/virtual-machine-gs-service-discovery#dns-interface

A Consul server node will require three files:

 + one for the CA bundle, which would include any intermediate CAs (if applicable) and the root CA

 + the certificate that was created from the intermediate or root CA

 + the private key associated with the certificate

Example configuration:

https://developer.hashicorp.com/consul/tutorials/security/tls-encryption-secure#configure-the-servers

The following code would create a prepared query named web-app1

https://developer.hashicorp.com/consul/tutorials/developer-discovery/automate-geo-failover

------------------------------------------------------------------------

Incorrect Answers:

1) This is an ACL policy:

2) This is a Consul service configuration

3) This is a Sentinel policy

A service can have more than one defined health check to ensure that different aspects of the service is functioning as required. For example, you can have a simple TCP health check, along with script check that gathers additional information, such as memory utilization.

https://developer.hashicorp.com/consul/tutorials/developer-discovery/service-registration-health-checks