Securely inject secrets for build flavors in CI/CD

WHAT THIS TESTS: This question evaluates your ability to secure the software supply chain for a Flutter application. The interviewer wants to see that you understand the difference between build-time and runtime secrets, that you can reason about trust boundaries in CI/CD systems, and that you know how to handle multiple build flavors without leaking credentials into Git history or compiled binaries. It also tests whether you consider operational concerns like secret rotation, auditability, and pipeline portability.

A GOOD ANSWER COVERS: Two distinct strategies with honest trade-offs. First, CI-native environment variables injected at build time. In this model each flavor maps to a variable set in GitHub Actions, GitLab CI, or Bitrise, and the build script writes them into a Dart-define or an untracked env file. The pros are speed and simplicity; the cons are vendor lock-in, limited audit trails, and the risk that secrets appear in build logs if masking is misconfigured. Second, fetching secrets from a dedicated secrets manager such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault via a CLI step in the pipeline. The build job authenticates with short-lived credentials or OIDC, pulls the latest values, and injects them before compilation. The pros are centralized rotation, fine-grained access control, and audit logs; the cons are network dependency, added latency, and the operational overhead of managing the vault itself. A strong candidate explicitly mentions avoiding committed files, scoping secrets to the job rather than the repository, and rotating credentials automatically.

COMMON WRONG ANSWERS: Storing encrypted env files in the repository using git-crypt or similar tools without explaining how the decryption key is distributed and rotated. This merely moves the secret problem upstream. Another red flag is relying on code obfuscation or string encryption inside the Flutter binary to hide keys, since reverse engineering can still extract them. Suggesting that secrets can be safely embedded in the Dart source if the repo is private also fails because version control is not an access control mechanism. Finally, confusing runtime secrets with build-time secrets, such as suggesting a remote config fetch for an API key that must exist at compile time, shows a lack of architectural clarity.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle a leaked secret, which should trigger an immediate rotation workflow and pipeline audit. They might probe on OIDC federation to eliminate long-lived CI tokens, or ask how you prevent secrets from appearing in build artifacts and logs. Another follow-up is how to support local developer builds without giving every engineer production access, which points toward a local secrets manager or developer-specific sandbox keys.

ONE CONCRETE EXAMPLE: Consider a Flutter app with staging and production flavors. In the CI pipeline for staging, an environment variable named STAGING_API_KEY is injected through GitHub Actions secrets and passed as a Dart define during the flutter build command. For production, the pipeline instead runs a Vault CLI login using OIDC, reads the latest production key from a path like secret/mobile/prod, writes it to a temporary file excluded by gitignore, builds the APK, and then deletes the temporary file in a finally block. The staging approach is fast and sufficient for lower-risk environments, while the Vault approach provides an audit log of exactly which CI job accessed the production key and when.