简介：这份资源是一套面向IT运维、云计算与项目管理方向学习者的选择题练习文档，内容覆盖项目管理流程、金融业务合规、OSI参考模型、VLAN与以太网标准、OpenStack组件、AWS云服务、Docker与Linux命令等核心考点，适合备考认证、巩固基础或进行知识自测的读者使用。资源包内共1个docx文件，约23KB，以题目与参考答案对照的形式组织，涵盖单选与多选两类题型，便于快速查阅与集中练习。文档中涉及Keystone认证服务、RDS支持的数据库引擎、EBS跨可用区迁移、收尾过程顺序、NAT容器通信吞吐率等具体知识点，可作为日常刷题与查漏补缺的参考材料。目前已有71人学习下载，适合需要系统梳理IT基础与云平台知识点的初、中级学习者。
1. 从一道选择题说起：项目管理流程里到底有没有“质保”这个阶段
如果你做过 IT 行业的笔试题，大概率见过这样一道题：下面哪个阶段不是项目管理流程中的阶段？选项里赫然列着“项目质保”。很多人第一反应是——质保怎么会不是阶段？产品做完了不都要质保吗？但正确答案偏偏就是它。
这背后其实藏着一个特别容易被忽略的认知：项目管理流程的阶段划分，和产品质量保障的工作内容，是两套不同的语言体系。项目管理流程通常按时间线走——立项、开发、测试、收尾，每个阶段有明确的输入输出和里程碑。而“质保”更像是一种贯穿始终的职能，它可能分布在测试阶段、验收阶段，甚至运维阶段，但它本身不构成一个独立的流程节点。
打个比方，做菜有“备菜、下锅、调味、装盘”几个流程，而“尝咸淡”这件事可能发生在任何一个环节，你不会把它单独列成一道工序。项目管理里的“质保”也是这个道理。搞懂这个区别，你再看那些 IT 基础笔试题，就不会被字面意思带偏了。
2. 为什么这些概念总被搞混：从 OSI 到 VLAN 的认知陷阱
2.1 分层模型里的“归属问题”：路由为什么在网络层
OSI 七层模型是 IT 笔试的常客，但很多人背了七层名字，却说不清某个功能到底属于哪一层。比如“路由”，它的核心任务是找路——把数据包从一个网络送到另一个网络。这个“找路”的动作，依赖的是 IP 地址，而 IP 地址工作在第三层，也就是网络层。
你可以这样理解：物理层是公路，数据链路层是路口的红绿灯和车道线，网络层是导航地图。导航告诉你从 A 城市到 B 城市走哪条高速，但它不关心你开的是轿车还是卡车。路由做的就是导航的活，所以它属于网络层。而交换机、VLAN 这些概念，更多是在数据链路层做文章——它们管的是同一个局域网内部怎么划分车道、怎么避免绕圈。
注意：OSI 是理论模型，实际网络里 TCP/IP 四层模型更常用，但笔试往往考 OSI，因为分层更清晰，方便出题。
2.2 VLAN 的本质：为什么说它是一个广播域
VLAN 这个缩写看起来唬人，全称是 Virtual Local Area Network，虚拟局域网。但如果你只记“虚拟局域网”五个字，做题时还是会懵。真正好用的理解是：VLAN 就是一个广播域。
什么是广播域？想象一个办公室，所有人都在一个大房间里喊话，谁喊一声所有人都能听见——这就是一个广播域。人多了就吵，效率低。VLAN 相当于把大房间用隔音玻璃分成若干小间，每个小间里的喊话只有自己人听得见。交换机上配置 VLAN，就是在逻辑上划分这些隔音间。
那 VLAN 的取值范围为什么是 1 到 4094？因为 VLAN 标签在以太网帧里占 12 个比特，2 的 12 次方是 4096，其中 0 和 4095 被保留不用，剩下就是 1 到 4094。这个数字不是随便定的，是协议里写死的。
2.3 容器与虚拟机：docker inspect 到底在看什么
Docker 相关的考题里，经常问“查看容器属性的方法”。选项里有 docker log、docker info、docker describe、docker inspect。正确答案是 docker inspect。为什么？因为 log 看的是日志，info 看的是 Docker 引擎的整体信息，describe 根本不是 Docker 的原生命令（那是 Kubernetes 的风格），只有 inspect 是专门用来“解剖”一个容器或镜像的——它返回的是 JSON 格式的详细配置，包括网络、挂载、环境变量、启动参数等等。
这就像你去医院做检查，log 是查病历，info 是查医院整体运营数据，inspect 才是给你拍 CT。搞懂每个命令的“职责边界”，比死记硬背有用得多。
3. 云平台与开源栈：那些容易混淆的服务和组件
3.1 OpenStack 的组件分工：Keystone、RabbitMQ、Ceilometer 各管什么
OpenStack 是一个庞大的开源云平台，里面组件多如牛毛，初学者最容易把功能搞串。我们挑三个高频考点来说。
Keystone 是认证服务。你可以把它理解成公司大楼的前台——你进去之前得先刷卡，刷卡通过后前台告诉你“你有权限去几楼、能进哪些房间”。OpenStack 里所有其他服务要干活，都得先找 Keystone 验明正身。
RabbitMQ 是消息服务。OpenStack 的各个组件之间需要互相通信，比如 Nova 要创建虚拟机，得通知 Neutron 配网络、通知 Cinder 挂硬盘。这些通知不是直接打电话，而是往 RabbitMQ 这个“消息队列”里扔纸条，对方有空了就来取。这样做的好处是解耦——发消息的人不用等对方回复，系统更稳。
Ceilometer 是监控服务，它收集云平台里的各种指标数据，比如 CPU 用了多少、内存剩多少。这些数据存到哪里？答案是 MongoDB。为什么不用 MySQL？因为监控数据是时序数据，写入量大、结构灵活，MongoDB 这种文档型数据库更合适。
3.2 AWS 的存储与网络：EBS、RDS、VPC 的边界在哪
AWS 的考题里，EBS 和 RDS 经常一起出现。EBS 是弹性块存储，你可以把它理解成一块可以插拔的硬盘，挂到 EC2 实例上当系统盘或数据盘用。RDS 是关系型数据库服务，它底层可能也用了 EBS，但用户不需要管硬盘，只需要选数据库引擎——目前支持六种：Amazon Aurora、Oracle、Microsoft SQL Server、PostgreSQL、MySQL 和 MariaDB。
VPC 是虚拟私有云，相当于你在 AWS 上圈了一块地，自己规划子网、路由表、网关。考题里常问“单个实例停止再启动后，公共 IP 会不会保留”。答案是：不会。因为公共 IP 是动态分配的，停止实例后就被回收了，重新启动会拿一个新的。如果你需要固定 IP，得用弹性 IP。
提示：EBS 卷只能在同一个可用区里挂载。想把卷挪到另一个可用区，必须先做快照，再从快照创建新卷。这就像你不能把一块硬盘直接从北京机房拔下来插到上海机房，得先拷贝数据。
3.3 容器编排与镜像构建：Kubernetes 和 Dockerfile 的关键词
Kubernetes 集群里有两种节点：控制节点和工作节点。控制节点负责决策——比如调度容器去哪台机器、监控集群状态；工作节点负责干活——实际运行容器。考题里有时会把“管理节点”“存储节点”也列进去，但那些不是 K8s 的标准节点类型。
Dockerfile 里，RUN 和 CMD 最容易混。RUN 是在构建镜像时执行的命令，比如安装软件包、创建目录；CMD 是容器启动时执行的默认命令。打个比方，RUN 是装修房子时铺地砖、刷墙，CMD 是你搬进去之后每天开灯的动作。装修只做一次，开灯每次住进去都会做。
4. 常见误区与易混概念：别把“差不多”当成“一样”
4.1 tar 解压参数：-zxvf 和 -xvz 到底差在哪
解压 wordpress.tar.gz 的命令，选项里有 tar -xvz、tar -xcf、tar -zxvf、tar -czf。正确答案是 tar -zxvf。这里的关键是参数顺序和含义：-z 表示用 gzip 解压，-x 表示提取，-v 表示显示过程，-f 表示指定文件名。虽然 -xvz 和 -zxvf 在有些系统上都能跑，但标准写法是 -zxvf，因为 -f 后面必须紧跟文件名，放在最后最安全。
-c 是创建压缩包，所以 -czf 是打包压缩，不是解压。搞混 -x 和 -c，就像把“开瓶器”和“封口机”搞反了——一个开一个封，方向完全相反。
4.2 rm -rf 的威力：递归强制删除到底删了什么
rm -rf dirname 这条命令，选项里有人选“删除 dirname 目录中的文件”，有人选“只能删除空目录”，正确答案是“递归强行删除 dirname 目录及其目录下的所有文件”。关键词是递归和强行——递归意味着如果目录里还有子目录，它会一层层往下删；强行意味着不提示、不确认。
这条命令在 Linux 里被戏称为“删库跑路专用”。用之前一定要确认路径写对了，尤其是变量拼接的时候，多一个空格可能就把根目录删了。血泪经验：在生产环境执行 rm -rf 之前，先把命令里的 rm 换成 echo 跑一遍，看看会删什么。
4.3 NFS 和 Samba：共享文件到底用哪个
NFS 和 Samba 都是文件共享协议，但适用场景不同。NFS 是 Linux 之间共享用的，Samba 是 Linux 和 Windows 之间共享用的。NFS 依赖 RPC 服务，所以配置的时候要确保 rpcbind 在跑；Samba 依赖 smbd 和 nmbd 两个服务，端口是 139 和 445。
考题里问“NFS 由哪几部分组成”，答案是 NFS 用户空间工具、NFS 内核模块、RPC 相关服务。没有 HDFS——那是 Hadoop 的东西，跟 NFS 不是一家人。
4.4 主从数据库：show slave status 里该看什么
配置 MySQL 或 MariaDB 主从同步后，在从节点执行 show slave status\G，最关键的两个字段是 Slave_IO_Running 和 Slave_SQL_Running。两个都是 Yes，才说明同步正常。如果 IO 线程是 No，通常是网络不通或主库授权有问题；如果 SQL 线程是 No，通常是 SQL 语句在从库执行报错了。
Seconds_Behind_Master 表示从库落后主库多少秒，0 表示完全同步。但这个值不是绝对可靠——如果主库长时间没写入，它可能显示 NULL。
4.5 项目收尾的顺序：为什么经验教训要在解散团队之前写
收尾过程的正确顺序是：得到正式验收、写出经验教训、解散团队、结束合同。为什么经验教训不能等团队散了再写？因为很多细节只有一线执行的人记得——比如某个技术难点怎么绕过去的、某个供应商沟通时踩了什么坑。人一走，这些信息就丢了。先写教训，再解散，最后走合同流程，这个顺序是有逻辑的。
5. 什么时候用、什么时候别用：从一道实操题看技术选型的边界
假设你面对这样一道实操题：在交换机上创建 VLAN 100 和 VLAN 101，配置网关，设置 trunk 和 access 端口。你拿到题之后，第一反应可能是直接敲命令。但更值得思考的是：什么时候该用 VLAN，什么时候不该用？
VLAN 的核心价值是隔离广播域。如果一个网络里设备很少，比如只有五六台机器，而且都在同一个网段，那划不划 VLAN 区别不大，反而增加配置复杂度。但如果是一个几十上百台设备的办公网络，不划 VLAN 的话，广播风暴能把网络拖垮。这时候 VLAN 就是刚需。
再比如，你在一台 Linux 服务器上要共享一个目录给同事的 Windows 电脑，用 Samba 还是 NFS？如果同事全是 Linux，NFS 更轻量；如果混用 Windows，Samba 更省事。技术选型没有绝对的好坏，只有适不适合。
注意：实操题里经常要求“使用完整命令，通过 Tab 键补全”。Tab 补全不只是省打字，它能帮你确认命令和路径是否存在。如果 Tab 补不出来，说明你拼错了或者组件没装。
我刚开始学 Linux 的时候，总觉得命令能跑就行，参数顺序无所谓。直到有一次在客户现场配 NFS，showmount -e 一直报错，排查了半天才发现是 rpcbind 没启动。从那以后，我每次配共享服务之前，都强制走一遍检查清单：服务在不在、端口通不通、防火墙放没放、权限对不对。这套习惯帮我省了无数个加班的夜晚。
希望帮到你。
本文还有配套的精品资源，点击获取
