简介：适用于备考1+X云计算平台运维与开发认证（中级）的考生，这份docx文档汇集了认证考试中的总题库试题与详细答案解析，内容覆盖项目管理流程与敏捷开发、软件版本控制工具、VRRP/STP/DHCP等网络协议、Nginx信号与配置加载、OpenStack消息服务与Neutron命令、Kubernetes最小调度对象Pod、Shell种类、MySQL数据库操作、腾讯云按量计费及CDN加速等高频考点。文档以单选题为主，每题均标注正确答案，方便考生逐题自测并对照理解。整个资源为1个docx文件，包体仅46KB，轻量便于下载和手机端翻阅。目前已有1076人学习下载，适合需要在考前集中刷题、快速排查知识短板的云计算爱好者与备考学员，既可当作模拟练习，也可作为知识点速查手册。
1. 云计算中级认证刷题：这份真题集把考点密度和出题套路一次摊开
准备 1+x 云计算平台运维与开发认证（中级）的考生，最头疼的不是题目难，而是不知道选择题到底考多深。这份 docx 收录了 80 多道单选题，从 SVN 和项目管理流程，到 VRRP 组播地址、OpenStack 组件职责、Docker 命名空间、Ansible 配置路径，再到腾讯云按量计费和 CDN 加速，基本把中级认证选择题的知识域铺满了。它能帮你解决两个实际问题：一是用一套题快速自测，定位自己哪块知识是空白；二是从答案解析里反推出题人的习惯——哪些点反复考、哪些选项专门用来坑人。适合正在备考、想压缩复习周期的人，也适合想拿一套完整题量做岗前自测的运维新手。
2. 考点地图：从 80 多道单选反推出题人的六个知识域
拿到这套题，先别急着逐题刷。我习惯先把题目按知识域归类，看看每块占多少比重，再决定复习精力往哪放。这套题里网络协议、OpenStack、腾讯云产品、数据库与自动化工具、项目管理与 Linux 基础、云服务模型六块都有覆盖，而且出题方式很有规律。
2.1 网络基础：VRRP、STP、VLAN 的常考形态
网络题在这套题里占比不低，但考得很收敛，基本都是协议的关键数值和状态机。VRRP 那题问固定组播地址，答案是 224.0.0.18，这个地址是 VRRP 报文的目的组播地址，所有运行 VRRP 的路由器都监听这个组。端口聚合那题更直白，2 个 100Mb/s 物理端口聚合成逻辑口，速率就是 200Mb/s，聚合是把多个物理链路捆成一个逻辑链路，带宽叠加。
STP 和 RSTP 是另一组高频考点。STP 的本质是二层链路管理协议，作用是在有物理环路的网络里通过阻塞冗余端口来消除环路，同时保留备份路径。题目里说「被阻塞端口没有被激活」，这个表述容易让人误判，其实阻塞端口只是不转发数据帧，但还接收 BPDU 参与生成树计算。RSTP 相比 STP 最大的变化是状态从 5 个减到 3 个：丢弃、学习、转发，原来 STP 里的监听状态被合并进丢弃状态了，所以「监听状态不是 RSTP 工作状态」这个判断要记住。
VLAN 的取值范围 1-4094 也是必记的，0 和 4095 是保留的，不能用于常规 VLAN。交换机二层转发还有个经典题：MAC 地址表查不到目的地址时怎么办？答案是向除入端口外的所有端口泛洪，这是二层交换机和路由器的本质区别，路由器查不到路由表会丢包，交换机查不到 MAC 表项反而要把帧广播出去。
2.2 OpenStack 组件职责：认证、消息、存储、计算各管一摊
OpenStack 是这套题的重头戏。它的组件非常多，但选择题只考职责对应关系，记住一句话就能应付大半：Keystone 管认证、RabbitMQ 管消息、Nova 管计算、Glance 管镜像、Swift 管对象存储、Cinder 管块存储、Neutron 管网络、Horizon 管界面。这 8 个组件两两之间别搞混，基本就稳了。
题目里有两个容易踩的细节。第一个是「OpenStack 各组件之间通信的核心」，答案是 Keystone，因为所有组件调用 API 之前都要先过认证，所以它不只是给用户发令牌，内部服务间的通信也靠它做信任授权。第二个是 Swift 的存储方式，默认保存 3 个副本，题目问的是副本数而不是存储节点数，这个 3 是硬编码的默认值，改副本数要改配置文件。
命令类的题也有规律。Neutron 查网络列表用neutron network-list，查代理列表用neutron agent-list，注意题干问的是「网络服务列表」还是「代理列表」，一字之差答案不同。Swift 创建容器用swift post，这个命令名容易和 HTTP 的 POST 方法搞混，其实 swift 命令里 post 就是创建容器和上传对象的入口。另外 Horizon 是 Essex 版本正式发布的，Cactus 和 Diablo 都是更早的开发版，这个版本线选择题只需要记住 Essex。
2.3 腾讯云产品题：按量计费、CDN、CDB 的场景化考法
云厂商产品在这套题里占了约四分之一，考法和前面完全不同，题目会给你一个业务场景，让你选产品或者判断描述对错。按量计费连出两道，核心点是：先使用后付款、灵活调整资源、用多少付多少，但单位价格不一定比预付费低，预付费有折扣所以单价更便宜，所以「单位价格较预付费低」反而是错误描述。这里有个小陷阱是「较大量资源临时增加时可能出现无资源可用」，这是真实存在的风险，按量计费不承诺资源预留。
计费计算题就一道，但很典型：500G SSD 云硬盘按量计费，单价 0.0033 元/GB×结算单位，用 2 小时，就是 500×2×0.0033=3.3 元。注意结算单位是小时，单价是按 GB 算的，别把两个维度搞混。
CDN 那几道题在考产品边界。CDN 提供静态内容加速、下载分发加速、音视频点播加速，直播加速不在其中，因为直播是实时流不适合做缓存分发。CDB 关系型数据库有个选项是「默认支持双主备份模式」，这个表述是错的，CDB 默认是主从架构，不是双主。HttpDNS 那道题特别典型：音视频 APP 连接成功率低、解析超时，答案是使用 HttpDNS 服务，因为传统 DNS 解析依赖运营商本地 DNS，容易遭劫持或超时，HttpDNS 用 HTTP 协议直接向权威服务器查询，绕过本地 DNS。
3. 命令题实操：把选择题变成可复现的真机验证
刷题时最亏的是一类题——命令明明在 Linux 上敲一下就出结果，但考试只能靠背。我的习惯是把这类题挑出来，在虚拟机里逐个验证一遍，验证完基本不会忘。
3.1 MySQL：建库命令、备份参数与主从复制的三步走
题库里 MySQL 相关的题有一个共同点：考命令格式和参数含义，不考 SQL 语法。创建 test 数据库那道题，正确命令是mysqladmin -uroot -p000000 create test，注意两点：一是用mysqladmin而不是mysql，mysql 命令是进入交互式客户端用的，不能直接create database；二是-p和密码之间不能有空格，写成-p 000000会被当成密码是「空格」然后报错。
# 创建数据库 test mysqladmin -uroot -p000000 create test # 备份指定数据库，-u 指定用户，-p 提示输入密码 mysqldump -uroot -p000000 --databases test > /backup/test.sql # 查看二进制日志当前位置，用于主从复制 mysql -uroot -p000000 -e "SHOW MASTER STATUS;"mysqldump的-u参数后面跟用户名，-p后面直接跟密码，--databases表示导出时带上 CREATE DATABASE 语句，这样恢复时不用手动建库。主从复制那道题问的是整体分几步，答案是 3 步：主库开启二进制日志并记录日志位置、从库配置主库连接信息、启动复制。默认复制方式是「基于语句的复制」，也就是把主库执行的 SQL 语句原样在从库重放一遍，这种效率比基于行复制高，但遇到 NOW() 之类非确定性函数会有数据不一致风险。
3.2 Nginx：主进程通信与 HUP 重载的实验验证
Nginx 的进程模型题很稳定：主进程负责管理工作进程，worker 进程负责处理实际请求，操作 Nginx 时要给主进程发信号而不是直接操作 worker。题目里 reload 的命令是kill -HUP pid，这个 pid 必须是主进程的 PID，读到 HUP 信号后主进程会先重新加载配置，再启动新的 worker 平滑替换旧 worker。
# 查看 nginx 主进程 PID cat /var/run/nginx.pid # 给主进程发送 HUP 信号，平滑重载配置 kill -HUP $(cat /var/run/nginx.pid) # 等效于 nginx -s reload，验证主进程 PID 没有变化 ps -ef | grep nginx实验时可以先记下主进程 PID，执行 reload 后再看一次，主进程 PID 不变，worker 的 PID 变了，这就直观理解了「主进程管理 worker」的含义。nginx -s reload底层走的也是 HUP 信号，所以两种方式等价，考试如果问信号类型就选 HUP。
3.3 Docker 与 K8s：命名空间、Dockerfile 指令与最小调度单元
Docker 题集中在三个点：命名空间、Dockerfile、调度单元。命名空间那道题问 Docker 用到了哪些，答案是 PID、NET、IPC 都是，实际上 Docker 还用了 UTS、MNT、USER，一共 6 类命名空间。验证方法很直观，在容器里看/proc/<pid>/ns/目录：
# 启动一个容器，找到容器内进程的 PID docker run -d --name ns-test nginx sleep 300 docker inspect ns-test --format '{{.State.Pid}}' # 查看该进程的命名空间链接，能看到 pid、net、ipc、uts、mnt、user ls -l /proc/$(docker inspect ns-test --format '{{.State.Pid}}')/ns/Dockerfile 指令题只考 RUN 的含义，就是构建镜像时执行的 Linux 命令，其他指令如 FROM 定义基础镜像、MAINTAINER 写作者、ADD 添加文件，每个指令的职责要分清。K8s 最小操作对象是 Pod，这是调度和运行的最小单元，一个 Pod 里可以有一个或多个容器共享网络和存储。Docker Swarm 的最小部署单元是 Task，对应一个容器实例，Service 是 Task 的集合，Stack 是 Service 的集合，层级关系别记反。
3.4 Ansible 与 ZooKeeper：资产清单与 Leader 同步状态机
Ansible 的题很基础，但考的都是「文件在哪、靠什么工作」这类实操定位问题。inventory 主机清单文件的位置是/etc/ansible/hosts，注意不是/etc/ansible目录本身，也不是ansible.cfg。Ansible 基于模块工作，通过 SSH 协议执行任务，用 Python 语言开发，这三件事分别对应三个题。
# 模拟 ZooKeeper 选主后的 zxid 同步判断 follower_zxids = {"f1": 100, "f2": 80, "f3": 120} leader_zxid = max(follower_zxids.values()) for name, zxid in follower_zxids.items(): if zxid < leader_zxid: print(f"{name}: 需要从 Leader 同步，zxid={zxid}") else: print(f"{name}: 已是最新，zxid={zxid}")ZooKeeper 那题问选完 Leader 后状态同步的顺序，答案是 5 步：Leader 等连接、Follower 上报最大 zxid、Leader 确定同步点、通知 uptodate、Follower 重新对外服务。核心逻辑是 zxid 越大代表事务越新，Follower 的 zxid 小于 Leader 的同步点就要补齐数据，这个用上面的 Python 脚本模拟一遍就理解为什么顺序是 12345 了。
4. 理论题解法：项目管理、Shell 与网络排查的送分与丢分边界
理论题看着简单，实际是这套题里丢分最惨的部分。原因很统一：不是不会，是没理解出题人喜欢在哪个词上做文章。
4.1 项目管理流程：立项、计划、部署阶段谁该在场
项目管理单选不多，但雷点密集。第一道是「哪个阶段不是项目管理流程中的阶段」，答案是项目质保，流程只有立项、开发、测试、部署运维，质保是质量体系的概念不是项目阶段。第二道问敏捷开发「可以单独迭代多次但不包括哪个过程」，答案计划，敏捷开发里计划是持续进行的轻量活动，不会像开发、测试、发布那样单独迭代。第三道问立项启动阶段开发经理不需要验证哪份报告，答案是《项目计划书》，立项阶段计划书还没做出来，用户需求说明书、立项建议书、可行性分析报告才是立项阶段要看的。这些题都有个共同解法：站在阶段时间线上去推，立项阶段不可能有项目计划书，部署阶段开发人员不需要参与，因为代码已经交付，剩下是运维和测试的事。
4.2 Shell 与 Linux：C 语言编写、vi 退出与网络故障排查
Shell 相关题考的是基础和偏门。Shell 本身是用 C 语言写的程序，常见的 Bourne Shell、Bourne-Again Shell、Korn Shell 是不同流派，J2SE 是 Java 平台跟 Shell 没有任何关系。用户按照 Shell 语言规范写的脚本保存为文件，这题是送分但容易选成目录或压缩包。vi 编辑器强制退出不保存是:q!，:q在有修改时会拒绝退出，:wq是保存退出，:!q是执行外部命令 q，这道题考的是冒号和感叹号的位置。
# 查看 CPU 信息 cat /proc/cpuinfo # 查看内存信息 cat /proc/meminfo # 查看 swap 分区信息 cat /proc/swaps # 查看磁盘分区使用情况，注意是 df 不是 du df -h查看硬件信息的命令也有一道经典坑题：CPU 看/proc/cpuinfo、内存看/proc/meminfo、swap 看/proc/swaps都是对的，唯独「用 du -h 查看硬盘信息」是错的，du 是统计目录占用空间，看磁盘分区要用df -h。另外init不是网络故障排查命令，网络排查常用的是 ping、telnet、netstat，init 是切换系统运行级别的。
4.3 云服务模型：IaaS、PaaS、SaaS 的选择逻辑与边界判断
云服务模型的题核心是判断边界。客户要「开箱即用、统一服务流程和体验」，选 SaaS，因为 SaaS 连应用都给你部署好了。需要自己管虚拟机选 IaaS，需要开发平台选 PaaS，这个分类判断是送分题，但题干如果带「开箱即用」三个字就别犹豫，直接 SaaS。
弹性伸缩那题描述正确的是「根据服务器压力自动增加或减少实例」，这是弹性伸缩的核心定义，其他选项像「特殊软性材质生产」是纯干扰项。上云需求特征里「拥有更多固定资产」是错的，上云的本质是用租代建、轻资产。小微企业用云计算能得到的好处里，「获得大量机房管理经验」是错的，恰恰相反，上云就是为了不自己管机房。私有云基础架构的基石是虚拟化，不是分布式也不是并行，虚拟化把物理资源池化才能谈弹性。租户网络那题有点反直觉：不同租户之间可以设置冲突的 IP 地址，因为租户网络是通过虚拟化隔离的，各自独立互不影响，所以默认也不能互 ping 通。
5. 刷题避坑指南：五类最容易翻车的考点与处理记录
这套题刷下来，我把最容易错的五类情况记录一下，每条都是实际踩过的坑，按「现象 → 原因 → 解决」列清楚。
5.1 同一道题出现两次，答案选项顺序还不一样
现象：腾讯云按量计费那道题在 12 题和 16 题里重复出现，连选项都一样，很容易以为是自己刷重了，结果在选答案时反而犹豫。 原因：这套题是从多个模拟卷合并而来的，没有去重，而且重复题的正确答案位置没有变，都是 C，但考生会因为「怎么又是这题」而怀疑自己的第一判断。 解决：遇到重复题直接当复习题做，不要重新推理。这种重复其实是好事，说明这个考点出题概率高，按量计费「单位价格较预付费低是错误描述」这个结论值得单独记进笔记。
5.2 命令题选项只有空格差异，答错在细节
现象：mysqladmin -uroot -p000000 create test这道题，四个选项只有空格位置不同，很容易选成带空格的写法。 原因：Linux 命令的-p参数后面跟密码时不能有空格，有空格会把密码解析为只读了一个空格字符，然后提示输入密码。出题人就是拿这个细节做区分点。 解决：做题时看见命令行选项和参数之间疑似有空格的，先在心里把它还原成实际执行效果。这类题不需要死记，真机敲一遍就记住了，后面刷到任何含-p的命令都先检查空格。
5.3 子网划分计算题：/24 用 240 掩码能分出 16 个可用子网
现象：192.168.0.0/24 用掩码 255.255.255.240 划分子网，问可用子网数和每个子网可用主机数，很容易算成 14 和 16，把两个数字的位置搞反。 原因：255.255.255.240 意味着最后一个字节的高 4 位是网络位，低 4 位是主机位。256 除以 16 得到 16 个子网，每个子网 16 个地址，减去网络地址和广播地址各 1 个，可用主机是 14。这道题的答案是 16 和 14，顺序是「子网数在前、主机数在后」。 解决：计算时先确定掩码的位数偏移，240 对应二进制 11110000，子网数是 2 的 4 次方等于 16，主机数是 2 的 4 次方减 2 等于 14。这类题做错基本都是算对了但排反了顺序，答题前把「子网数、主机数」两个词圈出来再看一眼。
5.4 概念题被「绝对化表述」带偏
现象：CDB 那道题里「默认支持双主备份模式」看起来是产品优势，像是对的。Keystone 题里「令牌的有效期是无限的，可以随时被撤回」这个描述也混在正确选项里。 原因：出题人故意把错误表述写得像产品宣传语，双主备份听着比主从高级，令牌无限期听着比限时方便，但这些都不符合真实产品逻辑。CDB 默认主从架构，双主需要额外配置；Keystone 令牌有有效期，过期后必须重新认证。 解决：凡是带「默认」「无限」「随时」这类绝对化词汇的选项，先怀疑再验证。云产品和认证系统的设计原则都是安全优先，令牌不可能无限期，数据库默认不可能双主。这道题的记忆锚点就是「默认」和「无限」这两个词。
5.5 组件记忆混淆：Hive 和 Cinder、Swift 的分工边界
现象：OpenStack 组件题里问「哪个不是 OpenStack 组件」，容易在 Hive 和 Heat 之间犹豫。存储题里 Swift 和 Cinder 的功能也容易混。 原因：Hive 是 Hadoop 生态的数仓工具，不在 OpenStack 组件列表里，但名字长相和 Heat 接近，容易干扰记忆。Swift 管对象存储，适合图片、视频这类非结构化数据，Cinder 管块存储，给虚拟机提供云硬盘，一个是 REST API 访问，一个是挂载到虚拟机的块设备。 解决：用一个场景区分——往 Swift 里存文件用swift post命令，创建云硬盘用cinder create命令。前者面向对象，后者面向块设备。做题时先看题干是「对象存储容器」还是「云硬盘」，再选对应的组件名。
6. 错题转实验：用本地环境把记忆题变成肌肉记忆
刷题最怕的是「背了答案但没理解，换个说法就懵」。我的做法是把错误率高的题转成一组可以在本地跑的验证实验，每道题的原理跑通了，比背十遍选项都管用。
先在虚拟机里起两个 Docker 容器做 MySQL 主从验证，正好覆盖第 3 章那几道数据库题。主库开二进制日志，从库指定主库位置，启动复制后主库建表，从库自动同步，整个过程跑一遍，主从复制是 3 步还是 4 步、基于语句复制和基于行复制的区别，就全清楚了。
# 两个 MySQL 容器模拟主从 docker run -d --name mysql-master -e MYSQL_ROOT_PASSWORD=000000 mysql:8.0 docker run -d --name mysql-slave -e MYSQL_ROOT_PASSWORD=000000 mysql:8.0 # 主库创建复制用户并查看日志位置 docker exec mysql-master mysql -uroot -p000000 -e "CREATE USER 'repl'@'%' IDENTIFIED BY 'repl123'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; SHOW MASTER STATUS;" # 从库指定主库并启动复制 docker exec mysql-slave mysql -uroot -p000000 -e "CHANGE MASTER TO MASTER_HOST='mysql-master', MASTER_USER='repl', MASTER_PASSWORD='repl123'; START SLAVE;"Nginx 重载那题可以用一个容器验证，kill -HUP信号触发配置重载，主进程 PID 不变，新 worker 进程生成，这比干背信号名直观得多。ZooKeeper 同步顺序的题我给每台 Follower 设置不同的 zxid，用第 3 章那个 Python 脚本跑一遍，马上理解为什么先对比 zxid 再确定同步点。
我自己的习惯是每刷完一套题，就把错题按「命令类、协议类、概念类」分三个文件夹记录，命令类的必须在虚拟机里跑通才归档，协议类的画一张状态图，概念类的写一句人话笔记。从那以后我每次做认证题模拟卷都强制走一遍这个流程：先把错题转实验，再重刷一遍原题，正确率比纯刷题提高了不少。这个习惯后来做其他认证备考也一直在用，希望帮到你。
本文还有配套的精品资源，点击获取
