diff --git a/content/for-administrators/how-to-guides/certificate-management/tls-certs.md b/content/for-administrators/how-to-guides/certificate-management/tls-certs.md
index 5af9557f..5c49d65d 100644
--- a/content/for-administrators/how-to-guides/certificate-management/tls-certs.md
+++ b/content/for-administrators/how-to-guides/certificate-management/tls-certs.md
@@ -8,28 +8,26 @@ Go to `common-shared-secret` path in Vault and create a secret `external-dns-cre
 
 ### Cloudflare
 
-- `api-token (required)`: API token generated from DNS provider being used. In case of Cloudflare, it should have `DNS:Edit` and `Zone:Read` access.
-- `domain-filter (optional)`: This field should contain base domain that becomes base for registering further subdomains. For example: `example.com`.
-- `zone-id-filter (optional)`: In case of Cloudflare, if you want to give more restrictive access of only few zones to this token, then this field should contain these zone ids.
+| Key | Required/Optional | Explanation |
+|----------|----------|----------|
+| `api-token`   | required   | API token generated from DNS provider being used. In case of Cloudflare, it should have the following access <br> - `DNS:Edit` <br> - `Zone:Read`   |
+| `domain-filter`    | optional   | This field should contain base domain that becomes base for registering further subdomains. For example: `example.com`.   |
+| `zone-id-filter`| optional   | In case of Cloudflare, if you want to give more restrictive access of only few zones to this token, then this field should contain these zone ids.
 
-## Step 2: Navigate to the Target Path
+## Step 2: Create Cert Manager Issuer Resource
 
-Navigate to the appropriate path in your Infra GitOps repository. For this example, the path is:
+Create following resources in your Infra GitOps repository at given path:
 
 ```plaintext
 <cluster>/tenant-operator-config/templates/
 ```
 
-## Step 3: Create Required Resources
-
-In this directory, create the following resources:
-
 - [`Template`](https://docs.stakater.com/mto/main/crds-api-reference/template.html)
 - [`TemplateGroupInstance`](https://docs.stakater.com/mto/main/crds-api-reference/template-group-instance.html)
 
 ### Template
 
-The `Template` resource defines the underlying YAML files to be deployed to tenant namespaces. Below is an example template for setting up a TLS certificate:
+The `Template` resource defines the underlying YAML files to be deployed to tenant namespaces. Use the following template for setting up a TLS certificate:
 
 #### Cloudflare
 
@@ -80,19 +78,21 @@ resources:
 
 #### Explanation of Resources
 
-1. **`ExternalSecret`**:
-   - Retrieves the `api-token` from the secret provider (Vault).
-   - The `api-token` authenticates the DNS provider (e.g., Cloudflare) for certificate validation.
+**`ExternalSecret`**:
+
+- Retrieves the `api-token` from the secret provider (Vault).
+- The `api-token` authenticates the DNS provider (e.g., Cloudflare) for certificate validation.
+
+**`Issuer`**:
 
-1. **`Issuer`**:
-   - Configures Cert-Manager to generate TLS certificates using [Let’s Encrypt](https://letsencrypt.org/).
-   - Requires:
-     - `.spec.acme.email`: Email address for certificate lifecycle updates.
-     - `.spec.acme.solvers.dns01.cloudflare.apiTokenSecretRef`: Reference to the `ExternalSecret` created earlier.
+- Configures Cert-Manager to generate TLS certificates using [Let’s Encrypt](https://letsencrypt.org/).
+- Requires:
+    - `.spec.acme.email`: Email address for certificate lifecycle updates.
+    - `.spec.acme.solvers.dns01.cloudflare.apiTokenSecretRef`: Reference to the `ExternalSecret` created earlier.
 
 ### TemplateGroupInstance
 
-The `TemplateGroupInstance` deploys resources by referencing the created templates and specifying target namespaces. Example:
+The `TemplateGroupInstance` deploys resources by referencing the created templates and specifying target namespaces:
 
 ```yaml
 apiVersion: tenantoperator.stakater.com/v1alpha1
@@ -103,9 +103,9 @@ spec:
   template: certificate-creds
   selector:
     matchExpressions:
-      - key: stakater.com/kind
+      - key: stakater.com/tenant
         operator: In
-        values: [sandbox, dev]
+        values: [ <comma separated tenant names list> ]
   sync: true
 ```
 
@@ -113,11 +113,11 @@ spec:
 
 - **`.spec.template`**: References the `Template` resource.
 - **`.spec.selector`**: Specifies namespaces to deploy resources based on label expressions.
-    - In this example, resources are deployed to tenant namespaces with the label `stakater.com/kind` having values `sandbox` or `dev`.
+    - In this example, resources are deployed to tenant with the label `stakater.com/tenant` having values `tenant1` or `tenant2`. Ensure this list includes the names of all tenants where the `Issuer` needs to be available. Whenever you add a new tenant requiring an `Issuer`, update this field to include its name.
 
 Commit, push, and merge these changes to the `main` branch. ArgoCD will deploy the resources to the specified namespaces within a few minutes.
 
-### Verify Deployment
+## Step 3: Validation
 
 1. In the cluster console, switch to `Administrator` view and navigate to `Home > Search`.
 1. Select the namespace and search for `Issuer` in the `Resources` dropdown.
diff --git a/content/for-developers/how-to-guides/expose-applications-to-internet/expose-applications-to-internet.md b/content/for-developers/how-to-guides/expose-applications-to-internet/expose-applications-to-internet.md
index 184da311..4bffcd44 100644
--- a/content/for-developers/how-to-guides/expose-applications-to-internet/expose-applications-to-internet.md
+++ b/content/for-developers/how-to-guides/expose-applications-to-internet/expose-applications-to-internet.md
@@ -26,7 +26,7 @@ application:
     dnsNames:
       - <DNS for which we need to generate certificate for example:example.com>
     issuerRef:
-      name: <cert manager's Issuer name. You can ask cluster admin for this>
+      name: <cert manager's Issuer name.>
       kind: Issuer
 ```
 
@@ -37,7 +37,7 @@ application:
     - Requires:
         - `.certificate.secretName`: This is the name of secret that `Certificate` will create. It will contain TLS credentials that will find its utilization in next steps.
         - `.certificate.dnsNames`: DNS name for which this certificate will be valid. It can contain wildcard names like `*.example.com` or specific names like `api.example.com`.
-        - `.certificate.issuerRef.name`: Name of the issuer that this certificate will reference. We have created this issuer in previous steps.
+        - `.certificate.issuerRef.name`: Name of the issuer that this certificate will reference. We have created this issuer in previous steps. You can find this in the cluster console by switching to `Administrator` view and navigate to `Home > Search` and search for `Issuer` in your current namespace.
 
 ## Step 2: Deploy the Route
 
@@ -71,7 +71,7 @@ application:
     - `route.host`: Specifies the host name that you want to use for this route. This value must match the `external-dns.alpha.kubernetes.io/hostname` annotation.
     - `route.path`:  Specifies the URL path where your application will be exposed (e.g., `/api`).
 
-### Verify Deployment
+### Validation
 
 After updating the `values.yaml` file and applying the Helm chart, verify the deployment:
 
@@ -93,6 +93,6 @@ After updating the `values.yaml` file and applying the Helm chart, verify the de
 1. Navigate to the OpenShift cluster console.
 1. Go to Networking > Routes and locate the Route resource for your application.
 1. Confirm that:
-   - The Route resource is listed.
-   - Its status is Accepted.
-   - The DNS name and TLS configuration are correct.
+    - The Route resource is listed.
+    - Its status is Accepted.
+    - The DNS name and TLS configuration are correct.