SnowPro Core(COF-C03)教科書

模擬試験 セット2(100問・115分・合格ライン750/1000 目安75%)

模擬試験 セット2 — 全100問 残り 115:00

模擬試験 セット2(応用シナリオ編)

本試験と同じ100問・115分です。単一選択(ラジオボタン)と複数選択(チェックボックス、「2つ選べ」等)が混在します。ページを開いた時点からタイマーが動いています。すべて解答したら最下部の「採点する」を押してください(時間切れで自動採点されます)。

最終確認:2026年8月

ドメイン1:Snowflake AI Data Cloudの特徴とアーキテクチャ(問1〜31)

問1. (シナリオ)ある小売企業では、毎朝9時にBIダッシュボードの利用者が集中し、個々のクエリは単純なのに待ち行列(キュー)に溜まって結果表示が遅くなる。Enterprise Editionを利用中である。最も適切な対策はどれか。

解説:同時実行数の増加によるキュー滞留にはスケールアウト(マルチクラスタ、Enterprise以上)が適切。Aのスケールアップは個々の複雑・大規模クエリの高速化に有効だが、同時実行の問題は解決しない。Bは逆効果、Dは管理負荷が増えるだけで解決にならない。参照:1-5節

問2. (シナリオ)月次で実行する大規模な集計クエリだけが極端に遅く、クエリプロファイルを見るとローカルストレージへのスピル(退避)が大量に発生していた。日常の小さなクエリは問題ない。最もコスト効率の良い対策はどれか。

解説:スピルはメモリ不足のサインで、スケールアップが有効。ウェアハウスサイズはいつでも変更でき秒課金なので、必要な時間帯だけ大きくするのが最も経済的。Aは同時実行向けで単一クエリには効かない。Cは待機コストが無駄。Dは管理が複雑になるうえ効果が不確実。参照:1-5節

問3. (シナリオ)経営ダッシュボードが同じクエリを1日に何度も発行している。ウェアハウスがサスペンド状態でも結果が即座に返ることがあるのはなぜか。

解説:結果キャッシュはクラウドサービス層に24時間保持され、同一クエリかつ対象データが不変ならウェアハウスを起動せずに結果を返す。Bはサスペンドで消えるため誤り。Cのストレージ層はクエリを実行しない。Dはサスペンドの意味に反する。参照:1-1節

問4. (シナリオ)開発チームのウェアハウスのクレジット消費が想定の3倍になっている。調査すると、auto-suspendが8時間に設定され、X-Largeサイズで軽い検証クエリを流していた。有効な是正策はどれか。(2つ選べ)

解説:アイドル時間の課金を減らすauto-suspend短縮と、サイズ適正化(サイズ2倍=クレジット2倍)が直接効く。Bはむしろ計算量を増やす。DはストレージコストでありWHクレジットとは別。Eはクラスタが増えれば消費はさらに増えうる。参照:1-5節

問5. (シナリオ)夜間にサスペンドされるウェアハウスで、朝一番のクエリだけ毎日遅いという苦情がある。2回目以降は速い。主な原因はどれか。

解説:ウェアハウス(ローカルディスク)キャッシュはサスペンドで失われるため、再開直後の初回クエリはストレージ層からの読み込みが発生して遅くなる。Aの結果キャッシュは24時間有効で、同一クエリなら朝も効く。BやCのような動作仕様はない。参照:1-1節、1-5節

問6. (シナリオ)マルチクラスタウェアハウスで、応答速度よりコスト抑制を優先したい。多少キューに溜まっても追加クラスタの起動を抑えたい場合、どのスケーリングポリシーを選ぶべきか。

解説:Economyポリシーはコスト優先で、十分な負荷が見込まれるまで追加クラスタの起動を抑制する。AのStandardはキュー発生を避けるため速やかに起動する応答性優先。CのMaximizedは常に最大クラスタ数で稼働しコスト増。Dは無関係かつコスト増要因。参照:1-5節

問7. (シナリオ)監査要件により、テーブルの過去データを90日前まで遡って参照できる必要がある。Standard Editionを利用中のアカウントで取るべき対応はどれか。

解説:Time Travelの最大保持期間はStandardで1日、Enterprise以上で90日。Aは上限超過で設定不可。BのFail-safeは7日固定でユーザーが照会・延長できない。DはTime Travelで実現できるため「以外に方法はない」が誤り。参照:1-2節

問8. (シナリオ)金融機関が「自社管理の鍵を組み合わせた暗号化」と「パブリックインターネットを経由しない閉域接続」を必須要件に挙げた。Business Critical Editionで初めて利用可能になる機能はどれか。(2つ選べ)

解説:顧客管理キーを組み合わせるTri-Secret Secureと、閉域網でのプライベート接続はBusiness Critical。A・EのマスキングやポリシーとCのマルチクラスタはEnterpriseで利用できるため「Business Criticalで初めて」ではない。参照:1-2節、2-5節

問9. (シナリオ)請求明細に「クラウドサービス」のクレジットが計上される月とされない月がある。この課金の仕組みとして正しいものはどれか。

解説:クラウドサービス層の消費は、日次のウェアハウスクレジット消費の10%までは相殺され、超過分のみ課金される。このためメタデータ操作中心の日だけ計上されることがある。B・C・Dはいずれもこの調整の仕組みに反する。参照:1-2節

問10. (シナリオ)数十億行のイベントテーブルに対し日付で絞り込むクエリが遅い。クエリプロファイルではほぼ全マイクロパーティションがスキャンされていた。データはランダムな順序でロードされている。有効な対策はどれか。

解説:プルーニングはマイクロパーティションごとのメタデータ(最小値・最大値)に依存する。ランダムロードで日付が全パーティションに散らばると絞り込みが効かないため、クラスタリングで日付順に整理するのが有効。Aは同時実行対策、Cは無関係、Dの期間はユーザーが延長できない。参照:1-6節

問11. (シナリオ)ETLジョブがセッション内でのみ使う中間テーブルを毎回作成している。他のセッションから見える必要はなく、ストレージコストも最小化したい。最も適切なテーブルタイプはどれか。

解説:一時テーブルはセッション終了で自動的に消え、他セッションから見えず、Fail-safeも持たないため要件に合致する。CのトランジェントはFail-safeなしだがセッションをまたいで存在し続ける。Aは保持コストが最大。Bは外部データ参照用で書き込み用途に不適。参照:1-7節

問12. (シナリオ)Time Travel保持期間(1日)を過ぎたテーブルを誤ってドロップしたことに気づいた。Fail-safeについて正しい説明はどれか。

解説:Fail-safeは永続テーブルに対する7日間の災害復旧領域で、ユーザーが直接クエリ・復元することはできず、サポート経由の対応となる。AのUNDROPはTime Travel期間内のみ。Bの延長は不可。Cが正しく、DのトランジェントテーブルにFail-safeはない。参照:1-7節

問13. マイクロパーティションの特性として正しいものはどれか。(2つ選べ)

解説:マイクロパーティションは自動作成・イミュータブルで、列単位の統計メタデータによりスキャン対象を絞り込める。Bの手動指定は不可(自動管理)。Cは誤りで列指向(カラムナ)。Eも誤りで、永続保存はストレージ層であり、ローカルディスクはキャッシュにすぎない。参照:1-6節

