diff --git a/modules/troubleshooting-certs-auto-etcd.adoc b/modules/troubleshooting-certs-auto-etcd.adoc
index 87b4eccb9416..33861a46b19d 100644
--- a/modules/troubleshooting-certs-auto-etcd.adoc
+++ b/modules/troubleshooting-certs-auto-etcd.adoc
@@ -6,6 +6,7 @@
 [id="troubleshooting-certs-auto-etcd_{context}"]
 = Certificates managed by etcd
 
+[role="_abstract"]
 The etcd certificates are used for encrypted communication between etcd member peers as well as encrypted client traffic. 
 The certificates are renewed automatically within the cluster provided that communication between all nodes and all services is current.
 Therefore, if your cluster might lose communication between components during a specific period of time, which is close to the end of the etcd certificate lifetime, it is recommended to renew the certificate in advance.
diff --git a/modules/troubleshooting-certs-auto-node.adoc b/modules/troubleshooting-certs-auto-node.adoc
index b018eee0893f..c1a6f7482b8a 100644
--- a/modules/troubleshooting-certs-auto-node.adoc
+++ b/modules/troubleshooting-certs-auto-node.adoc
@@ -6,6 +6,7 @@
 [id="troubleshooting-certs-auto-node_{context}"]
 = Node certificates
 
+[role="_abstract"]
 Node certificates are self-signed certificates, which means that they are signed by the cluster and they originate from an internal certificate authority (CA) that is generated by the bootstrap process.
 
 After the cluster is installed, the cluster automatically renews the node certificates.
diff --git a/modules/troubleshooting-certs-auto-service-ca.adoc b/modules/troubleshooting-certs-auto-service-ca.adoc
index e05fbbaf6cdc..d18e16d17fa8 100644
--- a/modules/troubleshooting-certs-auto-service-ca.adoc
+++ b/modules/troubleshooting-certs-auto-service-ca.adoc
@@ -6,6 +6,7 @@
 [id="troubleshooting-certs-auto-service-ca_{context}"]
 = Service CA certificates
 
+[role="_abstract"]
 The `service-ca` is an Operator that creates a self-signed certificate authority (CA) when an {product-title} cluster is deployed.
 This allows user to add certificates to their deployments without manually creating them. 
 Service CA certificates are self-signed certificates.
diff --git a/modules/troubleshooting-certs-auto.adoc b/modules/troubleshooting-certs-auto.adoc
index 0541abdf2181..1f39ded8e25a 100644
--- a/modules/troubleshooting-certs-auto.adoc
+++ b/modules/troubleshooting-certs-auto.adoc
@@ -6,6 +6,7 @@
 [id="troubleshooting-certs-auto_{context}"]
 = Certificates managed by the cluster
 
+[role="_abstract"]
 You only need to check cluster-managed certificates if you detect an issue in the logs.
 The following certificates are automatically managed by the cluster:
 
diff --git a/modules/troubleshooting-certs-manual-proxy.adoc b/modules/troubleshooting-certs-manual-proxy.adoc
index d87adbad4394..887b35fc4fc4 100644
--- a/modules/troubleshooting-certs-manual-proxy.adoc
+++ b/modules/troubleshooting-certs-manual-proxy.adoc
@@ -6,6 +6,7 @@
 [id="troubleshooting-certs-manual-proxy_{context}"]
 = Managing proxy certificates
 
+[role="_abstract"]
 Proxy certificates allow users to specify one or more custom certificate authority (CA) certificates that are used by platform components when making egress connections.
 
 [NOTE]
@@ -25,5 +26,5 @@ Therefore, you need to pull the certificate from the `ConfigMap` object of your
 ----
 $ openssl x509 -enddate -noout -in <cert_file_name>.pem
 ----
-
-For more information about determining how and when to renew your proxy certificates, see "Proxy certificates" in _Security and compliance_.
\ No newline at end of file
++
+For more information about determining how and when to renew your proxy certificates, see "Proxy certificates" in _Security and compliance_.
diff --git a/modules/troubleshooting-certs-manual-user-provisioned.adoc b/modules/troubleshooting-certs-manual-user-provisioned.adoc
index 1c790d36fcf4..b3629c890258 100644
--- a/modules/troubleshooting-certs-manual-user-provisioned.adoc
+++ b/modules/troubleshooting-certs-manual-user-provisioned.adoc
@@ -6,6 +6,7 @@
 [id="troubleshooting-certs-manual-user-provisioned_{context}"]
 = User-provisioned API server certificates
 
+[role="_abstract"]
 The API server is accessible by clients that are external to the cluster at `api.<cluster_name>.<base_domain>`.
 You might want clients to access the API server at a different hostname or without the need to distribute the cluster-managed certificate authority (CA) certificates to the clients.
 You must set a custom default certificate to be used by the API server when serving content.
diff --git a/modules/troubleshooting-certs-manual.adoc b/modules/troubleshooting-certs-manual.adoc
index 76a5dbd2632d..36ef8273136c 100644
--- a/modules/troubleshooting-certs-manual.adoc
+++ b/modules/troubleshooting-certs-manual.adoc
@@ -6,6 +6,7 @@
 [id="troubleshooting-certs-manual_{context}"]
 = Certificates manually managed by the administrator
 
+[role="_abstract"]
 The following certificates must be renewed by a cluster administrator:
 
 * Proxy certificates