Future: order workload Building Blocks on existing Application Landing Zones #137

Product idea — explicitly outside the current scope

Introduce optional Building Blocks above Application Landing Zones. A Platform Owner defines reviewed workload bundles that authorized users can order within an existing Application Landing Zone without needing direct STACKIT Portal access. These are distinct from Application Landing Zone templates, which establish the project foundation.

Examples to investigate later include workload deployments and application services. A namespace in an Application-owned Kubernetes cluster belongs to its workload; this idea must not introduce Application Namespace services into the current Accelerator contract. Existing namespace onboarding remains exclusive to Platform Kubernetes (#37/#80 where relevant).

Design questions for a later feature stream

• Explicit target Application instance and supported resources/regions/clusters; no arbitrary cloud target or tenant crossing.
• Versioned bundle publication, parameter validation, policy and customer-defined approval requirements.
• Lifecycle and state ownership for bundle Plan/Apply/update/destroy; dependencies must not delete shared platform or Application resources.
• Bounded execution identity, auditability, quotas and recovery; users must not receive platform credentials.
• Define who may order, operate and remove bundles independently of direct Portal permissions.
• Keep the standalone Accelerator usable and preserve existing Application instances and resource identities.

Customer choice remains required

Until and after this feature exists, project IAM remains a customer decision. Recommend granular Application-team rights by default, but retain an explicit option for full project owner rights. Do not force Portal-free operations or silently downgrade existing owner grants. The Assistant should explain the trade-offs and supported choices once the permission profiles are implemented and qualified.

Future acceptance

• Agree product scope and architecture before implementation.
• Demonstrate an approved bundle can be ordered and operated on an existing Application Landing Zone without Portal access.
• Prove tenant/instance authorization, state ownership, versioning and failure recovery.
• Preserve customer choice of granular versus full-owner project permissions.

No implementation, release or infrastructure operation is authorized by this future-feature issue. This is not a blocker for the current Public/Corporate Application acceptance.