問14. (シナリオ)あるチームが「スキーマAのテーブルを、別のデータベースのスキーマBに移動せずそのまま参照したい」と相談してきた。Snowflakeのオブジェクト階層として正しい説明はどれか。

解説:階層はアカウント>データベース>スキーマ>オブジェクトで、スキーマは単一データベースに属する。権限さえあれば完全修飾名でどのデータベースのテーブルも参照可能。A・Bは階層構造に反する。Dは不要(同一アカウント内なら参照でき、複製にもゼロコピークローンがある)。参照:1-4節

問15. (シナリオ)コスト削減のため、開発者が数秒おきにウェアハウスを手動でサスペンド・レジュームするスクリプトを組んだところ、かえってクレジット消費が増えた。原因はどれか。

解説:課金は秒単位だが、起動(レジューム)ごとに最低60秒分が発生する。数秒間隔の再起動を繰り返すと最低課金が積み上がり逆効果になる。A・C・Dのような課金仕様は存在しない。参照:1-5節

問16. (シナリオ)決算期の3日間だけ、常に最大の同時実行能力を確保したい(負荷に応じた増減で起動待ちが生じるのも避けたい)。マルチクラスタウェアハウスの構成として適切なものはどれか。

解説:最小=最大とするMaximizedモードは常に全クラスタが稼働し、スケール待ちなしで最大同時実行能力を提供する。BのEconomyは起動を抑制するため要件と逆。Cのサイズアップは同時実行の解決策ではない。Dは可用性を下げるだけ。参照:1-5節

問17. (シナリオ)通常は軽いクエリが中心のウェアハウスで、ときどき巨大なスキャンを伴うクエリが混ざり、そのたびに全体が遅くなる。ウェアハウスサイズは変えずに、大きなスキャン部分だけ追加のコンピュートへ委譲したい。適切な機能はどれか。

解説:QAS(Enterprise以上)はスキャン負荷の大きい部分をサーバーレスな計算資源へオフロードし、ウェアハウス本体のサイズ変更なしに突発的な重いクエリを処理できる。Aはポイントルックアップ向け、Bは定型集計の事前計算、Cは同一クエリ再実行時のみ有効。参照:1-5節

問18. (シナリオ)データエンジニアリングチームが、SQLではなく使い慣れたプログラミング言語のDataFrame APIでSnowflake内のデータを処理したい。Snowparkがサポートする言語はどれか。(2つ選べ)

解説:SnowparkはPython・Java・Scalaの3言語をサポートし、処理はSnowflakeのコンピュート上で実行されるためデータ移動が不要。A・C・DはSnowparkの対象外。参照:1-9節

問19. (シナリオ)カスタマーサポート部門が、蓄積した問い合わせテキストの感情分析や要約を、機械学習基盤を別途構築せずSQLから直接実行したい。適切なアプローチはどれか。

解説:CortexのLLM関数はマネージドなAI機能をSQL関数として提供し、データをSnowflakeの外へ出さずに感情分析・要約・翻訳などを実行できる。Aはデータ移動とガバナンス上のリスクを伴う。C・DはAI処理の機能ではない。参照:1-8節

問20. (シナリオ)数十億行のテーブルに対して「特定の会員IDを1件だけ探す」等値検索が多発し、プルーニングが効きにくく遅い。クラスタリングキーは別の列で既に使用中である。Enterprise Editionで追加すべき機能はどれか。

解説:検索最適化サービス(Enterprise以上)は等値検索などのポイントルックアップ向けに専用のアクセスパスを構築し、クラスタリングと併用できる。Aは同時実行対策、Bは同一クエリの再実行のみ、Dはむしろ性能が下がる。参照:1-6節

問21. (シナリオ)Standard Editionのアカウントで CREATE MATERIALIZED VIEW を実行したところエラーになった。原因として正しいものはどれか。

解説:マテリアライズドビューはEnterprise以上で利用可能な機能で、Standardでは作成できない。Bはエディション要件の取り違え。Cのような廃止はない。Dはこのエラーの原因ではない。参照:1-2節

問22. (シナリオ)夜間バッチでスクリプトからSQLを一括実行し、結果をファイルへ書き出す運用を自動化したい。GUIを介さない実行に最も適したインターフェースはどれか。

解説:SnowSQLはCLIクライアントで、スクリプトからのバッチ実行・ファイル入出力・自動化に適する。A・BのSnowsightは対話的なWeb UIでありスケジューラからの無人実行には不向き。Cはデータ取得の場であり実行インターフェースではない。参照:1-3節

問23. (シナリオ)インフラ担当者が「Snowflakeのテーブルデータが格納されているクラウドストレージのバケットを直接開いて中身を確認したい」と言っている。ストレージ層の説明として正しいものはどれか。

解説:ストレージ層のデータは圧縮済みの独自カラムナ形式で、ユーザーがバケットを直接読むことはできず、SQL経由でのみアクセスする。Aは形式の誤り。Cはストレージ料金(TB単位)とコンピュート(クレジット)の混同。Dの実行はウェアハウスの役割。参照:1-1節

問24. クラウドサービス層が担う処理として正しいものはどれか。(2つ選べ)

解説:クラウドサービス層は認証・アクセス制御、クエリ解析と最適化、メタデータ管理、トランザクション調整などの「頭脳」を担う。Bの実行はコンピュート層(仮想ウェアハウス)、Dの保存はストレージ層の役割。Eはクライアント側の話でSnowflakeの層ではない。参照:1-1節

問25. (シナリオ)10TBの本番データベースの完全なコピーを開発環境として即座に用意したい。追加ストレージコストを最小限にする方法はどれか。

解説:ゼロコピークローンはメタデータ操作で瞬時に完了し、クローン後に変更された部分だけが追加ストレージを消費する。A・Bは物理コピーで時間もストレージも2倍かかる。Dの共有は読み取り専用で、書き込みが必要な開発環境には不適。参照:1-7節

問26. (シナリオ)データレイク上のParquetファイル群を、Snowflakeへロードすることなくその場でSQL参照したい。適切なオブジェクトはどれか。

解説:外部テーブルは外部ステージ上のファイルをロードせず読み取り専用で参照できる。B・Cはロードが前提の内部テーブル。Dは元となるテーブルが必要で、単体で外部ファイルを参照する仕組みではない(外部テーブル上にMVを作る構成は別論点)。参照:1-7節

問27. (計算)X-Smallウェアハウスが1時間あたり1クレジットを消費するとき、Smallウェアハウスを30分間連続稼働させた場合の消費クレジットはいくつか。

解説:サイズが1段階上がるごとに消費は2倍。SmallはX-Smallの2倍で2クレジット/時、30分(0.5時間)なら2×0.5=1クレジット。AはX-Smallの場合、CはSmallを1時間動かした場合、DはMediumを1時間動かした場合の値。参照:1-5節

問28. (シナリオ)BI用ウェアハウスのauto-suspendを60秒に設定したところ、コストは下がったが「少し席を外して戻るとクエリが遅い」という声が増えた。この現象の説明と対応として最も適切なものはどれか。

