diff --git a/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-overview.md b/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-overview.md
index 717a250e3..de132d9a4 100644
--- a/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-overview.md
+++ b/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-overview.md
@@ -41,7 +41,7 @@ Applications can also use the secrets API to access secrets from a Kubernetes se
 - The Helm defaults, or
 - `dapr init -k`
 
-If you are using another secret store, you can disable (not configure) the Dapr Kubernetes secret store by setting `disable-builtin-k8s-secret-store` to `true` through the Helm settings. The default is `false`.
+If you are using another secret store, you can disable (not configure) the Dapr Kubernetes secret store by adding the annotation `dapr.io/disable-builtin-k8s-secret-store: "true"` to the deployment.yaml file. The default is `false`.
 
 In the example below, the application retrieves the same secret "mysecret" from a Kubernetes secret store.
 
@@ -86,4 +86,4 @@ Want to skip the quickstarts? Not a problem. You can try out the secret manageme
 ## Next steps
 
 - Learn [how to use secret scoping]({{< ref secrets-scopes.md >}}).
-- Read the [secrets API reference doc]({{< ref secrets_api.md >}}).
\ No newline at end of file
+- Read the [secrets API reference doc]({{< ref secrets_api.md >}}).
diff --git a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-rabbitmq.md b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-rabbitmq.md
index 56c2a2683..a59139793 100644
--- a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-rabbitmq.md
+++ b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-rabbitmq.md
@@ -207,9 +207,15 @@ For example, if installing using the example above, the RabbitMQ server client a
 
 ## Use topic exchange to route messages
 
-Setting `exchangeKind` to `"topic"` uses the topic exchanges, which are commonly used for the multicast routing of messages.
-Messages with a `routing key` will be routed to one or many queues based on the `routing key` defined in the metadata when subscribing.
-The routing key is defined by the `routingKey` metadata. For example, if an app is configured with a routing key `keyA`:
+Setting `exchangeKind` to `"topic"` uses the topic exchanges, which are commonly used for the multicast routing of messages. In order to route messages using topic exchange, you must set the following metadata:
+
+- **`routingKey`:**  
+   Messages with a routing key are routed to one or many queues based on the `routing key` defined in the metadata when subscribing.
+
+- **`queueName`:**  
+   If you don't set the `queueName`, only one queue is created, and all routing keys will route to that queue. This means all subscribers will bind to that queue, which won't give the desired results.
+
+For example, if an app is configured with a routing key `keyA` and `queueName` of `queue-A`:
 
 ```yaml
 apiVersion: dapr.io/v2alpha1
@@ -223,6 +229,7 @@ spec:
   pubsubname: pubsub
   metadata:
     routingKey: keyA
+    queueName: queue-A
 ```
 
 It will receive messages with routing key `keyA`, and messages with other routing keys are not received.