# 1. Backstage Software Catalog 的实体模型中 Component/API/Resource/System/Domain/Group 的关系建模、catalog-info.yaml 的自动化生成与治理 A Catalog 只有 Component 一种实体类型 B Component/API/Resource/System/Domain/Group 通过 owner、dependsOn、system 等关系建模，catalog-info.yaml 可自动化生成并治理 ✓ 正确答案 C catalog-info.yaml 只能手工维护，无法自动生成 D 实体间无关系，无法展示依赖图
# 2. Backstage 插件开发实战中自定义插件的前后端架构（React + Node.js）、与 Kubernetes/CI/CD/监控系统的集成及插件市场发布 A Backstage 插件只有前端，无后端部分 B 前端直接携带数据库凭据调用外部系统 C 插件采用 React 前端 + Node.js 后端双架构，后端封装对外部系统的集成，插件可打包为 npm 包发布 ✓ 正确答案 D 插件无法与 Kubernetes 或 CI/CD 集成
# 3. Backstage 的部署与运维中 PostgreSQL 存储、OIDC 认证配置、插件升级与数据备份恢复 A Backstage 不依赖数据库，数据全部内存存储 B OIDC 认证与部署无关，无需配置 C Backstage 用 PostgreSQL 存储目录数据，通过 OIDC 接入企业身份，插件升级需重建镜像并做好备份恢复 ✓ 正确答案 D 插件升级无需考虑兼容性，直接替换即可
# 4. Port 的 Self-Service Actions 设计中 Blueprint/Entity/Action 模型、GitHub Actions/Jenkins/ArgoCD 作为后端执行器、审批流与 RBAC A Port 用 Blueprint/Entity/Action 建模，Action 通过 GitHub Actions/Jenkins/ArgoCD 等后端执行器执行，并配置审批流与 RBAC ✓ 正确答案 B Blueprint 是实体实例，Action 是实体类型 C Self-Service Action 只能由平台团队手工执行 D Port 的 RBAC 与审批流互不关联
# 5. 开发者门户的服务健康度看板中集成 SLO 状态、最近部署、告警、On-Call 信息、Tech Debt 评分以打造单一服务视图 A 服务健康度看板只展示 SLO 数据，不集成其他信息 B 门户把 SLO、部署、告警、On-Call、Tech Debt 聚合到单一服务视图，按服务维度关联各系统数据 ✓ 正确答案 C On-Call 信息无法集成到门户 D 看板数据无需实时更新，手工刷新即可
# 6. Backstage 架构解析中后端插件、前端插件与 Catalog 处理器的协作机制 A 前端插件展示、后端插件封装集成、Catalog 处理器采集实体，三者通过 API 与数据层协作 ✓ 正确答案 B Catalog 处理器负责前端 UI 渲染 C 后端插件直接访问数据库，无需通过 API D Catalog 数据由前端插件手工写入
# 7. Backstage 的 TechDocs 与文档即代码中 MkDocs 集成、文档质量评分、API 文档（OpenAPI/AsyncAPI）自动发现与渲染 A TechDocs 需要单独搭建文档站，与代码仓库分离 B TechDocs 用 MkDocs 实现文档即代码，通过质量评分与 OpenAPI/AsyncAPI 自动渲染实现文档与 API 一站式呈现 ✓ 正确答案 C 文档质量评分与代码无关，无法自动化 D API 文档需手工编写，无法从 OpenAPI 自动发现
# 8. Backstage 软件目录（catalog-info.yaml）如何建模服务、资源、所有权与依赖？ A catalog-info.yaml 无法表达所有权与依赖关系 B 服务用 Component、资源用 Resource 建模，owner 表达所有权，dependsOn/providesApis 表达依赖与归属 ✓ 正确答案 C 服务只能建模为 Resource，无法区分类型 D 所有权字段 owner 只能指向 User，不能指向 Group
# 9. 开发者门户的插件体系中 TechDocs、Scaffolder 模板与权限如何配置？ A TechDocs、Scaffolder 与权限插件通过 app-config.yaml 与插件包配置，模板与权限策略可自定义 ✓ 正确答案 B 插件无法通过配置文件启用，只能改源码 C Scaffolder 模板只能使用内置模板，无法自定义 D 权限插件与 TechDocs 无关，无法统一管理
# 10. 开发者门户的搜索与发现中全文检索、标签体系、服务依赖图可视化与新功能 onboarding 引导 A 门户搜索只能搜索实体，无法搜索文档 B 依赖图无法从 Catalog 关系自动生成 C 标签体系与搜索无关，无需统一 D 全文检索、标签体系、依赖图可视化与 onboarding 引导共同提升门户的可发现性与上手体验 ✓ 正确答案
# 11. 开发者门户自助操作的安全中 Action 执行权限审计、执行日志留痕与最小权限授权模型 A 自助操作无需审计，执行后即可 B Action 执行需校验权限并留痕，遵循最小权限授权模型，配合审批流实现可追溯、可问责 ✓ 正确答案 C 最小权限模型指所有用户拥有相同权限 D 执行日志只记录成功操作，失败无需记录
# 12. 软件目录的数据质量治理中实体所有权缺失、重复实体与孤儿实体的自动化巡检与修复 A 目录数据质量无需治理，自动生成即可保持准确 B 重复实体无法自动检测，只能手工比对 C 孤儿实体无需处理，不影响使用 D 通过自动化巡检发现所有权缺失、重复与孤儿实体，配合 CI 门禁与批量修复保持目录质量 ✓ 正确答案
# 13. Backstage 的权限框架（Permission Framework）中基于策略的访问控制、与 OAuth2/OIDC 集成及多团队权限隔离 A Permission Framework 只能做全有或全无的授权 B 权限判断与用户身份无关 C 权限框架基于策略判断，通过 OIDC 注入身份，结合用户组与实体归属实现多团队权限隔离 ✓ 正确答案 D 多团队隔离无法通过权限框架实现
# 14. 开发者门户的核心能力中服务发现、文档聚合与所有权信息如何一站式呈现 A 门户只做服务发现，不聚合文档与所有权 B 门户把服务发现、文档聚合与所有权信息聚合到统一服务实体页，提供一站式单一视图 ✓ 正确答案 C 所有权信息由各团队手工维护，无法在门户展示 D 文档需在独立系统查看，无法聚合到门户
# 15. 门户与 CI/CD 的深度集成中把模板脚手架、部署审批与质量门禁串成一条自助链路 A 脚手架生成的代码需手工配置 CI/CD B 部署审批无需纳入流水线，手动执行即可 C 质量门禁与门户无关，开发者自行检查 D 门户把模板脚手架、部署审批与质量门禁串成自助链路，让开发者从创建到上线全程自助受控 ✓ 正确答案
# 16. 门户定制实践中 Catalog 模板、权限策略与第三方集成的配置方法 A 门户定制必须修改核心源码，无法通过配置实现 B 第三方集成无法通过 app-config.yaml 配置 C 权限策略是固定的，无法自定义 D Catalog 模板、权限策略与第三方集成通过配置与自定义插件实现，遵循"配置优先"原则 ✓ 正确答案
# 17. 门户的运维中 Catalog 数据更新频率、插件升级与性能监控如何管理 A 门户运维需管理 Catalog 更新频率、插件升级与性能监控，三者平衡以保证可用性 ✓ 正确答案 B Catalog 数据只能定时采集，无法实时更新 C 插件升级无需测试，直接替换即可 D 门户性能无需监控，出问题再说
# 18. 门户采用度度量中开发者活跃度、自助成功率与黄金路径使用率如何定义？ A 门户采用度只看活跃用户数 B 活跃度反映使用频率、自助成功率反映自助效率、黄金路径使用率反映标准化程度，三者组合度量采用度 ✓ 正确答案 C 自助成功率与是否人工介入无关 D 黄金路径使用率无法从门户数据统计
# 19. 门户采用推广中团队 onboarding、反馈收集与采用率提升的实践 A 通过 onboarding 引导、反馈收集与标杆示范、默认入口等策略，让门户真正被团队采用 ✓ 正确答案 B 门户上线后无需推广，开发者自然会用 C 反馈收集只能靠工单，无法用访谈 D 强制所有团队立即切换是最高效的推广方式
