A water-utility GenAI microservice uses one shared service account across development, test, and production. What identity architecture change is most important?
Select an answer to reveal the explanation.
Short Explanation
One badge for the sandbox and the plant floor is how accidents become outages. Give each environment its own GenAI service identity so a leaky lower tier cannot impersonate production. Shared accounts erase the blast-radius fence civic ops need.
Full Explanation
Environment isolation for GenAI microservices in a water utility requires distinct identities and credentials per development, test, and production so a lower-environment compromise cannot authorize production actions against utility systems. Shared service accounts across environments collapse that boundary, amplify blast radius, and make forensic attribution harder when the same principal appears everywhere. Identity architecture should issue per-environment service principals with scoped secrets and separate secret stores.
Sharing the production account password in the team wiki for faster onboarding fails secrecy and least privilege, turning onboarding into a broadcast credential leak. Disabling authentication in development and copying that pattern to production for consistency exports an insecure lab posture into the live utility path. Reusing SCADA operator badge certificates as the GenAI service identity conflates OT operator credentials with application service identity, violating separation of duty and expanding impact if the GenAI service is abused.
Exam caveat: "one account everywhere" is convenience debt; municipal OT-adjacent GenAI must not inherit SCADA operator credentials. Operational check: create distinct GenAI service identities per environment, rotate and store secrets separately, deny lower-env principals from production APIs, and audit that no wiki or shared vault entry holds a cross-environment production password.