diff --git a/docs/user-tutorials/02-10-manage-module-with-custom-resource-policy.md b/docs/user-tutorials/02-10-manage-module-with-custom-resource-policy.md
index 39bdd2d153..e8e7f33635 100644
--- a/docs/user-tutorials/02-10-manage-module-with-custom-resource-policy.md
+++ b/docs/user-tutorials/02-10-manage-module-with-custom-resource-policy.md
@@ -20,7 +20,7 @@ By default, the CustomResourcePolicy of the enabled module is `CreateAndDelete`.
 For example, to enable the Keda module with the default policy for the `default-kyma` Kyma CR, run:
 
 ```bash
-kyma alpha add module keda -n kyma-system -k default-kyma
+kyma alpha enable module keda -n kyma-system -k default-kyma
 ```
 
 This will result in the `default-kyma` Kyma CR spec like this:
@@ -35,7 +35,7 @@ spec:
 
 Lifecycle Manager will create a corresponding Keda CR in your target cluster and propagate all the values from the ModuleTemplate `spec.data.spec` to the `spec.resource` of the related Manifest CR. This way, you can configure and manage your Keda resources using Lifecycle Manager.
 
-To skip this enablement process, you can set the `customResourcePolicy` flag to `Ignore` when you enable the module. This will result in no Keda CR created in your target cluster. It will also prevent Lifecycle Manager from adding any `spec.resource` to the related Manifest CR.
+To skip this enablement process, you can set the `--policy` flag to `Ignore` when you enable the module. This will result in no Keda CR created in your target cluster. It will also prevent Lifecycle Manager from adding any `spec.resource` to the related Manifest CR.
 
 > [!WARNING]
 > Setting up the flag to `Ignore` also means that Lifecycle Manager does not monitor or manage any Keda CR's readiness status. Therefore, you should exercise caution and discretion when using the `Ignore` policy for your module CR.