简介：这份PDF资料面向准备AWS Certified Cloud Practitioner（CLF-C02）认证的云计算初学者与从业者，帮助系统梳理考试涉及的核心服务与概念。内容以英文模拟题形式呈现，覆盖DynamoDB亚毫秒级键值存储、Snowball Edge数据传输、EC2实例安全评估、AWS Cloud Adoption Framework六大视角、Organizations与Service Catalog等治理服务，以及Direct Connect、PrivateLink私有连接和S3 Storage Lens存储分析等高频考点，并配有选项与参考答案，便于自测与查漏补缺。资源包共1个PDF文件，大小约2.07MB，轻量便携，适合在电脑或移动设备上随时翻阅刷题。目前已有121人学习下载，可作为备考冲刺阶段的练习材料，帮助读者熟悉题型、巩固服务应用场景与计费模式等关键知识点。
1. 从一份 CLF-C02 备考 PDF 说起：谁该啃、怎么啃、啃完能干嘛
如果你手上正躺着一份 CLF-C02 AWS Certified Cloud Practitioner 的 PDF，大概率你已经在纠结同一件事：这东西到底值不值得花时间。我见过太多人把 PDF 从头翻到尾，翻完还是说不清 S3 和 EBS 的区别，也说不清为什么账单月底突然多出一截。问题不在 PDF，在于大多数人把它当小说读，而不是当一张云从业者的地图来用。
CLF-C02 是 AWS 入门级认证的现行考纲代号，考的是云概念、安全合规、技术架构、计费与支持这几块地基。它不要求你写 Lambda，但要求你能在真实场景里判断「这个需求该用托管服务还是自建」「这笔钱花在哪一层」。所以这份 PDF 的正确用法，是当成一张对照表：左边是考纲条目，右边是你自己项目里对应的那件事。适合谁？转云的传统运维、要跟云团队对话的产品和测试、刚入行想拿一块敲门砖的应届生。不适合谁？已经天天在写 Terraform 和 CDK 的人，这份 PDF 对你太浅，直接去冲 SAA。
接下来我不复述 PDF 目录，而是按「考纲怎么拆 → 本地怎么把 PDF 变成可检索笔记 → 核心服务怎么对照真实操作 → 计费和安全怎么不翻车 → 怎么验证自己真的会了」这条线走一遍。中间会穿插 aws cli 的最小命令，让你在 mac 上就能把纸面知识落到终端里。litellm 接 aws bedrock 这类热词我也会在最后一章带一句，因为那是把 CLF-C02 知识用起来的一个真实出口。
2. 把 CLF-C02 考纲拆成四块可验证的能力：先搞清楚 PDF 里到底在考什么
2.1 四个域名的权重与它们对应的真实工作
CLF-C02 的考纲分成四个域，权重不是平均的。云概念约占 24%，安全与合规约 30%，云技术与服务约 34%，计费、架构与支持约 12%。安全和技术两块加起来超过六成，这意味着你不能靠背概念过关，得能判断「这个场景该开哪个开关」。
把权重翻译成工作语言：云概念考的是你懂不懂 IaaS/PaaS/SaaS 的边界、弹性与敏捷到底指什么；安全合规考的是共享责任模型、IAM、加密、合规认证；技术考的是计算、存储、数据库、网络、无服务器这些服务选型；计费考的是定价模型、成本工具、支持计划。PDF 里每一章基本对应一个域，但它是按知识点排的，不是按权重排的，所以读的时候要自己加权。
我一般会做一张对照表，左边写考纲条目，右边写「我项目里对应的那件事」。比如「共享责任模型」右边写「我们 RDS 的补丁是 AWS 打还是我们打」。这张表填不满的地方，就是你真正的薄弱点，比刷题准得多。
2.2 用 aws cli 把纸面概念变成可触摸的对象
光看 PDF 里讲 S3 存储类别，记不住。在 mac 上装好 aws cli 之后，开一个免费层账号，跑几条命令，概念立刻落地。下面是最小验证流程。
# 配置凭证，建议用 IAM 用户而不是根账号 aws configure # 依次输入 Access Key、Secret Key、默认区域（如 ap-southeast-1）、输出格式 json # 看当前身份，确认没配错账号 aws sts get-caller-identity # 列出现有 S3 桶，感受「对象存储是全局命名」这件事 aws s3 ls # 创建一个桶，注意桶名全局唯一 aws s3 mb s3://clf02-lab-<你的唯一后缀> --region ap-southeast-1 # 上传一个本地文件，观察存储类别默认是 STANDARD aws s3 cp ./notes.md s3://clf02-lab-<你的唯一后缀>/notes.md # 查看对象的存储类别和大小 aws s3api head-object --bucket clf02-lab-<你的唯一后缀> --key notes.md这几条命令的逻辑说明：sts get-caller-identity是排错第一步，任何权限问题先看它返回的 ARN 对不对。s3 mb建桶时区域参数决定数据落地位置，这直接关联 PDF 里「数据主权与合规」那一节。head-object返回的StorageClass字段，就是 PDF 里那张存储类别对比表的真实映射。参数上，桶名必须全小写、3 到 63 字符、全局唯一，踩过一次就知道为什么 PDF 反复强调命名规则。
提示：免费层账号也会产生少量费用，实验完记得
aws s3 rb s3://桶名 --force清空并删除桶，否则月底账单会给你上一课。
2.3 把 PDF 变成可检索笔记的三个动作
PDF 最大的问题是不可检索、不可关联。我的做法是三步。第一步，用任意 PDF 阅读器把四个域的标题提取出来，做成四个 Markdown 文件，文件名带域名和权重，比如01-cloud-concepts-24.md。第二步，每读一节，在文件里只写三行：这节在讲什么、对应哪个 AWS 服务、我项目里有没有对应场景。第三步，把不确定的点标成TODO，集中去查官方文档而不是继续往下读。
这样做的好处是，你读完之后得到的不是一份划线 PDF，而是一份带权重的索引。复习时先看TODO列表，再看权重高的域，效率比从头翻高得多。很多人备考失败不是不努力，是把时间平均分给了四个权重不同的域。
3. 核心服务选型对照：计算、存储、数据库在 PDF 里怎么讲、在控制台怎么认
3.1 计算服务：EC2、Lambda、容器到底怎么选
PDF 里讲计算服务时，会把 EC2、Lambda、ECS、EKS、Fargate 列一遍。但考试和实战都只问一件事：这个负载该用哪种计算模型。判断逻辑是三条线——运行时长、触发方式、运维负担。
EC2 适合长驻、可预测、需要完全控制操作系统的负载。Lambda 适合事件驱动、短时、突发、不想管服务器的场景。容器介于两者之间，ECS 或 EKS 管编排，Fargate 管底层节点。PDF 不会告诉你的是，选型错误最常见的后果是账单，而不是性能。一个每天只跑几分钟的定时任务放在 EC2 上，你付的是 24 小时的钱。
# 看有哪些 EC2 实例类型可用（输出很长，建议配合 grep） aws ec2 describe-instance-types --query "InstanceTypes[].InstanceType" --output text | head -20 # 看 Lambda 函数的运行时和内存配置 aws lambda list-functions --query "Functions[].{Name:FunctionName,Runtime:Runtime,Mem:MemorySize}" # 列出 ECS 集群，感受编排层和计算层的分离 aws ecs list-clusters逻辑说明：describe-instance-types帮你建立「实例族 + 规格」的命名直觉，PDF 里的t3.micro、m5.large不是随便起的。list-functions返回的MemorySize直接决定计费粒度，Lambda 按内存和调用时长计费，这是 PDF 计费章节的实操映射。list-clusters让你看到 ECS 集群本身不产生计算费用，费用在任务和节点上，这个区分考试常考。
参数上，Lambda 内存从 128MB 到 10240MB 可调，调大内存通常也会提升 CPU 配额，所以「加内存反而更便宜」在短任务上是真实存在的，因为执行时间缩短了。这个反直觉结论 PDF 不一定写透，但控制台里调一次就懂。
3.2 存储服务：S3、EBS、EFS、Glacier 的边界
存储是 CLF-C02 的高频区，也是最容易混的地方。一句话区分：S3 是对象存储，走 HTTP，无限容量，适合静态资源和备份；EBS 是块存储，挂在单台 EC2 上，像一块硬盘；EFS 是文件存储，多台 EC2 共享；Glacier 是归档，取回要等，便宜但慢。
PDF 会给你一张对比表，但真正要记的是「访问模式决定存储类别」。频繁访问用 STANDARD，不常访问用 STANDARD_IA，归档用 GLACIER 或 DEEP_ARCHIVE。生命周期策略就是自动在这几档之间搬数据。
# 给桶配置生命周期：30 天后转 IA，90 天后转 Glacier aws s3api put-bucket-lifecycle-configuration \ --bucket clf02-lab-<你的唯一后缀> \ --lifecycle-configuration '{ "Rules": [{ "ID": "archive-rule", "Status": "Enabled", "Filter": {"Prefix": ""}, "Transitions": [ {"Days": 30, "StorageClass": "STANDARD_IA"}, {"Days": 90, "StorageClass": "GLACIER"} ] }] }' # 确认策略已生效 aws s3api get-bucket-lifecycle-configuration --bucket clf02-lab-<你的唯一后缀>逻辑说明：Transitions数组按天数从小到大执行，天数必须递增，否则 API 直接报错。Filter里的Prefix决定规则作用范围，空字符串表示全桶。这条策略是 PDF 里「成本优化」章节最直接的落地，考试会问「如何降低不常访问数据的成本」，答案就是生命周期转存储类别。
参数上，STANDARD_IA 有最低存储时长 30 天的要求，提前删除会按 30 天计费，这是血泪经验。Glacier 的取回时间从分钟到小时不等，选 DEEP_ARCHIVE 前先确认业务能接受几小时的恢复窗口。
3.3 数据库与网络：RDS、DynamoDB、VPC 的最小认知
数据库这块，PDF 的核心是「托管 vs 自建」和「关系 vs 非关系」。RDS 是托管关系型，Aurora 是 AWS 自研的兼容版，DynamoDB 是托管 NoSQL，Redshift 是数据仓库。选型先问数据模型，再问访问模式，最后问运维能力。
网络这块，VPC 是必考。你要能说清子网、路由表、安全组、NACL 的关系。安全组是有状态的、作用在实例级；NACL 是无状态的、作用在子网级。这个区别考试反复考，实战里配错就是连不上。
# 看默认 VPC 和子网 aws ec2 describe-vpcs --query "Vpcs[].{ID:VpcId,CIDR:CidrBlock,Default:IsDefault}" aws ec2 describe-subnets --query "Subnets[].{ID:SubnetId,AZ:AvailabilityZone,CIDR:CidrBlock}" # 看安全组规则，注意入站和出站是分开的 aws ec2 describe-security-groups --query "SecurityGroups[].{Name:GroupName,In:IpPermissions,Eg:IpPermissionsEgress}"逻辑说明：describe-vpcs返回的IsDefault告诉你这是不是默认 VPC，默认 VPC 每个区域一个，方便但生产环境一般自建。describe-subnets的AvailabilityZone字段是理解「多可用区高可用」的入口，PDF 讲 RDS 多可用区部署时说的就是跨 AZ。describe-security-groups把入站和出站分开返回，正好对应安全组「默认拒绝入站、允许出站」的行为。
参数上，安全组规则引用另一个安全组 ID 而不是 IP 段，是 AWS 里做服务间访问控制的推荐做法，比写 IP 更稳。这个技巧 PDF 不一定强调，但控制台里配一次就记住。
4. 计费与安全合规：CLF-C02 里最容易翻车的两块怎么排
4.1 计费模型：按需、预留、Spot、节省计划
计费是 CLF-C02 里最像「财务题」的部分，但它的本质是「你愿意承担多少不确定性来换折扣」。按需最灵活最贵，预留和节省计划承诺一年或三年换折扣，Spot 用可中断换最大折扣。PDF 会列这几种，但不会告诉你什么时候用哪种。
判断逻辑：稳定长跑的核心业务用预留或节省计划，无状态可中断的批处理用 Spot，不确定的用按需。考试常考「哪个最省钱」，答案取决于负载是否可中断、是否长期稳定。
# 看当前月的成本和使用情况（需要开启 Cost Explorer） aws ce get-cost-and-usage \ --time-period Start=2024-01-01,End=2024-02-01 \ --granularity MONTHLY \ --metrics "BlendedCost" \ --group-by Type=DIMENSION,Key=SERVICE逻辑说明：get-cost-and-usage按服务维度聚合成本，返回结果里能看到每个服务花了多少。这是 PDF 里「成本管理工具」章节的实操入口，Cost Explorer 控制台就是这条 API 的可视化。参数上，Granularity可选 DAILY、MONTHLY、HOURLY，GroupBy可以按 SERVICE、LINKED_ACCOUNT、TAG 等维度切，按标签切的前提是你给资源打了标签。
注意：Cost Explorer 本身有少量费用，且数据有延迟，不要用它做实时告警，实时告警用 CloudWatch 账单警报。
4.2 共享责任模型：哪些是 AWS 的锅、哪些是你的锅
共享责任模型是安全域的核心。一句话：AWS 负责「云的安全」，你负责「云中的安全」。物理设施、硬件、网络、虚拟化层是 AWS 的；客户数据、IAM 配置、操作系统补丁、安全组规则是你的。这个边界随服务类型变化，IaaS 你管得多，SaaS 你管得少。
考试会给你一个场景问「谁负责」，实战里搞错边界就是安全事故。比如 RDS 的数据库引擎补丁，AWS 管；但库里的数据和账号权限，你管。S3 的桶策略配错了导致数据公开，那是你的责任，不是 AWS 的。
# 检查 IAM 用户是否有 MFA 开启 aws iam list-users --query "Users[].UserName" --output text | while read u; do echo -n "$u: " aws iam list-mfa-devices --user-name "$u" --query "MFADevices[].SerialNumber" --output text done # 看根账号有没有开启 MFA（根账号 MFA 是安全基线） aws iam get-account-summary --query "SummaryMap.AccountMFAEnabled"逻辑说明：第一段循环遍历所有 IAM 用户，逐个查 MFA 设备，输出为空说明没开。第二段直接查账号级 MFA 状态，AccountMFAEnabled为 1 表示根账号开了 MFA。这两条对应 PDF 里「IAM 最佳实践」和「根账号保护」，是安全域最该动手验证的点。
参数上，list-mfa-devices返回的是设备序列号，虚拟 MFA 的序列号是一串 ARN。生产账号里，根账号只用来做少数账号级操作，日常全部用 IAM 用户或角色，这是 PDF 反复强调但很多人不做的。
4.3 合规与支持计划：PDF 里那几张表怎么记
合规这块，PDF 会列一堆认证和框架，比如 SOC、ISO、PCI DSS、HIPAA。记法是按行业和地域分：金融看 PCI DSS，医疗看 HIPAA，通用看 SOC 和 ISO。AWS Artifact 是下载合规报告的地方，考试会问「哪里获取合规文档」，答案就是 Artifact。
支持计划分 Basic、Developer、Business、Enterprise 几档，区别在响应时间、技术支持范围、TAM（技术客户经理）。Basic 只有账单和账户支持，Business 起才有 24x7 技术支持和生产系统指导。考试常问「需要 15 分钟响应选哪个」，答案是 Business 或 Enterprise。
这块没有太多可跑的命令，但可以在控制台里打开 AWS Artifact 和 Support 页面各看一遍，把 PDF 里的表格和真实界面挂上钩。记不住的时候，问自己「这个场景是钱的问题、权限的问题，还是合规的问题」，三选一基本能定位到对应章节。
5. 避坑与排查：备考和实操里最常见的五个翻车点
5.1 把 PDF 当唯一资料，刷题正确率虚高
现象：PDF 翻了三遍，模拟题正确率 85%，一上真实控制台连桶都建不对。原因：PDF 是知识清单，不是操作手册，刷题考的是记忆，控制台考的是判断。解决：每读一个服务，就去控制台或 cli 里做一次最小操作，把「知道」变成「做过」。我一般要求自己每个核心服务至少跑通一条命令，跑不通就说明没懂。
5.2 区域选错导致延迟和合规问题
现象：服务能跑，但访问慢，或者客户要求数据不出境却选了境外区域。原因：建资源时随手选了默认区域，没考虑用户位置和数据主权。解决：建任何资源前先确认区域，把区域写进命名规范或标签。aws configure里的默认区域只是省事，不代表可以随便选。PDF 里「全球基础设施」那一节讲的就是这个，但只有踩过才记得住。
5.3 IAM 权限给太大，排查时找不到边界
现象：程序跑不通，报 AccessDenied，但不知道缺哪个权限，于是直接挂 AdministratorAccess，问题「解决」了，隐患留下了。原因：IAM 策略是显式拒绝优先、默认拒绝，排查需要看具体 API 和资源 ARN。解决：用 CloudTrail 看失败调用的具体事件，定位到 API 和资源，再最小化授权。aws cloudtrail lookup-events可以查最近的 API 调用，比猜快得多。
5.4 忽略免费层限制，实验做出真账单
现象：以为免费层全免费，跑了一堆实验，月底收到账单。原因：免费层有额度、时长、实例类型限制，超出部分正常计费。解决：实验前查清免费层覆盖范围，实验后清理资源。NAT 网关、弹性 IP、未挂载的 EBS 卷都是常见的「静默计费项」，PDF 计费章节会提，但不会替你清理。
5.5 把共享责任模型理解成「AWS 全包」
现象：以为用了托管服务就不用管安全，结果数据配置出错。原因：托管服务托管的是基础设施，不是你的配置和数据。解决：记住「云的安全」和「云中的安全」这条线，托管服务里你仍然负责访问控制、数据加密、配置审计。S3 桶公开、RDS 快照公开这类事故，责任都在客户侧。
6. 从 CLF-C02 到真实调用：用 litellm 接 AWS Bedrock 验证你学没学会
学完 CLF-C02，怎么验证自己真的会了？我的做法是找一个真实出口，把纸面知识用起来。最近比较顺手的一个出口是用 litellm 接 AWS Bedrock，因为这一条链路同时用到了 IAM 权限、区域选择、计费模型、API 调用四块知识，正好覆盖 CLF-C02 的核心域。
Bedrock 是 AWS 的托管大模型服务，调用它需要 IAM 权限、正确的区域、以及模型访问权限。litellm 是一个统一调用多家模型的库，把 Bedrock 当成一个 provider 接进来。下面是最小验证代码。
# 先安装：pip install litellm boto3 import os from litellm import completion # Bedrock 走的是 AWS 凭证链，这里显式设置，生产建议用 IAM 角色 os.environ["AWS_ACCESS_KEY_ID"] = "你的AccessKey" os.environ["AWS_SECRET_ACCESS_KEY"] = "你的SecretKey" os.environ["AWS_REGION_NAME"] = "us-east-1" # Bedrock 不是所有区域都有 response = completion( model="bedrock/anthropic.claude-3-sonnet-20240229-v1:0", messages=[{"role": "user", "content": "用一句话解释共享责任模型"}], max_tokens=200, temperature=0.3, ) print(response.choices[0].message.content)逻辑说明：model参数里的bedrock/前缀告诉 litellm 走 Bedrock provider，后面的模型 ID 必须和 Bedrock 控制台里开通的模型一致。AWS_REGION_NAME决定请求发到哪个区域，Bedrock 的模型可用性按区域不同，选错区域会报模型不存在。temperature控制随机性，验证连通性时设低一点，输出更稳定。
参数上，max_tokens直接影响计费，Bedrock 按输入和输出 token 计费，这是 CLF-C02 计费章节的真实映射。IAM 侧，调用 Bedrock 需要bedrock:InvokeModel权限，资源 ARN 指向具体模型。如果报 AccessDenied，先用aws sts get-caller-identity确认身份，再用 CloudTrail 看失败事件，这套排查流程和前面 IAM 那节完全一致。
跑通这条链路，你会发现 CLF-C02 里那些看似孤立的知识点——IAM、区域、计费、托管服务——在真实调用里是连在一起的。这也是我建议的验证方式：不要用刷题分数判断自己会不会，用一个能跑通的最小调用判断。跑不通，回去补对应章节；跑通了，说明你至少把纸面知识接上了地气。
我自己的习惯是，每学完一个认证，就找一个真实小项目把它用一遍，哪怕只是调一次 API。CLF-C02 这份 PDF 的价值不在于那张证书，而在于它逼你把云的地基术语和边界理清楚。理清楚之后，后面学 SAA、学 Bedrock、学任何托管服务，都会快很多。希望帮到你。
本文还有配套的精品资源，点击获取