解説:短すぎるauto-suspendは、サスペンドのたびにローカルキャッシュを失い、再開直後のクエリが遅くなる。対話的なBI用途では数分〜十数分に延ばすなどのバランス調整が定石。Aはキャッシュ喪失を無視しており誤り。Bは論点が違う。Cは利便性を壊すだけで逆効果。参照:1-5節

問29. (シナリオ)同じダッシュボードクエリなのに、結果キャッシュが効くときと効かないときがある。結果キャッシュが再利用されるための条件はどれか。(2つ選べ)

解説:結果キャッシュはクエリ文の同一性と基礎データの不変性が条件で、24時間有効。キャッシュはクラウドサービス層にあるため、Aのウェアハウスや Eの起動状態は不要で、Cについても必要権限を持つ別ユーザーの同一クエリで再利用されうる。CURRENT_TIMESTAMPのような非決定的関数を含むと効かない点も注意。参照:1-1節

問30. (シナリオ)夜間ETLと日中のBI分析が同じウェアハウスを共有しており、ETLの遅延時に朝のBIが巻き添えで遅くなる。アーキテクチャ上の定石はどれか。

解説:コンピュートとストレージが分離されたアーキテクチャでは、同一データに対して複数のウェアハウスを競合なく割り当てられる。ワークロード分離が定石で、互いの負荷の影響を受けない。Bは競合が残るうえ高コスト。Cは運用でしのぐだけ。Dはデータの一元性を壊す過剰な対応。参照:1-1節、1-5節

問31. Snowsightで実施できる操作として正しいものはどれか。(2つ選べ)

解説:SnowsightはWeb UIとしてワークシート・可視化・ダッシュボード・クエリ履歴・コスト管理などを提供する。Bのバケット直接操作は不可(問23参照)。Dの内部キー管理は自動でありUIから手動操作しない。EのようなOSレベルの監視は抽象化されており提供されない。参照:1-3節

ドメイン2:アカウント管理とデータガバナンス(問32〜51)

問32. (シナリオ)監査で「日常のテーブル作成やETL運用のほとんどがACCOUNTADMINロールで行われている」と指摘された。是正策として最も適切なものはどれか。

解説:最小権限の原則に従い、オブジェクトの作成・管理はSYSADMIN系のロール階層で行い、ACCOUNTADMINはアカウントレベルの限られた作業のみに使うのがベストプラクティス。Aは指摘内容の悪化。Cは全ユーザーに最上位権限を渡す重大事故。DはSECURITYADMINの役割(権限管理)と異なる。参照:2-2節

問33. (シナリオ)入退社対応のためユーザーとロールの作成・削除だけを担当するチームに権限を渡したい。過剰な権限を与えずに済むシステム定義ロールはどれか。

解説:USERADMINはユーザーとロールの作成・管理に特化したロールで、この業務に過不足がない。AとCは広すぎる。BのSYSADMINはウェアハウスやデータベースなどオブジェクト管理用で、ユーザー管理の役割ではない。参照:2-1節

問34. ACCOUNTADMINロールの運用に関するベストプラクティスはどれか。(2つ選べ)

解説:ACCOUNTADMINは最小限の人数に限定し、MFAで保護するのが原則。ただし1人だけにするとロックアウト時に復旧できないため複数名(ごく少数)が推奨される。A・Eは論外で、Cの自動化ジョブへの付与も、無人の資格情報に最上位権限を与えることになり避けるべき。参照:2-2節

問35. (シナリオ)分析チームのロールにスキーマ内の全テーブルへのSELECTを付与したが、その後ETLが新規作成するテーブルだけが毎回参照できず、都度手動でGRANTしている。恒久対策はどれか。

解説:「GRANT SELECT ON FUTURE TABLES IN SCHEMA ...」により、以後作成されるテーブルに自動で権限が付与され、手動対応が不要になる。既存の一括付与(ALL)は既存分にしか効かない点がこの症状の原因。Bは過剰権限、Cは運用頼みで漏れが再発する。Dは責務分離を壊す。参照:2-1節

問36. (シナリオ)各テーブルの所有者(作成したロール)が自由に他ロールへ権限を付与できてしまい、ガバナンス部門が把握できない付与が増えている。権限付与の権限をスキーマ所有者に集約する仕組みはどれか。

解説:MANAGED ACCESSスキーマでは、オブジェクト所有者が自身のオブジェクトに対する権限付与を行えなくなり、付与の権限がスキーマ所有者(およびMANAGE GRANTS保持者)に集約される。Aは将来オブジェクトへの自動付与、B・Dは本問の統制とは別の仕組み。参照:2-1節

問37. (シナリオ)電話番号列にマスキングポリシーを適用したのに、一部の分析担当者から「自分の画面では生の番号が見える」と報告があった。最も可能性の高い原因はどれか。

解説:動的マスキングはクエリ実行時にポリシー内の条件式(CURRENT_ROLEなど)を評価して返す値を決める。特定ロールに生データが見えるのは、条件でそのロールが許可されている(またはロール階層経由で許可ロールを継承している)ため。Aは誤りでビュー経由でも適用される。Cは誤りで即時評価。Dも誤りで文字列型は対象。参照:2-4節

問38. (シナリオ)Standard Editionの利用企業が個人情報保護の強化を計画している。Enterprise Edition以上へのアップグレードで利用可能になるガバナンス機能はどれか。(2つ選べ)

解説:動的マスキングと行アクセスポリシーはEnterprise以上の機能。Bの保存時暗号化とDのRBACは全エディション標準で、アップグレードで「新たに」得られるものではない。EはBusiness Criticalが必要なのでEnterpriseでは足りない。参照:1-2節、2-4節

問39. (シナリオ)ある列に「マスキングポリシー」、同じテーブルに「行アクセスポリシー」の両方を設定した。クエリ実行時の評価順序として正しいものはどれか。

解説:評価順序は行アクセスポリシー→マスキングポリシー。まず見える行が決まり、その行の列値がマスクされる。A・Bは順序の誤り。Cは誤りで併用可能(ただし同一列を行アクセスポリシーの判定列とマスキング対象の両方に使う構成には制約がある)。参照:2-4節

問40. (シナリオ)ネットワークポリシーで許可IPリストを更新した直後、管理者自身が接続できなくなった。オフィスの新IPを許可リストに入れ忘れたのが原因だった。今後の再発防止策として適切なものはどれか。(2つ選べ)

解説:ネットワークポリシーは適用者自身を締め出す事故が起きやすい。ユーザー単位での事前検証と、自分の接続元IPが許可されていることの確認が定石(Snowflakeは自分を締め出す設定の適用時に警告する仕組みも持つ)。Aはセキュリティ低下、Cは全IP許可でポリシーが無意味になる。Dは無関係で業務停止を招く。参照:2-3節

問41. (シナリオ)人事システムと連携したIdPを導入済みの企業が、入社・異動・退職に合わせてSnowflakeのユーザーとロール割り当てを自動で作成・更新・無効化したい。利用すべき仕組みはどれか。

解説:SCIMはIdP側のユーザー・グループ情報をSnowflakeへ自動同期し、アカウントのライフサイクル管理を自動化する標準プロトコル。Aは認証方式でありプロビジョニングはしない。Bは接続元IP制御。Dは無関係。なお、ログイン自体のシングルサインオンはSAML等のSSOが担い、SCIMと役割が異なる点も整理しておくこと。参照:2-3節

