题目重点：从期望状态、云 API、异步操作、状态读取和删除清理解释 Terraform Provider 的资源生命周期。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 以异步创建的虚拟计算资源为训练对象，云 API 返回 operation_id，最终可读 resource_id；真实 provider SDK、认证和 API 限额取决于平台。
- 用户目标是声明式收敛：配置给出期望状态，provider 的 create/read/update/delete 把远端状态与本地 Terraform state 协调。
解题路线
- 创建先验证输入与授权、构造幂等请求键并提交云 API；拿到 operation_id 后以退避和 jitter 轮询，直到 succeeded、failed 或超时。成功后记录稳定远端 ID，并做一次 read 确认实际属性。
- Read 需要区分暂时未可见与真 404：最终一致期间短暂重试；确认为远端已删除时把该资源从 state 移除，让下一次 plan 能恢复。
- Update 要界定哪些字段可原地改、哪些必须替换；有异步 operation 时仍等待终态，失败需保留可诊断状态而不把部分修改假报成功。
- Delete 应幂等：远端已经不存在可视为成功；若还被依赖占用，返回可行动错误。长轮询尊重 context 取消、期限、速率限制与 429/5xx，避免所有客户端同步重试。
- 解释 plan/apply 的差别：plan 展示拟变更，apply 才执行；并发操作者通过 state locking 和远端版本/幂等键降低冲突风险，不能假设本地 state 是云端真相。
手动走一遍
用户声明一台实例，Create 返回 op-42。轮询几次为 PENDING，再变 SUCCEEDED；Read 获得 instance-7 及实际 region/IP，写入 state。若等待中客户端超时，重试时先用 request key/op 查询原创建结果，避免再建一台。
规模与取舍
若平均需要 p 次轮询，每次 API 往返时间 r，调用量 O(p)，总延迟受后端 provisioning 与退避上限控制。大批资源并行 apply 要受云 API 配额约束，不能对每个资源毫秒级轮询。
易错点与追问
容易失分的边界
- 只写 CRUD 名称，遗漏异步终态与超时/取消。
- 创建请求超时即重新 POST，造成重复资源。
- 远端实际失败但只因提交请求 202 就把 state 标为成功。
- Read 看到短暂 404 立即判资源永不存在。
- 删除未幂等，重试后因 404 报错阻塞收敛。
继续深挖
- 远端创建成功但本地 state 写入失败如何恢复或 import？
- 哪些字段更新应该 ForceNew，如何让 plan 明确展示替换？
- API 429 和大量并发 provision 时如何调速？
- 操作超时后怎样区分云端仍在执行与已经失败？
