测验：删除保护与恢复证据

我从 Git 中删除了保留的定义，但该对象仍具有相同的 UID、OutOfSync/Succeeded 且已 PruneSkipped。最合理的解释是什么？

• 根据 Prune=false 跳过删除，与 Git 的差异依然存在。
• Git 恢复已完成，新对象已重用相同的 UID。
• 由于存储库身份验证失败，无法执行当前提交的比较。
• 资源健康检查将取代删除批准，并将很快自动删除。

当我从 Git 中使用 Prune=confirm 删除 ConfigMap 时，操作正在运行，并且有一条消息正在等待删除批准。下一步适当的行动是什么？

• 重新启动控制器以自动将运行操作转换为成功。
• 在审查当前申请和整个计划删除列表后获得批准。
• 直接删除live对象，等待Git比较完成。
• 添加Delete=false记录当前剪枝审批已完成。

空目标提交B是一个SyncError，但是操作状态仍然是Succeeded并且提交A。您确认了什么？

• B的操作成功，错误情况是无意义的过去记录。
• 由于A和B是同一个分支，因此可以合并两次操作的成功。
• A过去的操作是成功的，B的自动删除目前被拒绝。
• 由于资源 UID 相同，因此 B 中的所有更改均已实际实施。

验证空目标保护最合适的材料是什么？

• 将路径更改为不存在的Git目录并等待错误。
• 错误地更改集群连接地址，查看是否有剩余资源。
• 去掉存储读权限后，只查看最终的成功状态。
• 提交有效的空列表并查看当前修订/条件/保留 UID。

使用allowEmpty=true删除一次性并恢复Git定义后，创建了一个具有相同名称的新UID。报告中哪种表述是正确的？

• 声明的ConfigMap已经重新生成，数据备份恢复是单独验证的。
• 先前的物体以相同的身份复活，相关数据也被恢复。
• 由于旧的 UID 消失了，Git 恢复在任何意义上都失败了。
• 由于有新的UID，持久卷的时间点恢复已经过去。

有一篇评论说，如果设置Delete=false，从 Git 中删除的资源将不会被删除。正确的审查意见是什么？

• Delete 和 Prune 是同一选项的两个名称，因此按原样接受它们。
• 检查删除应用程序时的清理和删除 Git 时的修剪。
• 使用自动同步时，这两个选项都会被忽略，因此请删除它们。
• 仅当资源运行状况良好时，“删除”选项才会更改为“修剪”。