diff --git a/latest/ug/manage-access/aws-access/enable-iam-roles-for-service-accounts.adoc b/latest/ug/manage-access/aws-access/enable-iam-roles-for-service-accounts.adoc
index bb1b1da48..24f630b3f 100644
--- a/latest/ug/manage-access/aws-access/enable-iam-roles-for-service-accounts.adoc
+++ b/latest/ug/manage-access/aws-access/enable-iam-roles-for-service-accounts.adoc
@@ -48,11 +48,13 @@ If output is returned, then you already have an IAM OIDC provider for your clust
 eksctl utils associate-iam-oidc-provider --cluster $cluster_name --approve
 ----
 +
-NOTE: If you enabled the EKS VPC endpoint, the EKS OIDC service endpoint couldn't be accessed from inside that VPC. Consequently, your operations such as creating an OIDC provider with `eksctl` in the VPC will not work and will result in a timeout. An example error message follows:
-+
+[NOTE]
+====
+If you enabled the EKS VPC endpoint, the EKS OIDC service endpoint couldn't be accessed from inside that VPC. Consequently, your operations such as creating an OIDC provider with `eksctl` in the VPC will not work and will result in a timeout. An example error message follows:
 ----
 ** server cant find oidc.eks.<region-code>.amazonaws.com: NXDOMAIN
 ----
+====
 +
 To complete this step, you can run the command outside the VPC, for example in {aws} CloudShell or on a computer connected to the internet. Alternatively, you can create a split-horizon conditional resolver in the VPC, such as Route 53 Resolver to use a different resolver for the OIDC Issuer URL and not use the VPC DNS for it. For an example of conditional forwarding in CoreDNS, see the https://github.com/aws/containers-roadmap/issues/2038[Amazon EKS feature request] on GitHub.