Merge pull request #3576 from yogeek/patch-1

fix format in using-iam-roles-in-mgmt-cluster.md

Author: k8s-ci-robot

docs/book/src/topics/using-iam-roles-in-mgmt-cluster.md

@@ -30,18 +30,24 @@ Create a management cluster which uses instance profiles (IAM roles) attached to
    Since only control-plane nodes have the required IAM roles attached, CAPA deployment should have the necessary tolerations for master (control-plane) node and node selector for master.
 > **Note:** A cluster with a single control plane node won’t be sufficient here due to the `NoSchedule` taint.
 
-3. Get the kubeconfig for the new target management cluster(created in previous step) once it is up and running.
-4. Zero the credentials CAPA controller started with, such that target management cluster uses empty credentials and not the previous credentials used to create bootstrap cluster using:
-```bash
-clusterawsadm controller zero-credentials --namespace=capa-system
-```
-For more details, please refer [zero-credentials doc](https://cluster-api-aws.sigs.k8s.io/clusterawsadm/clusterawsadm_controller_zero-credentials.html).
-5. Rollout and restart on capa-controller-manager deployment using:
-```bash
-clusterawsadm controller rollout-controller --kubeconfig=kubeconfig --namespace=capa-system
-```
-For more details, please refer [rollout-controller doc](https://cluster-api-aws.sigs.k8s.io/clusterawsadm/clusterawsadm_controller_rollout-controller.html).
-6. Use `clusterctl init` with the new cluster’s kubeconfig to install the provider components. For more details on preparing for init, please refer [clusterctl init doc](https://cluster-api.sigs.k8s.io/clusterctl/commands/init.html).
-7. Use `clusterctl move` to move the Cluster API resources from the bootstrap cluster to the target management cluster. For more details on preparing for move, please refer [clusterctl move doc](https://cluster-api.sigs.k8s.io/clusterctl/commands/move.html).
-8. Once the resources are moved to target management cluster successfully, `capa-manager-bootstrap-credentials` will be created as nil, and hence CAPA controllers will fall back to use the attached instance profiles.
-9. Delete the bootstrap cluster with the AWS credentials.
+2. Get the kubeconfig for the new target management cluster(created in previous step) once it is up and running.
+
+3. Zero the credentials CAPA controller started with, such that target management cluster uses empty credentials and not the previous credentials used to create bootstrap cluster using:
+   ```bash
+   clusterawsadm controller zero-credentials --namespace=capa-system
+   ```
+   For more details, please refer [zero-credentials doc](https://cluster-api-aws.sigs.k8s.io/clusterawsadm/clusterawsadm_controller_zero-credentials.html).
+
+4. Rollout and restart on capa-controller-manager deployment using:
+   ```bash
+   clusterawsadm controller rollout-controller --kubeconfig=kubeconfig --namespace=capa-system
+   ```
+   For more details, please refer [rollout-controller doc](https://cluster-api-aws.sigs.k8s.io/clusterawsadm/clusterawsadm_controller_rollout-controller.html).
+
+5. Use `clusterctl init` with the new cluster’s kubeconfig to install the provider components. For more details on preparing for init, please refer [clusterctl init doc](https://cluster-api.sigs.k8s.io/clusterctl/commands/init.html).
+
+6. Use `clusterctl move` to move the Cluster API resources from the bootstrap cluster to the target management cluster. For more details on preparing for move, please refer [clusterctl move doc](https://cluster-api.sigs.k8s.io/clusterctl/commands/move.html).
+
+7. Once the resources are moved to target management cluster successfully, `capa-manager-bootstrap-credentials` will be created as nil, and hence CAPA controllers will fall back to use the attached instance profiles.
+
+8. Delete the bootstrap cluster with the AWS credentials.