diff --git a/docs/pages/access-controls/reference.mdx b/docs/pages/access-controls/reference.mdx
index 007afd0bc51c3..cb064c718f0e2 100644
--- a/docs/pages/access-controls/reference.mdx
+++ b/docs/pages/access-controls/reference.mdx
@@ -152,10 +152,10 @@ Label              | `v3` Default   | `v4` and `v5` Default
 `kubernetes_labels` | `[{"*": "*"}]` | `[]`
 `database_labels`   | `[{"*": "*"}]` | `[]`
 
-## RBAC for hosts
+## RBAC for resources
 
-A Teleport role can also define which hosts (nodes) a user can have access to.
-This works by [labeling nodes](../management/admin/labels.mdx) and listing
+A Teleport role defines which resources (e.g., applications, servers, and databases) a user can have access to.
+This works by [labeling resources](../management/admin/labels.mdx) and listing
 allow/deny labels in a role definition.
 
 Consider the following use case:
@@ -189,16 +189,26 @@ spec:
       'workload': ['database', 'backup']
 ```
 
+Teleport handles multiple label entries with logical "AND" operations.
+As an example this entry would match to databases that have the `env: prod` label and a
+`region` label of either `us-west-1` or `eu-central-1`:
+
+```yaml
+    db_labels:
+      'env': 'prod'
+      'region': ['us-west-1', 'eu-central-1']
+```
+
 <Admonition
   type="tip"
   title="Dynamic RBAC"
 >
-  Node labels can be dynamic, i.e. determined at runtime by an output of an executable. In this case, you can implement "permissions follow workload"
+  Resource labels can be dynamic, i.e. determined at runtime by an output of an executable. In this case, you can implement "permissions follow workload"
   policies (eg., any server where PostgreSQL is running becomes *automatically*
   accessible only by the members of the "DBA" group and nobody else).
 </Admonition>
 
-### Extended Node labels syntax
+### Extended labels syntax
 
 Below are a few examples for more complex filtering using various regexes.