diff --git a/source/faas-automated-testing/faas-automated-testing.rst b/source/faas-automated-testing/faas-automated-testing.rst
index c2e523b4c1..df5c3a7408 100644
--- a/source/faas-automated-testing/faas-automated-testing.rst
+++ b/source/faas-automated-testing/faas-automated-testing.rst
@@ -222,6 +222,11 @@ Run the function locally from the same directory where the template.yaml resides
   sam build
   sam local invoke --parameter-overrides "MongoDbUri=${MONGODB_URI}"
 
+*NOTE* "127.0.0.1" in the MONGODB_URI MUST be replaced with "host.docker.internal" to test
+a local MongoDB deployment. If "host.docker.internal" does not work (can occur on M1
+machines), drivers MAY choose to use a [bridged docker container](https://docs.docker.com/network/bridge/)
+to test locally.
+
 
 Implementing the Function
 `````````````````````````
@@ -346,7 +351,6 @@ functions inside of it for setup, teardown, and execution:
       tasks:
         - test-aws-lambda-deployed
 
-
 Drivers MUST run the function on a single variant in Evergreen, in order to not
 potentially hit the Atlas API rate limit. The variant itself MUST have the SAM CLI installed.
 
@@ -364,5 +368,6 @@ Description of the behaviour of run-deployed-lambda-aws-tests.sh:
 Changelog
 =========
 
+:2023-08-17: Fixed URI typo, added host note, increase assume role duration.
 :2023-06-22: Updated evergreen configuration to use task groups.
 :2023-04-14: Added list of supported variants, added additional template config.
diff --git a/source/retryable-reads/retryable-reads.rst b/source/retryable-reads/retryable-reads.rst
index 49838e3690..f1705aeb4b 100644
--- a/source/retryable-reads/retryable-reads.rst
+++ b/source/retryable-reads/retryable-reads.rst
@@ -627,10 +627,9 @@ The spec concerns itself with retrying read operations that encounter a
 retryable error (i.e. no response due to network error or a response indicating
 that the node is no longer a primary). A retryable error may be classified as
 either a transient error (e.g. dropped connection, replica set failover) or
-persistent outage. In the case of a transient error, the driver will mark the
-server as "unknown" per the `SDAM`_
-spec. A subsequent retry attempt will allow the driver to rediscover the primary
-within the designated server selection timeout period (30 seconds by
+persistent outage. If a transient error results in the server being marked as
+"unknown", a subsequent retry attempt will allow the driver to rediscover the
+primary within the designated server selection timeout period (30 seconds by
 default). If server selection times out during this retry attempt, we can
 reasonably assume that there is a persistent outage. In the case of a persistent
 outage, multiple retry attempts are fruitless and would waste time. See `How To
@@ -695,6 +694,7 @@ Changelog
 :2023-08-??: Require that in a sharded cluster the server on which the
              operation failed MUST be provided to the server selection
              mechanism as a deprioritized server.
+:2023-08-21: Update Q&A that contradicts SDAM transient error logic
 :2022-11-09: CLAM must apply both events and log messages.
 :2022-10-18: When CSOT is enabled multiple retry attempts may occur.
 :2022-10-05: Remove spec front matter, move footnote, and reformat changelog.