Apply suggestions from code review

Co-authored-by: Kalyani Desai <[email protected]>

serverlessworkflow/modules/ROOT/pages/cloud/operator/add-custom-ca-to-a-workflow-pod.adoc

@@ -8,22 +8,22 @@ If you're working with containers running Java applications and need to add a CA
 :toc:
 
 
-== Problem Space 
+== Problem space 
 
-If you have a containerized Java application that connects to an SSL endpoint with a certificate signed by an internal authority (like SSL terminated routes on a cluster) you need to make sure Java can read the CA Authority certificate and verify it. Java unfortunately doesn't load certificates directly, but rather store them in a {keytool-docs}[keystore].
+If you have a containerized Java application that connects to an SSL endpoint with a certificate signed by an internal authority (like SSL terminated routes on a cluster), you need to make sure Java can read and verify the CA Authority certificate. Java unfortunately doesn't load certificates directly but rather stores them in a {keytool-docs}[keystore].
 
 The default trust store under `$JAVA_HOME/lib/security/cacerts` contains only CA's that are shipped with the Java distribution and there is the `keytool` tool that knows how to manipulate those key stores.
-The containerized application may not know the CA certificate in build time, and so we need to add it to the trust-store in deployment. To automate that we can use a combination of an init-container and a shared directory to pass the mutated trust store to the container before it runs. Let's run this step by step:
+The containerized application may not know the CA certificate in build time, so we need to add it to the `trust-store` in deployment. To automate that we can use a combination of an init-container and a shared directory to pass the mutated trust store to the container before it runs. Let's run this step by step:
 
 === Step 1: Obtain the CA Certificate
 
 Before proceeding, ensure you have the CA certificate file (in PEM format) that you want to add to the Java container. If you don't have it, you may need to obtain it from your system administrator or certificate provider.
 
-For the purpose of this guide we would take the k8s cluster root CA that is automatically deployed into every container under `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`
+For this guide, we would take the k8s cluster root CA that is automatically deployed into every container under `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`
 
 === Step 2: Prepare a trust store in an init-container
 
-Add or amend this volumes and init-container snippet to your pod spec or podTemplate in a deployment:
+Add or amend these volumes and init-container snippet to your pod spec or `podTemplate` in a deployment:
 
 [source,yaml]
 ---
@@ -50,9 +50,9 @@ The default keystore under `$JAVA_HOME` is part of the container image and is no
 
 === Step 3: Configure Java to load the new keystore
 
-Here we would just mount the new, modified cacerts into the default location where the JVM looks at.
-The Main.java example uses the standard http client so alternatively we could mount the cacerts to a different location and
-configure the Java runtime to load the new keystore with a system property `-Djavax.net.ssl.trustStore`.
+Here you can mount the new, modified `cacerts` into the default location where the JVM looks.
+The `Main.java` example uses the standard HTTP client so alternatively you could mount the `cacerts` to a different location and
+configure the Java runtime to load the new keystore with a `-Djavax.net.ssl.trustStore` system property.
 Note that libraries like resteasy don't respect that flag and may need to programmatically set the trust store location.
 
 [source,yaml]
@@ -136,7 +136,7 @@ spec:
 === {product_name} Example
 
 Similar to a deployment spec, a serverless workflow has a spec.podTemplate, with minor differences, but the change is almost identical.
-In this case we are mounting some ingress ca bundle because we want our workflow to reach the `.apps.my-cluster-name.my-cluster-domain` SSL endpoint.
+In this case, we are mounting some ingress ca-bundle because we want our workflow to reach the `.apps.my-cluster-name.my-cluster-domain` SSL endpoint.
 Here is the relevant spec section of a workflow with the changes:
 
 [source,yaml]