問42. (シナリオ)ETLツール用のサービスアカウントが、パスワード認証かつ接続元制限なしで運用されていると指摘された。セキュリティ強化策として適切なものはどれか。(2つ選べ)

解説:プログラム・サービス用途にはキーペア認証が推奨で、さらにネットワークポリシーで接続元を固定すれば資格情報が漏れても悪用しにくい。Bは最小権限の逆。C・Eは資格情報管理・監査の観点で悪化させる。参照:2-3節

問43. (シナリオ)リソースモニターのクォータ100%到達時のアクションをSUSPENDに設定していたが、到達後もしばらくクレジット消費が続いた。この動作の説明として正しいものはどれか。

解説:SUSPENDは新規クエリの受付を止めるが、実行中のステートメントは完了まで動くため、その間の消費は発生する。即時に中断したい場合はSUSPEND_IMMEDIATEを使う。Aのような遅延仕様はない。CはNOTIFYの説明。Dは誤りでモニターの対象はクレジット消費。参照:2-6節

問44. (シナリオ)SYSADMINロールの担当者が CREATE RESOURCE MONITOR を実行したところ権限エラーになった。正しい説明はどれか。

解説:リソースモニターの作成はACCOUNTADMINに限定される(作成後の参照・変更権限は他ロールへ付与可能)。Aは誤りで自アカウントで作成できる。Bは誤りで全エディションで利用可能。CのSECURITYADMINにも作成権限はない。参照:2-6節

問45. (シナリオ)ある月のクレジット消費が前月の2倍になった。調査の結果、検証用ウェアハウスの消し忘れと想定外の大量クエリが原因だった。再発防止として有効な施策はどれか。(2つ選べ)

解説:消費の上限管理はリソースモニター(NOTIFY/SUSPEND等)、消し忘れ対策はauto-suspendが直接的な打ち手。Bはキャッシュ再利用による無償の結果返却を捨てるため逆効果。Dはコスト増、Eはストレージコストを増やすだけで無関係。参照:2-6節、1-5節

問46. SNOWFLAKEデータベースのACCOUNT_USAGEスキーマの特性として正しいものはどれか。(2つ選べ)

解説:ACCOUNT_USAGEは365日分の履歴を保持し、ドロップ済みオブジェクトも含む一方、反映に45分〜3時間程度の遅延がある。Bはこの遅延に反する。Dは誤り。Eは各データベースに存在するINFORMATION_SCHEMAの説明で、ACCOUNT_USAGEは共有のSNOWFLAKEデータベース内にある。参照:2-7節

問47. (シナリオ)「たった今実行したロードジョブの結果を、遅延なしで即座に確認したい」という要件がある。参照すべき情報源はどれか。

解説:INFORMATION_SCHEMAは遅延のないリアルタイム情報を提供する(保持期間は短く、ドロップ済みオブジェクトは含まない)。AのACCOUNT_USAGEは45分〜3時間の遅延があり「即座に」の要件に合わない。Bは復旧用領域で照会不可。Dはリーダーアカウント用で本問の用途ではない。参照:2-7節

問48. (シナリオ)数百個のテーブルに散在する個人情報列へ、列を1つずつ指定せずに一括で同じマスキングを適用・維持したい。適切なアプローチはどれか。

解説:タグベースマスキングでは、タグにポリシーを関連付けておけば、そのタグが付いた(または付けられた)列へ自動的にマスキングが適用され、大規模環境でも一貫した保護を維持できる。Aは運用負荷と適用漏れのリスクが残る。Cはデータ活用を損なう。Dの行アクセスポリシーは行の可視性制御であり列値のマスクはできない。参照:2-4節

問49. (シナリオ)規制対応のため「自社が管理する鍵を暗号化に組み込み、必要なら自社側の判断でデータアクセスを遮断できること」が求められた。適切な機能とその前提はどれか。

解説:Tri-Secret SecureはSnowflake管理キーと顧客管理キーを組み合わせた複合マスターキーを構成し、顧客側キーの無効化によりアクセスを遮断できる。Business Criticalが必要。Aの標準暗号化は鍵がSnowflake管理のため要件を満たさない。Bは列値の表示制御、CはIP制御であり、暗号鍵の統制はできない。参照:2-5節

問50. Snowflakeの保存データ暗号化の標準動作として正しいものはどれか。

解説:保存時暗号化は全エディションでデフォルト有効であり、キーは階層型(ルート→アカウント→テーブル等)で管理され自動的にローテーションされる。Bはエディションの誤り(標準機能)。Cは誤りで自動。Dは誤りでテーブルデータを含む保存データ全体が対象。参照:2-5節

問51. (シナリオ)カスタムロールDATA_ENGを作成しユーザーに付与したところ、DATA_ENGが作成したデータベースをSYSADMINが管理できず、運用が属人化してしまった。ロール設計上の是正策はどれか。

解説:カスタムロールはSYSADMINへ(直接または階層経由で)集約するのがベストプラクティス。ロール階層により上位のSYSADMINがカスタムロールの権限を継承し、作成オブジェクトを一元管理できる。Aは全ユーザーへの権限拡散で危険。Bは最小権限に反する。Dは手作業依存で属人化の解決にならない。参照:2-2節

ドメイン3:データロード・アンロードと接続(問52〜69)

問52. (シナリオ)誤ってテーブルをTRUNCATEしてしまったため、3週間前にロードしたCSVファイル群(ステージに残っている)をCOPY INTOで再ロードしようとした。しかしCOPYは正常終了するもののロード件数が0件だった。原因と対策として最も適切なものはどれか。

解説:COPY INTOはターゲットテーブルごとにロードメタデータを64日間保持し、ロード済みと記録されたファイルを自動的にスキップする。TRUNCATEしてもこのメタデータは消えないため、同じファイルを再ロードするにはFORCE = TRUEで重複チェックを無効化する。Aはファイル破損ならエラーになるはずで、0件スキップとは症状が異なる。Cのキャッシュはロード結果に影響しない。Dのような制限は存在しない。参照:3-2節

問53. (シナリオ)クラウドストレージのバケットに毎日置かれる生データファイルを、認証情報をSQLに書かずにSnowflakeへロードするバッチ処理を新規構築する。作業の順序として最も適切なものはどれか。

解説:まずストレージ統合(storage integration)を作成してIAMロールベースの認証を確立し、それを参照する外部ステージを作成、その後COPY INTOでロードし、最後にロード先テーブルで変換を行うのが正しい順序である。Aはステージがストレージ統合を参照するため順序が逆。BはステージなしでCOPYできない。Dは変換対象のデータがまだ存在しない。参照:3-1節

問54. (シナリオ)100万行のファイルをCOPY INTOでロードしたところ、1行の形式エラーでロード全体が失敗した。エラー行だけをスキップして残りをロードしたい。指定すべきオプションはどれか。

解説:ON_ERRORの既定値はABORT_STATEMENTで、1行でもエラーがあるとステートメント全体が中断される。エラー行をスキップして残りをロードするにはON_ERROR = CONTINUEを指定する。AのVALIDATION_MODEは検証のみでロードを行わない。Bは重複チェックの無効化でエラー処理とは無関係。Cは既定値そのものであり症状は変わらない。参照:3-2節

