Infrastructure as Code: Deploy the Decision Execution Engine as a Lambda or EKS Container

The Infrastructure console answers a question the Deployments page cannot: where does the execution engine itself run?

The Deployments page answers 'which version is live in staging?' — deployment inside the platform. It says nothing about whether the execution engine is a Lambda in your AWS account, a container on your EKS cluster, or a Cloud Run service in GCP. An enterprise replacing IBM ODM is buying exactly that control: give me the rule execution service in my account, with the Terraform checked in next to everything else I own.

**Cloud targets**: AWS Lambda, AWS EKS, GCP Cloud Run, Azure Container Apps. Each target is configured with provider, account, region, and the apply guard ('allow_apply', FALSE by default).

**The four-tab workflow**: Targets → Generate → Plan (dry-run) → Deploy → Status. You cannot generate without a target. You cannot plan without a module. The apply step requires a typed confirmation naming the provider, the account, and the region. Leaving the whole feature unexercised changes nothing in anybody's cloud account — that is the property the schema was arranged to give.

**Apply guard**: 'manager.trg_iac_run_apply_guard' enforces that apply cannot be triggered without an explicit 'allow_apply' flag on the target. A dry-run produces a plan; the operator reads it and then enables apply separately. This is not a UX affordance — it is a database trigger.

**The Terraform is yours**: the generated modules are downloaded to your repository. The platform does not maintain a Terraform state file, does not hold cloud credentials after generation, and does not manage the lifecycle of what it generated. You own the infrastructure.