Reword

Author: javiereguiluz

configuration.rst

@@ -589,25 +589,21 @@ different scenarios: staging, quality assurance, client review, etc.)
 Configuration Based on Environment Variables
 --------------------------------------------
 
-Using `environment variables`_ (or "env vars" for short) is a common practice to
-configure options that depend on where the application is run (e.g. the database
-credentials are usually different in production versus your local machine). If
-the values are sensitive, you can even :doc:`encrypt them as secrets </configuration/secrets>`.
+Using `environment variables`_ (or "env vars" for short) is a common practice to:
+
+* Configure options that depend on where the application is run (e.g. the database
+  credentials are usually different in production versus your local machine);
+* Configure options that can change dynamically in a production environment (e.g.
+  to update the value of an expired API key without having to redeploy the entire
+  application).
+
+In other cases, it's recommended to keep using :ref:`configuration parameters <configuration-parameters>`.
 
 Use the special syntax ``%env(ENV_VAR_NAME)%`` to reference environment variables.
 The values of these options are resolved at runtime (only once per request, to
 not impact performance) so you can change the application behavior without having
 to clear the cache.
 
-.. note::
-
-    Environment variables are designed to store information that can
-    dynamically change in a production environment, such as an API
-    key that may have an expiration date. This information could be updated
-    without having to redeploy the application. Thus, not everything is a good
-    candidate for env vars, and
-    :ref:`parameters <configuration-parameters>` should be used in other cases.
-
 This example shows how you could configure the application secret using an env var:
 
 .. configuration-block::