問55. (シナリオ)本番テーブルへのロード前に、ステージ上のファイルにデータ形式のエラーがないかを、実際にはロードせずに確認したい。使用すべき機能はどれか。

解説:VALIDATION_MODEを指定するとデータは一切ロードされず、検証結果(エラー行など)だけが返される。事前チェックに最適である。Bは実際にロードが実行されてしまう。Cもロードが発生するうえ手作業で非効率。DはSnowpipeの状態確認用の関数でファイル検証はできない。参照:3-2節

問56. (シナリオ)50GBの単一の巨大CSVファイルをCOPY INTOでロードしたところ、大きなウェアハウスを使っているのに想定より時間がかかった。ロード時間を短縮する方法として最も適切なものはどれか。

解説:COPYの並列処理はファイル単位で行われるため、単一の巨大ファイルでは並列性を活かせない。圧縮後100〜250MB程度に分割するのが推奨プラクティスである。Aは単一ファイルでは並列度が上がらずコストだけ増える。Bはロード方式を変えてもファイルが単一なら並列化できない。Dはエラー処理の設定で速度に関係ない。参照:3-2節

問57. (シナリオ)AUTO_INGEST = TRUEのSnowpipeを作成したが、バケットに新しいファイルを置いてもまったくロードされない。原因の切り分けとして適切な確認・対処はどれか。(2つ選べ)

解説:AUTO_INGESTはクラウドストレージのイベント通知に依存するため、通知設定の不備が最も多い原因である(B)。またSYSTEM$PIPE_STATUSでパイプがRUNNINGか、保留中ファイルがあるかを確認するのが定石(D)。AはSnowpipeがサーバーレスでありユーザーのウェアハウスを使わないため無関係。Cはロードされない原因の調査にならない。Eは保持期間とSnowpipeの動作に関係がない。参照:3-3節

問58. (シナリオ)数KBの小さなファイルを毎分数千個Snowpipeでロードしていたところ、ロード量のわりにクレジット消費が想定を大きく超えた。コストを抑える対策として最も適切なものはどれか。

解説:Snowpipeにはロードするファイル1つあたりのオーバーヘッド課金があるため、極端に小さいファイルを大量に処理するとコスト効率が悪化する。ファイルを集約して数を減らすのが正しい対策である。AはSnowpipeがサーバーレスでウェアハウスを使わないため無意味。Cは自動検出を止めるだけでコスト構造は変わらない。Dはエラー処理でコストと無関係。参照:3-3節

問59. (シナリオ)30日前にSnowpipeでロードしたファイルの一覧を監査したい。最も適切な確認方法はどれか。

解説:SNOWFLAKE.ACCOUNT_USAGE.COPY_HISTORY ビューは365日分の履歴を保持し、COPYコマンドとSnowpipeの両方のロードを収録するため、30日前のSnowpipeロードも確認できる。AのINFORMATION_SCHEMA.COPY_HISTORYは保持期間が14日のため30日前は追えない。BのSnowpipeの重複防止用ロードメタデータも14日で期限切れになる(COPYコマンドのロードメタデータは64日)。Dは誤りで、履歴自体はACCOUNT_USAGE側に残っている。参照:3-3節

問60. (シナリオ)IoTアプリケーションから発生する行単位のデータを、ファイルを経由せず数秒以内のレイテンシでテーブルに書き込みたい。最も適切な方式はどれか。

解説:Snowpipe Streamingはファイルをステージングせず行単位で低レイテンシに書き込める方式で、この要件に合致する。Bはファイル経由になるうえ極小ファイル大量発生でコスト効率が悪い。Cはレイテンシ要件(数秒)を満たせない。Dはロードではなく参照であり、書き込み要件を満たさない。参照:3-3節

問61. (シナリオ)月次バッチでのみ消費していたストリームが「stale」となり、変更データを読み取れなくなった。根本原因として最も適切なものはどれか。

解説:ストリームのオフセットがソーステーブルのデータ保持期間(Time Travel)の範囲外まで古くなると、変更を辿れずstaleになる。保持期間内に定期的に消費するか、保持期間を延ばすことで防げる。AはSELECTだけではオフセットは進まないので直接の原因の説明として不正確。Bは変更がなければstaleの問題自体が顕在化しない。Dのような自動削除仕様はない。参照:3-4節

問62. (シナリオ)ストリームに対して INSERT INTO target SELECT * FROM my_stream を実行して差分を取り込んだ直後、確認のためストリームをSELECTしたところ0件だった。この状況の説明として最も適切なものはどれか。

解説:ストリームはDMLステートメント(INSERT ... SELECTなど)で消費された時点でオフセットが前進し、消費済みの変更レコードは返さなくなる。これは正常動作である。Aの破損ではない。Cは自動コミットされた後の話であり説明にならない。Dは誤りで、単なるSELECTではオフセットは前進しない(DML消費で前進する)。参照:3-4節

問63. (シナリオ)スケジュール付きのタスクを含むタスクツリーを新規作成したが、時刻になってもまったく実行されない。原因として考えられるものはどれか。(2つ選べ)

解説:タスクは作成時点ではSUSPENDEDであり、RESUMEし忘れは最も典型的な原因(A)。またスケジュールを設定できるのはルートタスクのみで、子タスクは先行タスクの完了で起動する(C)。Bはロールでなく権限(EXECUTE TASKなど)の問題でありログインロールの常時要件はない。Dは誤りでサーバーレスタスクが存在する。Eのような削除仕様はない。参照:3-4節

問64. (シナリオ)5分間隔のタスクがストリームを処理しているが、新着データがない時間帯にも起動してコンピュートを消費している。無駄な実行を避ける最も適切な方法はどれか。

解説:WHEN句にSYSTEM$STREAM_HAS_DATAを指定すると、ストリームに未消費データがない場合は本体処理がスキップされ、コンピュート課金を避けられる。Bは逆に起動回数が増える。Cは差分管理を壊すうえ無意味。Dは自動化の利点を失い運用負荷が上がる。参照:3-4節

問65. (シナリオ)複数のストリームとタスクを連鎖させた変換パイプラインの保守が煩雑になっている。「結果として欲しいテーブルの定義」と「許容できる鮮度」を宣言するだけで、更新のオーケストレーションをSnowflakeに任せたい。採用すべき機能はどれか。

解説:Dynamic TableはSELECT定義とTARGET_LAG(またはDOWNSTREAM)を宣言するだけで更新を自動管理する、Streams+Tasksパイプラインの宣言的な代替である。Aのマテリアライズドビューは単一テーブル参照などの制約があり、複数段の変換パイプラインの置き換えには適さない。Bはロードせず外部データを参照する機能。Cは共有時の定義秘匿が目的でオーケストレーションとは無関係。参照:3-5節

問66. (シナリオ)COPY INTO @ステージ でテーブルをアンロードしたところ、gzip圧縮されたCSVが複数ファイルに分割されて出力された。連携先システムの都合で1つのファイルにまとめたい。指定すべきオプションはどれか。

