💡**题型和时间** — 65 题 / 115 分钟 ≈ 每题 106 秒。Architect 场景题比 DE 更长，经常一道题 3-4 行业务背景 + 4 个长选项，读题时间是主要开销。建议第一遍 75 分钟快速过完 + 大方 Mark 不确定的，剩 40 分钟专攻 Mark 题。纠结 3 分钟还没答案的题直接蒙一个继续走，不然后半段时间不够。
💡**场景题关键词条件反射** — "跨云共享数据给 50+ 付费客户" → Private Listing；"临时给一个没 Snowflake 账户的合作方 30 天访问" → Reader Account；"同一份数据给内部多个 BU 只读" → Secure Data Sharing；"region 整个挂了客户端无感切换" → Replication + Failover Group + Client Redirect 三件套；"强制客户端走私有网络不走公网" → PrivateLink + Network Policy 禁公网；"HIPAA / PCI 合规 + 客户要管密钥" → Business Critical + Tri-Secret Secure；"Snowpark UDF 调第三方 REST API" → External Access Integration（不是 External Functions）。
💡**死记数字和版本依赖** — Time Travel Enterprise 最多 90 天、Standard 只有 1 天；Fail-safe 固定 7 天不可改；PrivateLink 需要 Business Critical；Tri-Secret Secure 需要 Business Critical；Database Failover 需要 Business Critical；Account Usage 延迟 45 分钟到 3 小时、保留 1 年；Information Schema 保留 7-14 天无延迟；Materialized View 需要 Enterprise；Search Optimization Service 需要 Enterprise。几乎每道题都隐含一个 edition 约束。
💡**读官方 whitepaper 比刷题更有用** — Architect 考题有大约 20% 的原话来自这两份必读 PDF：《Snowflake Security Overview》和《Cross-Cloud Snapshot: Replication, Failover, and Client Redirect》。考前一周把这两份 PDF 每份读 2 遍，很多考题直接能认出原文。Snowflake University 的免费视频课相对更基础，真正拉开差距的是这两份 whitepaper。
💡**熟悉 SYSTEM$ 函数速查** — SYSTEM$ALLOWLIST() 查 PrivateLink 需放行的 endpoint、SYSTEM$GET_PRIVATELINK_CONFIG() 查 private URL、SYSTEM$AUTHORIZE_PRIVATELINK() 授权、SYSTEM$CLUSTERING_INFORMATION / SYSTEM$CLUSTERING_DEPTH 看聚类健康度、SYSTEM$REFERENCE 用于 Secure Share 动态引用。考试会直接问"用哪个函数查 X"。
💡**新特性 2024-2026 考纲更新必刷** — Iceberg Tables（Snowflake 直接读写开放 Iceberg 格式）、Hybrid Tables / Unistore（行存 + 事务，对标 OLTP 场景）、Snowflake Horizon（统一治理 / Discovery / Lineage / Compliance 层）、Cortex AI Functions（LLM / Embedding / Vector Search）这几个新特性 2024 年起陆续进考纲，题库可能还没覆盖。考前一周必刷一遍官方最新 release notes。
💡**Core 依赖 + 2 年续期规划** — Architect 有效期 2 年，且**绑定 Core 有效状态** — Core 过期 Architect 也跟着失效。续期有两条路：(1) 到期前考 Recertification 刷新；(2) 再考一张更高级别的 Advanced（比如同时拿 Data Engineer 或 Administrator）会自动重置所有证书有效期。推荐路线：Architect 到期前 3 个月直接考 Data Engineer，一次覆盖两张证 2 年续期，比单独考 Recertification 划算。
⚠️**账户级数据共享 vs 数据库级数据共享混为一谈** — Snowflake 的 Secure Data Sharing 单位是 **Share 对象**，一个 Share 可以包含多个 database / schema / table / view，但共享的粒度只能到"这个对象被加到 Share 里"的级别。很多人以为"账户之间共享"意味着 provider 的整个账户对 consumer 可见，错。consumer 只能看到 provider 显式 GRANT TO SHARE 的对象，其他一切都不可见。另外 consumer 创建的 database-from-share 是**只读的**，不能写、不能建索引、不能做 Time Travel 查询 provider 的历史数据 — 这是 Architect 考题最爱出的陷阱。
⚠️**Reader Account vs Private Listing 的选型搞错** — 两者都能给"没有自己 Snowflake 账户的外部合作伙伴"提供数据访问，但定位完全不同。**Reader Account** 是 provider 创建并完全拥有的一个子账户，provider 付所有成本（存储 + 计算），适合临时性、一次性的数据交付，管理开销高，不适合规模化。**Private Listing**（属于 Snowflake Collaboration / Marketplace 体系）是 provider 在 Data Exchange 或 Marketplace 上发布的私有数据产品，consumer 必须有自己的 Snowflake 账户来订阅，provider 不付 consumer 的计算费用，还能做版本管理、审批流程、使用量计费。考题典型场景："一家数据公司要把数据卖给 50 个企业客户"— 答案几乎肯定是 Private Listing（可规模化 + 有计费机制），不是 Reader Account（单个还行，50 个管理崩溃）。
⚠️**Replication / Failover Group / Client Redirect 三件套的职责混淆** — Replication 是**数据层**的复制（把 database / account 对象复制到另一个 region 或 account）；**Failover Group** 是把一组对象绑在一起作为一个故障转移单元，允许你执行 failover 命令把 primary 切到 secondary；**Client Redirect** 是**连接层**的能力，给你一个组织级别的 connection URL，客户端不需要改连接字符串，failover 发生时 Snowflake 自动把流量切到当前的 primary。考题陷阱：只配了 Replication 没配 Failover Group → 不能 failover，只能手动切；配了 Failover Group 没配 Client Redirect → 可以 failover 但所有客户端需要手动改连接串。正确的企业级 BCP 必须三件套齐备。
⚠️**External Functions 和 External Access Integration 搞混** — 这是 2024 年考纲加进来的新知识点，两者都能从 Snowflake 调外部服务，但机制完全不同。**External Functions**（老特性）通过 API Integration + AWS API Gateway / Azure Function App 的 proxy 暴露 HTTP 端点，Snowflake 的 SQL 函数调用时走 proxy 转发，延迟高、配置复杂。**External Access Integration**（2023 GA 的新特性）让 UDF / Stored Procedure / Snowpark 代码直接从 Snowflake 计算层发起出站 HTTPS 请求，配合 Network Rule + Secret 管理凭据，延迟低、可控。考题会给场景："UDF 需要调第三方 REST API 获取汇率" — 新场景首选 External Access Integration，**只有题目明确提到 AWS Lambda 或 Azure Function 作为中间层时才是 External Functions**。
⚠️**Cortex AI 函数权限和成本的新考点被忽略** — 2024-2025 Snowflake 把 Cortex LLM Functions（COMPLETE、SUMMARIZE、TRANSLATE、SENTIMENT、EMBED_TEXT_768 等）纳入考纲。这些函数按 token 数计费，**不是**用 warehouse credit 而是用 Cortex 专属的 credit 账单项，成本完全独立。访问控制是通过 **SNOWFLAKE.CORTEX_USER** 这个 database role 分配，默认所有用户没有权限。考题陷阱："为什么 analyst 能看到数据表但调 SNOWFLAKE.CORTEX.COMPLETE() 报错" — 不是表权限问题，是少了 CORTEX_USER role grant。另一个坑：Cortex 调用是否跨 region 取决于账户所在 region 是否支持该模型，某些 region 会自动 cross-region inference，这涉及数据出境合规需要显式开启 CROSS_REGION_INFERENCE。
⚠️**PrivateLink 配置步骤和限制** — 企业客户最常要求的安全配置，考题必考。正确顺序：(1) 在 AWS/Azure 侧创建 VPC Endpoint 并记下 endpoint resource ID；(2) 联系 Snowflake Support 或用 SYSTEM$AUTHORIZE_PRIVATELINK 授权；(3) 用 SYSTEM$GET_PRIVATELINK_CONFIG() 拿到 Snowflake 侧的 private URL；(4) 在客户端配置使用 account-name.privatelink.snowflakecomputing.com 而不是公网 URL；(5) 配合 Network Policy 禁用公网访问。**PrivateLink 只能用于 Business Critical Edition 及以上**，Standard 和 Enterprise 不支持 — 考题会给一个用 Enterprise 的场景问能不能开 PrivateLink，答案是不能，必须升级版本。
⚠️**Tri-Secret Secure 的密钥层级理解错** — Snowflake 默认的加密是三层 hierarchical key 模型：Root Key → Account Master Key → Table Master Key → File Key。**Tri-Secret Secure** 的含义是在 Account Master Key 这一层引入**客户管理的密钥**（CMK，存在 AWS KMS 或 Azure Key Vault），组合成 "Snowflake Key + Customer Key" 的双密钥结构 — 任何一方撤销密钥都能让数据无法解密，这才是"Tri"的真正含义（Snowflake key + Customer key + 数据本身）。常见错误：以为 Tri-Secret Secure = 用三个密钥加密。还有考生分不清 CMK 和 BYOK，Snowflake 里只有 Tri-Secret Secure 这一种模式，没有纯 BYOK（客户独自管理根密钥）。**只有 Business Critical 及以上支持 Tri-Secret Secure**。
⚠️**Dynamic Data Masking 和 Row Access Policy 的作用域混淆** — Masking Policy 作用在**列**上，同一列对不同 role 显示不同值（明文/脱敏/NULL）；Row Access Policy 作用在**行**上，同一张表对不同 role 返回不同的行子集。两者可以叠加使用。常见陷阱：给同一列既挂 Masking 又挂 Row Access Policy → 合法；给一列挂两个 Masking Policy → **不合法**，一列只能挂一个 Masking Policy。另一个坑：Masking Policy 在 view 和 underlying table 上都可以挂，但如果 view 里对列做了复杂表达式（CONCAT、CASE WHEN），underlying table 的 Masking Policy **不会透传到 view**，需要在 view 层重新挂。
⚠️**Account Usage vs Information Schema 的选型** — 两者都能查元数据，但 **Account Usage** 是 SNOWFLAKE database 下的历史视图（保留 1 年），有 **45 分钟到 3 小时延迟**，数据最全，跨 warehouse 可查。**Information Schema** 是每个 database 下的实时视图，零延迟但只保留最近 7-14 天。审计合规场景（查 6 个月前谁访问了敏感表）必须用 Account Usage 的 ACCESS_HISTORY；实时监控当前跑的 query 必须用 Information Schema 的 QUERY_HISTORY。考题典型错误：用 Information Schema.QUERY_HISTORY 去查 90 天前的查询历史 — 查不到，已经过期。
