The configuration file is written for a Consul client, which is determined by the value of the server parameter. In this case, it's false, indicating it will not be a server, therefore it must be a Consul client.

Using retry_join, the client will automatically attempt to join a Consul client based upon the AWS tags specified. Alternatively, the retry_join could have been written to include the IP addresses of the Consul server nodes. However, because Consul servers are often treated as immutable, specifying IP addresses generally isn't scalable in a large environment as each client configuration file would need to be changed if new Consul nodes were provisioned.

Beyond the configuration file reference in the question, a second service definition file would be needed to register the actual service being hosted or provided by this client. The node_name provided indicates that this is a web server, so maybe the service definition file may register a front-end portal running on port 80 using Apache.

In Consul Connection, applications can use sidecar proxies (oftentimes referred to as sidecars) to establish TLS connectivity for inbound and outbound connection without even being aware of Connect at all. Applications are configured to communicate directly with the sidecar proxies, which permit or deny communication with other services within the organization if permitted.

https://developer.hashicorp.com/consul/docs/connect

Envconsul launches a subprocess that dynamically populates environment variables from secrets or data read from Vault or Consul. Your applications then read those environment variables.

https://github.com/hashicorp/envconsul

Consul can join a datacenter by using the cloud auto-join feature, which does automatic cluster joining using cloud metadata. In the configuration file above, the retry_join parameter states that the Consul agent should query AWS and discover instances that have a tag of consul with a value of true.

https://developer.hashicorp.com/consul/docs/agent/config/config-files#cloud-auto-joining

Consul Enterprise provides the ability to scale clustered Consul servers to include voting and non-voting servers. Non-voting servers still receive data from the cluster replication, however, they do not take part in quorum election operations. Expanding your Consul cluster in this way can scale reads without impacting write latency.

https://developer.hashicorp.com/consul/docs/enterprise/read-scale

Using the -stale command will permit any Consul server (non-leader) to respond to this request. This allows for lower latency and higher throughput but can result in stale data. This option has no effect on non-read operations.

https://developer.hashicorp.com/consul/commands/snapshot/save#stale

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

In this scenario, if you run consul members without a token and get a response, there can be only two reasons that it would immediately return the response.

1) the environment variable CONSUL_HTTP_TOKEN has already been set with a token with sufficient privileges

2) the anonymous token permits a read on the agent_prefix

The only other way this would work without a token is if the default_policy was set to "allow" or ACLs weren't enabled - both of which were specifically called out in the question.

https://developer.hashicorp.com/consul/docs/security/acl/acl-rules

This policy permits you to register a service using any name due to the service_prefix and the empty quotes. Empty quotes in a policy is sort of like a wildcard, meaning it doesn't have to match any specific value for it to be true.

https://developer.hashicorp.com/consul/docs/security/acl/acl-rules

Consul retains some additional metadata about the key-value pair. You can retrieve metadata (including the "flag" you set) using the -detailed command-line flag.

https://learn.hashicorp.com/consul/getting-started/kv

Since you are running the Consul Snapshot Agent, it is assumed you are running Consul Enterprise since the Consul Snapshot Agent is a feature of the Enterprise version. Also, since the Consul service itself is denying the snapshot agent permission to issue the snapshot, that implies that Consul ACLs have been enabled and are denying any requests that do not have a valid token. Lastly, the Consul Snapshot Agent should be assigned a service token (as shown below), which is associated with a policy, to permit the Snapshot Agent access to Consul to perform the snapshot.