解説:アンロードは既定で並列実行され複数ファイル(gzip圧縮CSV)に分割される。単一ファイルにするにはSINGLE = TRUEを指定する(既定の上限を超える場合はMAX_FILE_SIZEを引き上げる)。Aはヘッダー行の出力設定。Cは既存ファイルの上書き設定。DはJSONロード時のオプションでアンロードの分割とは無関係。参照:3-6節

問67. (シナリオ)日次アンロードで、後続の分散処理システムが読みやすいように「ファイル1つあたりのサイズ上限」と「日付ごとのフォルダ分け」を制御したい。COPY INTO(アンロード)で使用するオプションはどれか。(2つ選べ)

解説:MAX_FILE_SIZEで出力ファイルのサイズ上限を、PARTITION BYで式(日付など)に基づく出力パスの振り分けを制御できる。AはSnowpipeの自動検出設定。Cはロード前検証用でアンロードには使えない。DはDynamic Tableの鮮度設定でありCOPYのオプションではない。参照:3-6節

問68. (シナリオ)レビュー中に、同僚が書いた CREATE STAGE 文にクラウドストレージのアクセスキーとシークレットが平文で埋め込まれているのを発見した。推奨すべき修正はどれか。

解説:ストレージ統合はクラウド側のIAMロール(信頼関係)で認証するため、SQLやステージ定義に資格情報を書く必要がなくなる。これが推奨プラクティスである。Aのエンコードは秘匿にならない。Bもセッション内に平文で残り根本解決にならない。Dは外部バケット連携という要件自体を満たせず、内部ステージにキーは不要なので文意も矛盾する。参照:3-1節

問69. (シナリオ)アナリストが自分だけの一時的な分析のためにローカルのCSVをロードしたい。スキーマにステージを作成する権限は持っていない。追加の設定なしで利用できるステージはどれか。

解説:ユーザーステージ(@~)は各ユーザーに自動的に割り当てられており、作成権限が不要で本人だけがアクセスできるため、個人の一時的なロードに最適である。Aはストレージ統合等の設定とCREATE権限が必要。Bはスキーマへの作成権限が必要。Cは対象テーブルに紐づき、テーブルへの所有権/権限が前提となるうえ複数テーブルへの流用ができない。参照:3-1節

ドメイン4:パフォーマンス最適化・クエリ・変換(問70〜90)

問70. (シナリオ)大規模な集計クエリが極端に遅い。Query Profileを確認すると「Bytes spilled to remote storage」が非常に大きい。最も効果的な対策はどれか。

解説:リモートストレージへのスピルは、メモリにもローカルディスクにも収まらない深刻なメモリ不足のサインで、ウェアハウスのサイズアップ(スケールアップ)が有効である。Aの結果キャッシュは同一クエリ再実行時の話で初回実行は速くならない。Cのマルチクラスタは同時実行数(キューイング)対策であり単一クエリのメモリ不足には効かない。Dは無関係。参照:4-1節

問71. (シナリオ)朝9時台にBIダッシュボードの表示が遅いという苦情が多い。個々のクエリのQuery Profileを見ると処理自体は速いが、Queued(キュー待ち)時間が長い。最も適切な対策はどれか。

解説:キュー待ちは同時実行数がウェアハウスの処理能力を超えているサインであり、スケールアウト(マルチクラスタ)が正しい対策である。Aのサイズアップは個々の重いクエリ向けで、同時実行の詰まりには非効率。Bはポイントルックアップの高速化でキューイングと無関係。Dはクエリを打ち切るだけで解決にならない。参照:4-3節

問72. (シナリオ)数TBのテーブルに日付で絞り込むクエリを実行したが遅い。Query Profileで「Partitions scanned」が「Partitions total」とほぼ同じ値になっていた。この状況の解釈と対策として最も適切なものはどれか。

解説:scanned ≒ total はほぼ全マイクロパーティションを読んでいる、つまりプルーニングが効いていないサインである。絞り込み列(日付)でクラスタリングすればパーティションごとの値範囲が整理されスキャンを減らせる。Bは解釈が逆。Cはキャッシュの話でスキャン量の問題とは別。Dのマイクロパーティションはユーザーが直接管理するものではない。参照:4-1節、4-4節

問73. (シナリオ)それぞれ100万行程度のテーブル同士をJOINしたクエリが終わらない。Query Profileを見ると、Joinオペレータの出力行数が数十億行に膨れ上がっていた。最初に確認すべきことはどれか。

解説:入力よりも出力が桁違いに多いJoinは、結合条件の漏れ(実質クロスジョイン)や結合キーの重複による行の爆発(exploding join)の典型的サインで、まずJOIN条件を見直すべきである。A・Bはクエリの行数爆発と無関係。Cはこの症状の原因になりえない。参照:4-1節

問74. (シナリオ)昨日実行したものとまったく同じテキストのクエリを再実行したのに、結果キャッシュが使われずウェアハウスが起動した。原因として考えられるものはどれか。(2つ選べ)

解説:結果キャッシュが再利用されるのは、クエリが実質同一で、非決定的関数を含まず、参照データが変わっておらず、USE_CACHED_RESULTが有効な場合である。AとCはその条件を破る典型例。Bは誤りで、必要な権限を持つ別ユーザーでも再利用される。Dも誤りで、結果キャッシュはクラウドサービス層にありウェアハウスに依存しない。Eも誤りでセッションをまたいで約24時間(再利用で延長)有効である。参照:4-2節

問75. (シナリオ)夜間はウェアハウスをすべてサスペンドしている。早朝、データ変更のない状態で、前日と同一の定型レポートクエリが実行された。このときの動作として正しいものはどれか。

解説:結果キャッシュはクラウドサービス層に保持されるため、条件(同一クエリ・データ未変更など)を満たせばウェアハウスを起動せずに結果を返し、コンピュートコストもかからない。Aはキャッシュヒット時には起こらない。Bは誤りでエラーにはならない。Dのローカルディスクキャッシュはウェアハウス上にあり、サスペンド中は存在せず、そもそも「結果」を返す仕組みではない。参照:4-2節

問76. (シナリオ)AUTO_SUSPENDを60秒に設定したところ、コストは下がったが、断続的に実行される類似クエリのたびにリモートストレージへのスキャンが発生して遅くなった。この現象の説明として最も適切なものはどれか。

解説:ウェアハウスのローカルディスクキャッシュ(データキャッシュ)はサスペンドで失われる。頻繁にサスペンド/再開を繰り返すとキャッシュが温まらず、毎回リモートストレージから読み直すことになる。コストと性能のトレードオフでAUTO_SUSPENDを調整する。Bの結果キャッシュはクラウドサービス層にありサスペンドで消えない。Cのような再構成は起こらない。Dなら再開自体がされずクエリが実行されない。参照:4-2節、4-3節

問77. (シナリオ)1つのウェアハウスをETLバッチとBIダッシュボードが共用しており、ピーク時に短いBIクエリが大量にキュー待ちになる。有効な対策はどれか。(2つ選べ)

解説:ウェアハウス分離はSnowflakeの基本設計パターンで、重いETLが軽いBIを妨げないようにする(B)。さらに同時実行の波にはマルチクラスタのAuto-scaleが適する(D)。Aのサイズアップは同時実行の詰まりに対して非効率でコスト増が大きい。Cはユーザーのクエリを打ち切るだけで解決にならない。Eは特定のルックアップの高速化でありキューイング対策ではない。参照:4-3節

