diff --git a/network/core-node/admin-guide/configuring.mdx b/network/core-node/admin-guide/configuring.mdx
index ba4f5b19a..847dc626b 100644
--- a/network/core-node/admin-guide/configuring.mdx
+++ b/network/core-node/admin-guide/configuring.mdx
@@ -230,7 +230,7 @@ Choosing redundant nodes is good practice. The archive requirement is programmat
 
 :::info Important Note
 
-You need to either depend on exactly one entity OR have **at least 4 entities** for automatic quorum set configuration to work properly. At least 4 is the better option.
+It is ideal to configure at least 4 entities in your quorum if you'll be using automatic quorum set generation. The tradeoff here is about fault tolerance: a quorum with fewer than 4 entities will tolerate **zero** node failures. Take this moment to ensure your configured quorum meets your required fault tolerance.
 
 :::
 
@@ -249,7 +249,7 @@ _Diagram: Depiction of the nested quality levels and how they interact._
 
 ### Quorum and Overlay Network
 
-It is generally a good idea to give information to your validator on other validators that you rely on. This is achieved by configuring the `KNOWN_PEERS` and `PREFERRED_PEERS` fields with the addresses of nodes you depend on.
+It can be beneficial to give information to your validator on other validators that you rely on. This is achieved by configuring the optional `KNOWN_PEERS` and `PREFERRED_PEERS` fields with the addresses of nodes you depend on. Most often, it is reasonable to depend on your node's default peer discovery. These settings, however, can be very useful for troubleshooting.
 
 Additionally, configuring `PREFERRED_PEER_KEYS` with the keys from your quorum set might be a good idea to give priority to the nodes that allow you to reach consensus.