ASP.NET Core 试题 37：健康检查
0721 在 存活与就绪 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 数据库不可用时存活检查必须失败并立即重启所有实例
- B. 把短暂下游故障放入存活检查可能引发重启风暴，应按恢复策略分离
- C. 观察到“数据库抖动导致全部 Pod 循环重启”即可把一次现象当成完整框架契约。
- D. 存活检查判断进程是否需要重启，就绪检查判断实例是否可接收流量
查看答案与解析
正确答案D
正确答案直接描述 存活与就绪 的主规则：存活检查判断进程是否需要重启，就绪检查判断实例是否可接收流量。选项“把短暂下游故障放入存活检查可能引发重启风暴，应按恢复策略分离”是使用规则时要验证的边界，不是规则本身；“数据库不可用时存活检查必须失败并立即重启所有实例”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0722 数据库抖动导致全部 Pod 循环重启。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“把短暂下游故障放入存活检查可能引发重启风暴，应按恢复策略分离”，再依据“存活检查判断进程是否需要重启，就绪检查判断实例是否可接收流量”判断实现是否符合契约。
- B. 直接按“数据库不可用时存活检查必须失败并立即重启所有实例”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“把短暂下游故障放入存活检查可能引发重启风暴，应按恢复策略分离”。
- D. 以一次成功请求作为结论，不再确认“存活检查判断进程是否需要重启，就绪检查判断实例是否可接收流量”是否成立。
查看答案与解析
正确答案A
场景“数据库抖动导致全部 Pod 循环重启”指向 存活与就绪，但症状本身不能证明根因。正确排查应先确认边界“把短暂下游故障放入存活检查可能引发重启风暴，应按恢复策略分离”，再用主规则“存活检查判断进程是否需要重启，就绪检查判断实例是否可接收流量”解释证据。直接采用误区“数据库不可用时存活检查必须失败并立即重启所有实例”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0723 关于 存活与就绪，以下哪项说法不成立？
难度： 实战
- A. 存活检查判断进程是否需要重启，就绪检查判断实例是否可接收流量
- B. 把短暂下游故障放入存活检查可能引发重启风暴，应按恢复策略分离
- C. 数据库不可用时存活检查必须失败并立即重启所有实例
- D. 出现“数据库抖动导致全部 Pod 循环重启”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“数据库不可用时存活检查必须失败并立即重启所有实例”正是 存活与就绪 的典型误区。其余三项分别给出了主规则“存活检查判断进程是否需要重启，就绪检查判断实例是否可接收流量”、适用边界“把短暂下游故障放入存活检查可能引发重启风暴，应按恢复策略分离”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0724 针对“数据库抖动导致全部 Pod 循环重启”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“数据库不可用时存活检查必须失败并立即重启所有实例”修改实现，并把一次请求成功作为验收结果。
- B. 按“存活检查判断进程是否需要重启，就绪检查判断实例是否可接收流量”修正实现，并用测试或遥测验证“把短暂下游故障放入存活检查可能引发重启风暴，应按恢复策略分离”。
- C. 按“存活检查判断进程是否需要重启，就绪检查判断实例是否可接收流量”修改代码后直接上线，不验证“把短暂下游故障放入存活检查可能引发重启风暴，应按恢复策略分离”。
- D. 只验证“把短暂下游故障放入存活检查可能引发重启风暴，应按恢复策略分离”，但实现仍继续依赖“数据库不可用时存活检查必须失败并立即重启所有实例”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：存活检查判断进程是否需要重启，就绪检查判断实例是否可接收流量；并确认 把短暂下游故障放入存活检查可能引发重启风暴，应按恢复策略分离。继续接受“数据库不可用时存活检查必须失败并立即重启所有实例”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“数据库抖动导致全部 Pod 循环重启”这一生产场景能否安全上线。
0725 在 健康检查标签 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 注册检查时可添加 tags，映射端点时用 Predicate 选择检查集合
- B. 同一检查带多个标签时只会执行第一个标签
- C. 标签只是筛选元数据，命名和分组应与编排平台探针目的一致
- D. 观察到“readiness 端点意外运行了昂贵深度检查”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 健康检查标签 的主规则：注册检查时可添加 tags，映射端点时用 Predicate 选择检查集合。选项“标签只是筛选元数据，命名和分组应与编排平台探针目的一致”是使用规则时要验证的边界，不是规则本身；“同一检查带多个标签时只会执行第一个标签”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0726 readiness 端点意外运行了昂贵深度检查。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“同一检查带多个标签时只会执行第一个标签”定性，不再检查配置、身份或运行时证据。
- B. 先验证“标签只是筛选元数据，命名和分组应与编排平台探针目的一致”，再依据“注册检查时可添加 tags，映射端点时用 Predicate 选择检查集合”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“标签只是筛选元数据，命名和分组应与编排平台探针目的一致”。
- D. 以一次成功请求作为结论，不再确认“注册检查时可添加 tags，映射端点时用 Predicate 选择检查集合”是否成立。
查看答案与解析
正确答案B
场景“readiness 端点意外运行了昂贵深度检查”指向 健康检查标签，但症状本身不能证明根因。正确排查应先确认边界“标签只是筛选元数据，命名和分组应与编排平台探针目的一致”，再用主规则“注册检查时可添加 tags，映射端点时用 Predicate 选择检查集合”解释证据。直接采用误区“同一检查带多个标签时只会执行第一个标签”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0727 关于 健康检查标签，以下哪项说法不成立？
难度： 实战
- A. 注册检查时可添加 tags，映射端点时用 Predicate 选择检查集合
- B. 标签只是筛选元数据，命名和分组应与编排平台探针目的一致
- C. 同一检查带多个标签时只会执行第一个标签
- D. 出现“readiness 端点意外运行了昂贵深度检查”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“同一检查带多个标签时只会执行第一个标签”正是 健康检查标签 的典型误区。其余三项分别给出了主规则“注册检查时可添加 tags，映射端点时用 Predicate 选择检查集合”、适用边界“标签只是筛选元数据，命名和分组应与编排平台探针目的一致”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0728 针对“readiness 端点意外运行了昂贵深度检查”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“同一检查带多个标签时只会执行第一个标签”修改实现，并把一次请求成功作为验收结果。
- B. 按“注册检查时可添加 tags，映射端点时用 Predicate 选择检查集合”修改代码后直接上线，不验证“标签只是筛选元数据，命名和分组应与编排平台探针目的一致”。
- C. 只验证“标签只是筛选元数据，命名和分组应与编排平台探针目的一致”，但实现仍继续依赖“同一检查带多个标签时只会执行第一个标签”。
- D. 按“注册检查时可添加 tags，映射端点时用 Predicate 选择检查集合”修正实现，并用测试或遥测验证“标签只是筛选元数据，命名和分组应与编排平台探针目的一致”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：注册检查时可添加 tags，映射端点时用 Predicate 选择检查集合；并确认 标签只是筛选元数据，命名和分组应与编排平台探针目的一致。继续接受“同一检查带多个标签时只会执行第一个标签”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“readiness 端点意外运行了昂贵深度检查”这一生产场景能否安全上线。
0729 在 超时与取消 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 健康检查应响应 CancellationToken 并设置合理超时，避免探针堆积
- B. HealthCheckService 会强制终止所有阻塞线程
- C. 依赖客户端本身也要有超时，外层取消并不能保证不可取消调用立刻停止
- D. 观察到“下游无响应导致探针请求不断累积”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 超时与取消 的主规则：健康检查应响应 CancellationToken 并设置合理超时，避免探针堆积。选项“依赖客户端本身也要有超时，外层取消并不能保证不可取消调用立刻停止”是使用规则时要验证的边界，不是规则本身；“HealthCheckService 会强制终止所有阻塞线程”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0730 下游无响应导致探针请求不断累积。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“HealthCheckService 会强制终止所有阻塞线程”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“依赖客户端本身也要有超时，外层取消并不能保证不可取消调用立刻停止”。
- C. 以一次成功请求作为结论，不再确认“健康检查应响应 CancellationToken 并设置合理超时，避免探针堆积”是否成立。
- D. 先验证“依赖客户端本身也要有超时，外层取消并不能保证不可取消调用立刻停止”，再依据“健康检查应响应 CancellationToken 并设置合理超时，避免探针堆积”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“下游无响应导致探针请求不断累积”指向 超时与取消，但症状本身不能证明根因。正确排查应先确认边界“依赖客户端本身也要有超时，外层取消并不能保证不可取消调用立刻停止”，再用主规则“健康检查应响应 CancellationToken 并设置合理超时，避免探针堆积”解释证据。直接采用误区“HealthCheckService 会强制终止所有阻塞线程”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0731 关于 超时与取消，以下哪项说法不成立？
难度： 实战
- A. 健康检查应响应 CancellationToken 并设置合理超时，避免探针堆积
- B. 依赖客户端本身也要有超时，外层取消并不能保证不可取消调用立刻停止
- C. HealthCheckService 会强制终止所有阻塞线程
- D. 出现“下游无响应导致探针请求不断累积”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“HealthCheckService 会强制终止所有阻塞线程”正是 超时与取消 的典型误区。其余三项分别给出了主规则“健康检查应响应 CancellationToken 并设置合理超时，避免探针堆积”、适用边界“依赖客户端本身也要有超时，外层取消并不能保证不可取消调用立刻停止”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0732 针对“下游无响应导致探针请求不断累积”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“HealthCheckService 会强制终止所有阻塞线程”修改实现，并把一次请求成功作为验收结果。
- B. 按“健康检查应响应 CancellationToken 并设置合理超时，避免探针堆积”修正实现，并用测试或遥测验证“依赖客户端本身也要有超时，外层取消并不能保证不可取消调用立刻停止”。
- C. 按“健康检查应响应 CancellationToken 并设置合理超时，避免探针堆积”修改代码后直接上线，不验证“依赖客户端本身也要有超时，外层取消并不能保证不可取消调用立刻停止”。
- D. 只验证“依赖客户端本身也要有超时，外层取消并不能保证不可取消调用立刻停止”，但实现仍继续依赖“HealthCheckService 会强制终止所有阻塞线程”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：健康检查应响应 CancellationToken 并设置合理超时，避免探针堆积；并确认 依赖客户端本身也要有超时，外层取消并不能保证不可取消调用立刻停止。继续接受“HealthCheckService 会强制终止所有阻塞线程”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“下游无响应导致探针请求不断累积”这一生产场景能否安全上线。
0733 在 健康检查输出 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 把详细 JSON 放在随机路径即可视为安全
- B. 默认健康端点可只返回状态，详细依赖信息应限制访问并避免泄密
- C. 公开互联网不应暴露数据库名、内部地址和异常堆栈
- D. 观察到“攻击者从健康端点获取内部服务拓扑”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 健康检查输出 的主规则：默认健康端点可只返回状态，详细依赖信息应限制访问并避免泄密。选项“公开互联网不应暴露数据库名、内部地址和异常堆栈”是使用规则时要验证的边界，不是规则本身；“把详细 JSON 放在随机路径即可视为安全”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0734 攻击者从健康端点获取内部服务拓扑。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“把详细 JSON 放在随机路径即可视为安全”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“公开互联网不应暴露数据库名、内部地址和异常堆栈”。
- C. 以一次成功请求作为结论，不再确认“默认健康端点可只返回状态，详细依赖信息应限制访问并避免泄密”是否成立。
- D. 先验证“公开互联网不应暴露数据库名、内部地址和异常堆栈”，再依据“默认健康端点可只返回状态，详细依赖信息应限制访问并避免泄密”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“攻击者从健康端点获取内部服务拓扑”指向 健康检查输出，但症状本身不能证明根因。正确排查应先确认边界“公开互联网不应暴露数据库名、内部地址和异常堆栈”，再用主规则“默认健康端点可只返回状态，详细依赖信息应限制访问并避免泄密”解释证据。直接采用误区“把详细 JSON 放在随机路径即可视为安全”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0735 关于 健康检查输出，以下哪项说法不成立？
难度： 实战
- A. 把详细 JSON 放在随机路径即可视为安全
- B. 默认健康端点可只返回状态，详细依赖信息应限制访问并避免泄密
- C. 公开互联网不应暴露数据库名、内部地址和异常堆栈
- D. 出现“攻击者从健康端点获取内部服务拓扑”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“把详细 JSON 放在随机路径即可视为安全”正是 健康检查输出 的典型误区。其余三项分别给出了主规则“默认健康端点可只返回状态，详细依赖信息应限制访问并避免泄密”、适用边界“公开互联网不应暴露数据库名、内部地址和异常堆栈”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0736 针对“攻击者从健康端点获取内部服务拓扑”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“把详细 JSON 放在随机路径即可视为安全”修改实现，并把一次请求成功作为验收结果。
- B. 按“默认健康端点可只返回状态，详细依赖信息应限制访问并避免泄密”修改代码后直接上线，不验证“公开互联网不应暴露数据库名、内部地址和异常堆栈”。
- C. 按“默认健康端点可只返回状态，详细依赖信息应限制访问并避免泄密”修正实现，并用测试或遥测验证“公开互联网不应暴露数据库名、内部地址和异常堆栈”。
- D. 只验证“公开互联网不应暴露数据库名、内部地址和异常堆栈”，但实现仍继续依赖“把详细 JSON 放在随机路径即可视为安全”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：默认健康端点可只返回状态，详细依赖信息应限制访问并避免泄密；并确认 公开互联网不应暴露数据库名、内部地址和异常堆栈。继续接受“把详细 JSON 放在随机路径即可视为安全”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“攻击者从健康端点获取内部服务拓扑”这一生产场景能否安全上线。
0737 在 HealthCheckPublisher 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. Publisher 失败会自动让 Kestrel 停止接收请求
- B. 发布器执行频率、超时和失败处理需受控，不能因监控故障影响业务可用性
- C. IHealthCheckPublisher 可定期消费健康报告用于推送或记录
- D. 观察到“指标后端故障导致健康发布任务持续堆积”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 HealthCheckPublisher 的主规则：IHealthCheckPublisher 可定期消费健康报告用于推送或记录。选项“发布器执行频率、超时和失败处理需受控，不能因监控故障影响业务可用性”是使用规则时要验证的边界，不是规则本身；“Publisher 失败会自动让 Kestrel 停止接收请求”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0738 指标后端故障导致健康发布任务持续堆积。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“Publisher 失败会自动让 Kestrel 停止接收请求”定性，不再检查配置、身份或运行时证据。
- B. 先验证“发布器执行频率、超时和失败处理需受控，不能因监控故障影响业务可用性”，再依据“IHealthCheckPublisher 可定期消费健康报告用于推送或记录”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“发布器执行频率、超时和失败处理需受控，不能因监控故障影响业务可用性”。
- D. 以一次成功请求作为结论，不再确认“IHealthCheckPublisher 可定期消费健康报告用于推送或记录”是否成立。
查看答案与解析
正确答案B
场景“指标后端故障导致健康发布任务持续堆积”指向 HealthCheckPublisher，但症状本身不能证明根因。正确排查应先确认边界“发布器执行频率、超时和失败处理需受控，不能因监控故障影响业务可用性”，再用主规则“IHealthCheckPublisher 可定期消费健康报告用于推送或记录”解释证据。直接采用误区“Publisher 失败会自动让 Kestrel 停止接收请求”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0739 关于 HealthCheckPublisher，以下哪项说法不成立？
难度： 实战
- A. IHealthCheckPublisher 可定期消费健康报告用于推送或记录
- B. 发布器执行频率、超时和失败处理需受控，不能因监控故障影响业务可用性
- C. 出现“指标后端故障导致健康发布任务持续堆积”时，应收集证据并同时核对主规则与适用边界。
- D. Publisher 失败会自动让 Kestrel 停止接收请求
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“Publisher 失败会自动让 Kestrel 停止接收请求”正是 HealthCheckPublisher 的典型误区。其余三项分别给出了主规则“IHealthCheckPublisher 可定期消费健康报告用于推送或记录”、适用边界“发布器执行频率、超时和失败处理需受控，不能因监控故障影响业务可用性”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0740 针对“指标后端故障导致健康发布任务持续堆积”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“IHealthCheckPublisher 可定期消费健康报告用于推送或记录”修正实现，并用测试或遥测验证“发布器执行频率、超时和失败处理需受控，不能因监控故障影响业务可用性”。
- B. 按“Publisher 失败会自动让 Kestrel 停止接收请求”修改实现，并把一次请求成功作为验收结果。
- C. 按“IHealthCheckPublisher 可定期消费健康报告用于推送或记录”修改代码后直接上线，不验证“发布器执行频率、超时和失败处理需受控，不能因监控故障影响业务可用性”。
- D. 只验证“发布器执行频率、超时和失败处理需受控，不能因监控故障影响业务可用性”，但实现仍继续依赖“Publisher 失败会自动让 Kestrel 停止接收请求”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：IHealthCheckPublisher 可定期消费健康报告用于推送或记录；并确认 发布器执行频率、超时和失败处理需受控，不能因监控故障影响业务可用性。继续接受“Publisher 失败会自动让 Kestrel 停止接收请求”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“指标后端故障导致健康发布任务持续堆积”这一生产场景能否安全上线。