diff --git a/serverlessworkflow/modules/ROOT/pages/cloud/operator/add-custom-ca-to-a-workflow-pod.adoc b/serverlessworkflow/modules/ROOT/pages/cloud/operator/add-custom-ca-to-a-workflow-pod.adoc
index c79064ddd..db8e68051 100644
--- a/serverlessworkflow/modules/ROOT/pages/cloud/operator/add-custom-ca-to-a-workflow-pod.adoc
+++ b/serverlessworkflow/modules/ROOT/pages/cloud/operator/add-custom-ca-to-a-workflow-pod.adoc
@@ -13,7 +13,7 @@ If you're working with containers running Java applications and need to add a CA
 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].
 
 The default trust store under `$JAVA_HOME/lib/security/cacerts` contains only CA's which are shipped with the Java distribution and there's 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 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, 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:
 
 === Step 1: Obtain the CA Certificate