問78. (シナリオ)普段は短いクエリばかりのウェアハウスで、月に数回だけアドホックに巨大なテーブルフルスキャンを伴う分析が実行され、そのときだけ極端に遅い。ウェアハウスのサイズは変えたくない。最も適切な機能はどれか。

解説:QASは断続的に発生する大規模スキャン部分をサーバーレスの計算リソースにオフロードし、ウェアハウス本体のサイズを変えずに対応できる(Enterprise以上)。Aは対象クエリが毎回異なるアドホック分析には適さない。Cはロード方式であり無関係。Dは共有用のアカウント種別で性能とは無関係。参照:4-3節

問79. (シナリオ)10TBのテーブルに対し、サポート担当者が顧客IDの完全一致でたまに1件を検索する。テーブルの物理的な並び順(クラスタリング)は他の分析ワークロードに合わせており変えたくない。ルックアップを高速化する最も適切な機能はどれか。

解説:検索最適化サービスは等価・IN・部分文字列などのポイントルックアップを、テーブルの並び順を変えずに高速化する(Enterprise以上)。Aは他ワークロード最適化を壊すため要件に反する。Bは毎回異なるIDを検索するため効かない。Cはフルスキャンが速くなるだけでコスト効率が悪い。参照:4-4節

問80. マテリアライズドビュー(MV)について正しい記述はどれか。(2つ選べ)

解説:MVは単一テーブルに対する定義のみ可能で(Aは誤り)、更新はSnowflakeが自動で行い、そのぶんサーバーレスのメンテナンスコストがかかる(B)。手動REFRESHは不要(Cは誤り)。またクエリがベーステーブルを参照していてもオプティマイザがMVへ自動的に書き換えて利用できる(D)。MVはEnterprise以上の機能である(Eは誤り)。参照:4-4節

問81. (シナリオ)数TBの取引テーブルに対し、ほとんどのクエリが取引日の範囲(BETWEEN)で絞り込む。長年の更新でデータの自然な並び順が崩れ、プルーニングが効かなくなってきた。最も適切な対策はどれか。

解説:範囲述語が中心の大規模テーブルにはクラスタリングキーが適する。値の範囲がマイクロパーティションごとに整理され、プルーニングが回復する。Bの検索最適化は等価・INなどのポイントルックアップ向きで、広い範囲スキャンには不向き。Cはストレージ特性の変更で性能と無関係。Dは結果キャッシュの保持期間を任意に延長する設定はなく、毎回条件が変わる範囲検索にも効かない。参照:4-4節

問82. (シナリオ)問い合わせ管理チームが、大規模なログテーブルからメールアドレスの部分文字列(LIKE '%example%')で該当行を数件探す検索を日常的に行う。これを高速化できる機能はどれか。

解説:検索最適化サービスは等価・INに加えて部分文字列検索(LIKE/ILIKEなど)のポイントルックアップも高速化できる。Aのクラスタリングは中間一致の述語ではプルーニングに寄与しにくい。Bは検索条件が毎回変わるため事前集計の効果がない。Dはスキャンを並列にオフロードする機能で、数件のルックアップを索引的に速くするものではない。参照:4-4節

問83. (シナリオ)JSONファイルをVARIANT列にロードしたところ、JSONの null リテラルを含む要素が SQL の NULL ではなく「null」という値のまま保持されていた。この挙動の説明として最も適切なものはどれか。

解説:VARIANTは、JSONに明示的に書かれたnullリテラルを「VARIANTのnull値」として保持し、値そのものが欠落していることを示すSQLのNULLと区別する。不要であればファイルフォーマットオプション STRIP_NULL_VALUES=TRUE でロード時にnull値の要素を除去できる。Aのような自動変換仕様はなく不具合でもない。Cの文字コードやDのウェアハウスサイズはこの挙動と無関係である。参照:4-5節

問84. (シナリオ)VARIANT列に格納された注文JSONに商品明細の配列(items)が含まれている。明細1件を1行として展開し、リレーショナルに分析したい。使用すべき機能はどれか。

解説:FLATTEN(通常LATERALと併用)は半構造化データの配列やオブジェクトを行に展開するテーブル関数で、この用途の標準的な方法である。AのPARSE_JSONは文字列をVARIANTに変換する関数で逆方向の話。Bの集約では明細ごとの行は得られない。CのPIVOTは行を列に回転させる機能で配列展開には使えない。参照:4-5節

問85. (シナリオ)ファイル全体が1つの巨大なJSON配列 [ {...}, {...}, ... ] になっているファイルをCOPY INTOでロードし、配列の要素1つずつを1行のVARIANTとして格納したい。指定すべきファイルフォーマットオプションはどれか。

解説:STRIP_OUTER_ARRAY = TRUEは外側の配列を取り除き、要素ごとに1行としてロードする。これを指定しないとファイル全体が1つのVARIANT値として扱われ、128MB(非圧縮)上限にも抵触しやすい。Bはアンロード時の単一ファイル出力用。CはCSVのヘッダー用。Dはロード済みファイルの再ロード用でいずれも無関係。参照:4-5節

問86. (シナリオ)ROW_NUMBER()で採番した結果のうち1位の行だけを取り出したい。サブクエリやCTEでラップせずに、ウィンドウ関数の結果で直接フィルタしたい。使用すべき句はどれか。

解説:QUALIFYはウィンドウ関数の結果に対するフィルタ専用の句で、サブクエリなしで QUALIFY ROW_NUMBER() OVER (...) = 1 のように書ける。Aは集約(GROUP BY)結果のフィルタ用。Bはウィンドウ関数の評価前に適用されるため直接は使えない。Dは行数を切るだけでパーティションごとの1位抽出はできない。参照:4-6節

問87. 大規模テーブルの探索的分析でSAMPLE句を使う際の、サンプリング方式に関する正しい記述はどれか。(2つ選べ)

解説:BERNOULLI(ROW)は行単位の抽選で統計的に均質だが処理量が多く(A)、SYSTEM(BLOCK)はブロック(マイクロパーティション)単位の抽選で高速な代わりに偏りうる(C)。BとDは両方式の説明が逆になっているため誤り。Eのような仕様はない(SEED指定のない場合の結果の再現性の論点はあるがキャッシュが常に無効になるわけではない)。参照:4-7節

問88. (シナリオ)アナリストが、参照権限を持たない機密テーブルを集計するストアドプロシージャを呼び出したところ、正常に結果が得られた。この動作の説明として最も適切なものはどれか。

解説:ストアドプロシージャは既定でowner's rights(所有者権限)で実行される。プロシージャ内の処理は所有者の権限で評価されるため、呼び出し元がテーブルに直接アクセスできなくても結果を得られる。制御されたデータ公開の手段になる一方、設計時は注意が必要である。AはEXECUTE AS CALLERを明示した場合の動作。C・Dは事実に反する。参照:4-7節

問89. (シナリオ)内部ステージに保存した請求書PDF(非構造化データ)へのアクセスをアプリケーション経由でユーザーに提供したい。ファイルURLの生成に使用できる関数はどれか。(2つ選べ)

