解读

在国内金融、政企及互联网强监管场景下，面试官想确认两点：

1. 你是否理解 Cloud SQL 在“实例创建”这一瞬间，密码复杂度规则与验证策略谁先谁后；
2. 你是否能把 Google 侧的实现映射到国内等保、密评、工信部云评估等合规要求，避免“策略已启用但密码仍被放行”的合规漏洞。
   回答必须围绕“生效顺序”展开，而不是单纯罗列参数。

知识点

1. 根密码复杂度（Root Password Complexity）
   仅作用于首次设置 root 口令的字符串本身，由 Cloud SQL 控制面在创建请求到达时立即执行正则校验；校验失败则实例不会进入 ALLOCATING 状态，请求直接回滚。
2. 密码验证策略（Password Validation Policy / verify_xxx Plugin）
   是数据库引擎级功能（MySQL 的 validate_password、PostgreSQL 的 passwordcheck、SQL Server 的 password policy），在第一次启动容器并初始化系统表后才加载；此时 root 口令已写入数据目录，策略仅对后续新建用户或修改密码生效。
3. 生效顺序
   ① Cloud SQL 控制面复杂度预检 → ② 实例分配与容器启动 → ③ 引擎插件加载 → ④ 策略对后续操作生效。
   因此，根密码不受验证策略约束，但受复杂度规则约束；若策略文件被后续加固，root 仍可使用原口令登录，除非手动 ALTER USER。

答案

在实例初始化阶段，根密码复杂度由 Cloud SQL 控制面先于容器启动进行校验，未通过则实例创建失败；密码验证策略属于引擎插件，仅在容器首次启动并完成系统表初始化后才加载，此时 root 密码已落盘，策略对后续用户或密码变更生效。简言之：复杂度先生效，策略后生效；根口令只过复杂度，不过策略。

拓展思考

1. 国内等保 2.0 要求“首次登录必须修改密码”，可结合 Cloud SQL 的 initializationPriority=POST_START 脚本，在策略加载后立刻 ALTER USER root PASSWORD EXPIRE，强制运维人员首次连接即改密，从而把“策略后生效”的缺口补上。
2. 若企业使用 Terraform 模块做基础设施即代码，建议把复杂度正则与策略参数拆成两层变量：一层在 google_sql_database_instance 的 root_password 字段做前置校验，另一层通过 google_sql_user 的 post_create 本地执行器动态下发 ALTER USER 并启用 validate_password，实现“双层密码治理”，既满足 Google 侧预检，又满足国内合规后检。