[Bug] gemini-enterprise deploy.sh: ENABLE_MODEL_ARMOR_FLAG is assigned only inside the FedRAMP-High/NONE branch, so IL4, IL5 and regime option 4 abort application configuration on an empty jq argument

[JohnHales]

Bug Description

In the application-configuration loop, the Model Armor prompt is gated on the compliance regime:

# deploy.sh:1353
if [[ "$COMPLIANCE_REGIME" == "FEDRAMP_HIGH" || "$COMPLIANCE_REGIME" == "NONE" ]]; then
    ...
    read -p "Would you like to enable 'Model Armor'? [y/N]: " ENABLE_MODEL_ARMOR
    if [[ "$ENABLE_MODEL_ARMOR" =~ ^[Yy]$ ]]; then
        ENABLE_MODEL_ARMOR_FLAG="true"          # :1359
        ...
    else
        ENABLE_MODEL_ARMOR_FLAG="false"         # :1371
    fi
fi

Those two lines are the only assignments to ENABLE_MODEL_ARMOR_FLAG in the script; it is not initialised anywhere else. The value is then consumed unconditionally, outside the gate:

# deploy.sh:1386
--argjson model_armor "$ENABLE_MODEL_ARMOR_FLAG" \

Under IL4 or IL5 the variable is unset, so jq is handed --argjson model_armor "" and fails parsing empty input. deploy.sh runs under set -e (line 2), so the script aborts right there — part-way through configuring applications, after the operator has answered every other prompt in the loop.

The same path is reached under regime option 4 ("None"), because that option leaves COMPLIANCE_REGIME as the empty string rather than the literal NONE the gate tests for (reported separately) — so the branch a reader would expect to cover "none" does not cover it.

Environment and Deployment Context

• Stellar Engine Version/Commit: main at commit f64ce6cd (re-verified 2026-08-10)
• Deployment Type:
  • US Region Restricted (e.g., Access Policy constraint)
  • FedRAMP Medium
  • FedRAMP High
  • FedRAMP Moderate
  • DoD IL4
  • DoD IL5
  • Stand-alone / Custom
• FAST Stage (if applicable): N/A — this is a blueprint, not a FAST stage
  • Stage 0 (Bootstrap)
  • Stage 1 (Resource Management)
  • Stage 2 (Network Creation)
  • Stage 3 (Security and Audit)
• Affected Component:
  • blueprints/fedramp-high/gemini-enterprise/deploy.sh:1353 (the gate)
  • blueprints/fedramp-high/gemini-enterprise/deploy.sh:1359, :1371 (the only assignments)
  • blueprints/fedramp-high/gemini-enterprise/deploy.sh:1386 (unconditional use)
• Terraform Version: 1.12.2 (pinned by deploy.sh via tfenv; the stage declares required_version >= 1.7.4)
• GCP Provider Version: hashicorp/google >= 6.21.0 (stage-0 declared constraint)

Steps to Reproduce

1. Run ./deploy.sh and select compliance regime 2 (IL4) or 3 (IL5).
2. Continue into stage-0 configuration and answer the Gemini application prompts.
3. The run aborts at the jq -n that assembles the application JSON, on the empty model_armor argument.

Expected Behavior

Regimes that do not offer Model Armor produce enable_model_armor = false and continue.

Actual Behavior

Under IL4, IL5 or regime option 4, ENABLE_MODEL_ARMOR_FLAG is never assigned, jq receives an empty --argjson value, and set -e aborts the script part-way through application configuration — after the operator has answered every other prompt in the loop.

Relevant Logs and Errors

Expected error (from source inspection; not captured from a run) — jq rejects empty input for --argjson and the script exits under set -e:

jq: Invalid JSON text passed to --argjson
Use jq --help for help with command-line options,
or see the jq manpage, or online docs  at https://stedolan.github.io/jq

Suggested Fix

Initialize ENABLE_MODEL_ARMOR_FLAG="false" before the gate, alongside the other per-application flags. false is the correct fallback — the stage-0 variable already defaults enable_model_armor to false.

Additional Context

Read from source; confirmed against main @ f64ce6cd, 2026-08-10. Interacts with the compliance-regime issue reported alongside this one.

[AloysJehwin]

Taking this one — will open a PR shortly.

[AloysJehwin]

Opened #204 for this. Could a maintainer add a review label when you get a chance? External contributors can't set them.