diff --git a/acceptance/features/schema-crds.feature b/acceptance/features/schema-crds.feature
index 6f9598d2d..0ffe46a1e 100644
--- a/acceptance/features/schema-crds.feature
+++ b/acceptance/features/schema-crds.feature
@@ -8,7 +8,7 @@ Feature: Schema CRDs
     Given there is no schema "customer-profile" in cluster "basic"
     When I apply Kubernetes manifest:
     """
-    # tag::customer-profile-avro-schema-manifest[]
+# tag::customer-profile-avro-schema-manifest[]
     # This manifest creates an Avro schema named "customer-profile" in the "basic" cluster.
     # The schema defines a record with fields for customer ID, name, and age.
     ---
@@ -32,7 +32,7 @@ Feature: Schema CRDs
             { "type": "int", "name": "age" }
           ]
         }
-    # end::customer-profile-avro-schema-manifest[]
+# end::customer-profile-avro-schema-manifest[]
     """
     And schema "customer-profile" is successfully synced
     Then I should be able to check compatibility against "customer-profile" in cluster "basic"
@@ -42,7 +42,7 @@ Feature: Schema CRDs
     Given there is no schema "product-catalog" in cluster "basic"
     When I apply Kubernetes manifest:
     """
-    # tag::product-catalog-protobuf-schema-manifest[]
+# tag::product-catalog-protobuf-schema-manifest[]
     # This manifest creates a Protobuf schema named "product-catalog" in the "basic" cluster.
     # The schema defines a message "Product" with fields for product ID, name, price, and category.
     ---
@@ -65,7 +65,7 @@ Feature: Schema CRDs
           double price = 3;
           string category = 4;
         }
-    # end::product-catalog-protobuf-schema-manifest[]
+# end::product-catalog-protobuf-schema-manifest[]
     """
     And schema "product-catalog" is successfully synced
     Then I should be able to check compatibility against "product-catalog" in cluster "basic"
@@ -75,7 +75,7 @@ Feature: Schema CRDs
     Given there is no schema "order-event" in cluster "basic"
     When I apply Kubernetes manifest:
     """
-    # tag::order-event-json-schema-manifest[]
+# tag::order-event-json-schema-manifest[]
     # This manifest creates a JSON schema named "order-event" in the "basic" cluster.
     # The schema requires an "order_id" (string) and a "total" (number) field, with no additional properties allowed.
     ---
@@ -87,6 +87,7 @@ Feature: Schema CRDs
       cluster:
         clusterRef:
           name: basic
+      schemaType: json
       compatibilityLevel: None
       text: |
         {
@@ -99,7 +100,7 @@ Feature: Schema CRDs
           "required": ["order_id", "total"],
           "additionalProperties": false
         }
-    # end::order-event-json-schema-manifest[]
+# end::order-event-json-schema-manifest[]
     """
     And schema "order-event" is successfully synced
     Then I should be able to check compatibility against "order-event" in cluster "basic"
diff --git a/acceptance/features/topic-crds.feature b/acceptance/features/topic-crds.feature
index 4acdabab0..037d40058 100644
--- a/acceptance/features/topic-crds.feature
+++ b/acceptance/features/topic-crds.feature
@@ -9,7 +9,7 @@ Feature: Topic CRDs
     When I apply Kubernetes manifest:
     """
 # tag::basic-topic-example[]
-# In this example manifest, a topic called "topic1" is created in a cluster called "basic". It has a replication factor of 1 and is distributed across a single partition.
+    # In this example manifest, a topic called "topic1" is created in a cluster called "basic". It has a replication factor of 1 and is distributed across a single partition.
     ---
     apiVersion: cluster.redpanda.com/v1alpha2
     kind: Topic
@@ -24,4 +24,4 @@ Feature: Topic CRDs
 # end::basic-topic-example[]
     """
     And topic "topic1" is successfully synced
-    Then I should be able to produce and consume from "topic1" in cluster "basic"
\ No newline at end of file
+    Then I should be able to produce and consume from "topic1" in cluster "basic"
diff --git a/acceptance/features/user-crds.feature b/acceptance/features/user-crds.feature
index 571e83359..f8e5f07db 100644
--- a/acceptance/features/user-crds.feature
+++ b/acceptance/features/user-crds.feature
@@ -26,9 +26,9 @@ Feature: User CRDs
     When I apply Kubernetes manifest:
     """
 # tag::manage-authn-only-manifest[]
-# In this example manifest, a user called "jason" is created in a cluster called "sasl".
-# The user's password is defined in a Secret called "jason-password".
-# This example assumes that you will create ACLs for this user separately.
+    # In this example manifest, a user called "jason" is created in a cluster called "sasl".
+    # The user's password is defined in a Secret called "jason-password".
+    # This example assumes that you will create ACLs for this user separately.
     ---
     apiVersion: cluster.redpanda.com/v1alpha2
     kind: User
@@ -59,9 +59,9 @@ Feature: User CRDs
     When I apply Kubernetes manifest:
     """
 # tag::manage-authz-only-manifest[]
-# In this example manifest, an ACL called "travis" is created in a cluster called "sasl".
-# The ACL give an existing user called "travis" permissions to read from all topics whose names start with some-topic.
-# This example assumes that you already have a user called "travis" in your cluster.
+    # In this example manifest, an ACL called "travis" is created in a cluster called "sasl".
+    # The ACL give an existing user called "travis" permissions to read from all topics whose names start with some-topic.
+    # This example assumes that you already have a user called "travis" in your cluster.
     ---
     apiVersion: cluster.redpanda.com/v1alpha2
     kind: User
@@ -83,4 +83,4 @@ Feature: User CRDs
     """
     And user "travis" is successfully synced
     And I delete the CRD user "travis"
-    Then "travis" should be able to authenticate to the "sasl" cluster with password "password" and mechanism "SCRAM-SHA-256"
\ No newline at end of file
+    Then "travis" should be able to authenticate to the "sasl" cluster with password "password" and mechanism "SCRAM-SHA-256"