Mikhail Shapirov

@daveschmidt86 I assume the issue was specific for 1.22, however #417 should address it.

@daveschmidt86 please verify, if all good, we can close it.

Thank you, @otterley. I see the API usability issue. I spotted this a bit late and this feature is part of the stable API. We are using the record style...

@otterley I will take a look.

Assigned to @Eli1123

This works as designed. The behavior is similar to ekscstl --fargate behavior. See more [here](https://docs.aws.amazon.com/eks/latest/userguide/fargate-getting-started.html#:~:text=AWS%20Fargate%20profile.-,Note,any%20other%20namespaces%20you%20would%20like%20to%20use%20with%20Fargate.,-You%20can%20create). You can leverage the [generic cluster provider](https://aws-quickstart.github.io/cdk-eks-blueprints/cluster-providers/generic-cluster-provider/) to configure arbitrary fargate profiles (no default). Please...

It is a known issue for all Isengard accounts and occurs due to Account Guardian onboarding and PVRE stacks. The account protection automatically injects the policy to the node group....

@daveschmidt86 if your example was leveraging an account onboarded to the Account Guardian (which is also the case for all (most) Isengard accounts) then this issue will happen. Other than...

Great, we definitely need those. They may be more suitable for the patterns repo. We have a small example [here](https://github.com/aws-samples/cdk-eks-blueprints-patterns/blob/main/lib/generic-cluster-construct/index.ts#L30). But nothing with Karpenter and self-managed.

@christianhxc yes, the example should be in the patterns repo, but should definitely document it better. So doc update here with the link to the pattern. Also please let me...