diff --git a/website/content/docs/concepts/filtering/worker-tags.mdx b/website/content/docs/concepts/filtering/worker-tags.mdx
index ee204c58fd..9b1e7aadc2 100644
--- a/website/content/docs/concepts/filtering/worker-tags.mdx
+++ b/website/content/docs/concepts/filtering/worker-tags.mdx
@@ -41,9 +41,9 @@ As HCL is JSON-compatible, this turns into an input JSON value of:
}
```
-~> **Note:** This is the canonical format, as it maps closely to the filter
-structure. However, for compatibility with some other systems, it is also
-possible to specify the tags in a pure key=value style:
+This is the canonical format, as it maps closely to the filter structure.
+However, for compatibility with some other systems, it is also possible to
+specify the tags in a pure key=value style:
```hcl
worker {
@@ -76,7 +76,7 @@ worker {
}
```
-Note that the syntax within the environment variable / file changes
+Notice that the syntax within the environment variable / file changes
slightly depending on how the configuration file is set:
For setting the entire `tags` block, both the keys and values need
@@ -117,12 +117,12 @@ nested under `tags` and include a `name` value:
}
```
-~> **Note:** If an expression fails due to a key not being found within the input data,
-the worker is not included in the final set, so ensure that all workers that
-should match a given filter are populated with tags referenced in the filter
-string. As a corollary, it is not possible to distinguish between a worker that
-is not included due to the expression itself and a worker that did not have
-correct tags.
+
+
+ If an expression fails due to a key not being found within the input data,
+the worker is not included in the final set. You should ensure that all workers that should match a given filter are populated with tags referenced in the filter string. It is not possible to distinguish between a worker that is not included due to the expression itself and a worker that did not have correct tags.
+
+
## Filter examples
@@ -135,8 +135,11 @@ Following are some examples of using these values in filters that can be applied
- Grouping: `("us-east-1" in "/tags/region" and "/name" == "web-prod-us-east-1") or "webservers" in "/tags/type"`
-~> **Note:** Each tag can have multiple values, so the `in` operator must be used to match values.
-If you know that you have only one value, an equivalent would be `"/tags/key/0" == "value"`.
+
+
+ Each tag can have multiple values, so the `in` operator must be used to match values. If you know that you have only one value, an equivalent would be `"/tags/key/0" == "value"`.
+
+
### Example worker filter for targets
@@ -176,6 +179,7 @@ resource "boundary_target" "aws-webservers-prod" {
name = "aws-web-prod"
description = "AWS EC2 Targets"
egress_worker_filter = "\"prod\" in \"/tags/type\""
+}
```
@@ -192,8 +196,11 @@ This allows the use of private Vault instances with Boundary. Workers
deployed in the same network as a private Vault instance can access and relay
Vault requests to Boundary controllers.
- ~> **Note:** A worker that matches the worker filter must exist before defining the Vault credential store, as it
- will perform the Vault calls needed to set up the credential store with Boundary.
+
+
+ A worker that matches the worker filter must exist before defining the Vault credential store, as it will perform the Vault calls needed to set up the credential store with Boundary.
+
+
[workers]: /boundary/docs/configuration/worker/worker-configuration
[credential stores]: /boundary/docs/concepts/domain-model/credential-stores#vault-credential-store-attributes
@@ -262,6 +269,7 @@ resource "boundary_storage_bucket" "aws_dynamic_credentials_example" {
scope_id = boundary_scope.org.id # change to valid scope ID
plugin_name = "aws"
bucket_name = "mybucket" # change to valid AWS S3 storage bucket name
+
# the role_arn value should match the arn used as the instance profile attached to the ec2 instance
# https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html
attributes_json = jsonencode({