解説:BUILD_SCOPED_FILE_URLは有効期限付きのスコープ付きURLを、GET_PRESIGNED_URLは事前署名付きURLを生成し、いずれもステージ上のファイルへのアクセス提供に使える。AはSnowpipeの状態確認、Cは半構造化データの展開、Eはストリームの未消費データ確認の関数であり、非構造化ファイルのURL生成とは無関係。参照:4-6節

問90. (シナリオ)連携ミスにより顧客テーブルに同一顧客IDの行が複数回取り込まれてしまった。「顧客IDごとに最新の更新日時の1行」だけを残して抽出したい。最も適切な方法はどれか。

解説:「グループごとに最新の1行」はウィンドウ関数の典型的ユースケースで、ROW_NUMBERで顧客IDごとに更新日時降順の順位を付け、QUALIFYで1位のみを残す。AのDISTINCTは全列が完全一致する行しか除去できず、更新日時が異なる重複には効かない。Bは非集約列を出力できずエラーになる。Cはテーブル全体からのランダム抽出であり要件と無関係。参照:4-6節

ドメイン5:データコラボレーション(問91〜100)

問91. (シナリオ)Standardエディション(保持期間は既定値)のアカウントで、10日前にDROPしたpermanentテーブルをUNDROPしようとしたが失敗した。理由として最も適切なものはどれか。

解説:UNDROPはTime Travelの保持期間内でのみ可能で、既定は1日である。期間終了後、permanentテーブルのデータはFail-safeに7日間だけ保持される(復元はSnowflakeへの依頼ベース)。既定設定ではDROPから1日+7日=8日でFail-safeも終了するため、10日後にはUNDROPはもちろん、いかなる手段でも復元できない。AはStandardでもUNDROP自体は使える。Bはテーブル・スキーマ・データベースに使える。Dは権限があれば別ユーザーでも実行できる。参照:5-1節

問92. (シナリオ)ステージング用のtransientテーブルに、誤削除対策としてDATA_RETENTION_TIME_IN_DAYS = 30 を設定しようとした。結果として正しいものはどれか。

解説:transient(および一時)テーブルのTime Travelは最大1日(0または1)で、30日は設定できない。Bの90日まで延長できるのはEnterprise以上のpermanentテーブルのみ。Cは誤りで、そもそもtransientにはFail-safeがない。Dも誤りで、0〜1日の範囲では利用できる。参照:5-1節

問93. (シナリオ)8日前に誤って上書きしたpermanentテーブルのデータ(保持期間1日)について、アナリストが「Fail-safeに残っているはずなので、AT句で直接クエリしたい」と相談してきた。正しい回答はどれか。

解説:Fail-safeはpermanentテーブルのみを対象とする7日間の災害復旧領域で、ユーザーによるクエリや自己復元はできない(Snowflakeへの依頼ベース)。AのAT句が使えるのはTime Travel期間内のみ。Cは逆で、transientにはFail-safeがない。Dは期間(7日)も手段(Time Travel不可)も誤り。参照:5-1節

問94. (シナリオ)本番データベースをCLONEして検証環境を作成した。ところが、本番側でSELECT権限を持っていた分析ロールから「クローンのデータベースにアクセスできない」と連絡があった。原因として最も適切なものはどれか。

解説:クローンで作られたオブジェクト自体は、元オブジェクトに付与されていた権限を引き継がない(内部の子オブジェクトは引き継ぐ)。そのため新しいデータベースへのUSAGE等を改めてGRANTする(またはCOPY GRANTSを使う)必要がある。Aは付与すればアクセス可能。Bはゼロコピークローンでありメタデータ操作のため即時に完了する。Cはクローンが通常の読み書き可能なオブジェクトなので誤り。参照:5-2節

問95. (シナリオ)スキーマ全体をCLONEしたところ、一部のオブジェクトがクローンに含まれていなかった。クローンされないオブジェクトはどれか。(2つ選べ)

解説:外部テーブルと内部の名前付きステージは、データベース/スキーマのクローンに既定では含まれない代表例である(外部テーブルは外部データを参照するためクローン対象外。内部の名前付きステージは INCLUDE INTERNAL STAGES を指定しない限り含まれない)。B・D・Eの各テーブルやビューは通常どおりクローンされる。参照:5-2節

問96. (シナリオ)取引先にデータを継続的に提供したいが、相手はSnowflakeを契約しておらず今後も契約予定がない。最も適切な提供方法はどれか。

解説:リーダーアカウントはプロバイダが作成・管理する読み取り専用のアカウントで、Snowflake未契約の相手にも共有データへのアクセスを提供できる。コンピュートコストはプロバイダが負担する。Bは共有機能で解決できるため不適切。Cは重大なセキュリティ違反。Dのレプリケーションは相手先のSnowflakeアカウントが前提で、オンプレミスには転送できない。参照:5-3節

問97. (シナリオ)他社からSecure Data Sharingで共有データベースの提供を受けることになった。コンシューマ側の特性として正しいものはどれか。(2つ選べ)

解説:共有はデータをコピーせずプロバイダのストレージを直接参照するためコンシューマにストレージコストは発生せず(Aは誤り)、データは読み取り専用(B)。再共有はできない(Cは誤り)。クエリはコンシューマ自身のウェアハウスで実行し、その分のコンピュートはコンシューマ負担である(E。Dは誤り。プロバイダが負担するのはリーダーアカウントの場合)。参照:5-3節

問98. (シナリオ)自社はクラウドAのリージョンX、共有先はクラウドBのリージョンYのアカウントで、直接共有を作成しようとしたところできなかった。この状況でデータを提供する方法はどれか。(2つ選べ)

解説:ダイレクトシェアは同一クラウド・同一リージョンのアカウント間でのみ作成できる。クロスリージョン/クロスクラウドでは、リスティングの自動フルフィルメント(A)か、相手側リージョンへのレプリケーション後に共有(C)が正しい方法である。Bは前提が誤り。Dのセキュアビューは定義の秘匿が目的でリージョン制約は解消しない。EのFail-safeは災害復旧用でデータ転送手段ではない。参照:5-3節、5-5節

問99. (シナリオ)複数の取引先に同じテーブルを共有するが、各社には自社に該当する行だけを見せたい。また、ビューの定義やベーステーブルの構造は隠したい。最も適切な方法はどれか。

解説:セキュアビューは定義を非公開にし、最適化による情報漏えい経路も防ぐため、共有時の行レベル制御(CURRENT_ACCOUNT()による絞り込み等)に推奨される。Aはコピー管理が煩雑でストレージも無駄になり、共有のゼロコピーの利点を失う。Bの通常ビューは共有では推奨されず、定義の秘匿もできない。Dはアクセス制御になっておらず全行が見えてしまう。参照:5-3節

問100. (シナリオ)リージョン障害に備え、別リージョンのアカウントへデータベースレプリケーションを構成し、障害時にはフェイルオーバーで業務を継続する計画を立てている。正しい記述はどれか。(2つ選べ)

解説:セカンダリデータベースは読み取り専用で(A)、更新は定期的なリフレッシュ(手動またはスケジュール)で反映されるため常時同期ではない(Bは誤り)。フェイルオーバー/フェイルバックはBusiness Critical以上の機能である(D。Cは誤り)。Eは誤りで、プライマリは通常どおり読み書きできる。参照:5-5節