测验：平台基线与合规

在 Pod 安全准入标签上不仅修复级别而且还修复版本 (enforce-version) 的最准确原因是什么？

• 您必须记下版本，以便策略名称保留在审核日志中。
• 如果你写下版本，则命名空间将仅在该版本的 API 服务器上运行。
• 如果没有版本，则忽略该标签并且不应用该策略。
• 类的定义随着每个 Kubernetes 版本的不同而扩大，因此除非进行修复，否则集群升级将更改策略内容。

提前了解命名空间的强制级别是否可以提高一级的最合适方法是什么？

• 向服务器空运行发送标签更改请求，以读取当前浮动 Pod 的警告
• 实际更改标签后，观察 pod 是否死亡。
• 通过客户端试运行测试清单
• 创建新的命名空间并移动工作负载

当您创建 ServiceMonitor 且未收集任何指标时，首先要检查的是什么？

• ServiceMonitor对象是否处于Established状态？
• Pod 是否在命名空间中运行？
• 选择器实际上选择的是Service，端点的端口与Service的端口名相同。
• 容器端口号是9102吗？

当您将编写为extensions/v1beta1的 Ingress 清单应用到最新集群时会发生什么？

• 它会自动转换为最新版本，并带有警告。
• 由于未提供该组，因此它在资源映射步骤中被拒绝。
• 由于字段不足而发生架构验证错误。
• 创建但被控制器忽略

当将 Ingress 迁移到networking.k8s.io/v1时，哪个字段不在 v1beta1 中但成为必需的？

• ingressClassName
• pathType
• backend.resource
• defaultBackend

当团队当前无法达到基线时，最合适的平台响应是什么？

• 降低总体基线，直到团队可以保持它。
• 一律屏蔽，让团队自己解决。
• 口头同意并为基线文件添加脚注。
• 给出一个异常，并在对象中给出原因和到期日期，然后再次查看到期日期。