Snowflake SnowPro Advanced: Architect Certification

**账户级数据共享 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 天前的查询历史 — 查不到，已经过期。