運用・コストの要点整理と想定問題

正解: B 【A（不正解）】 ？ 従量の支払いから先行投資への移行を指す。 向きが逆。クラウドでは資源を使ったときに費用が発生し、OpEx が中心になる。 【B（正解）】 ？ 資本支出と運用支出のどちらが中心になるかを述べている。 正解。オンプレミスは機器への CapEx を償却していく。クラウドの多くの費用は、資源を使ったときに発生する OpEx になる。 【C（不正解）】 ？ 費用の種類そのものが消えるという考え。 誤り。クラウドでも利用料という運用支出は発生し、使用量に応じて変動する。 【D（不正解）】 ？ 費用モデルに違いはないという考え。 誤り。公式の費用最適化の指針は、オンプレミスとクラウドでは費用モデルが大きく異なると説明している。

出典: Well-Architected Framework: 費用の最適化の柱

正解: C 【A（不正解）】 ？ すでに発生した Google Cloud の費用をグラフで見る機能。 誤り。発生済みの費用を見る機能で、移行前の見積もりには使えない。 【B（不正解）】 ？ 利用額がしきい値に達したら通知する機能。 誤り。移行後の監視には役立つが、移行案ごとの費用を事前に比べる機能ではない。 【C（正解）】 ？ 移行案ごとの構成と費用をまとめるレポート。 正解。資産グループと設定の組み合わせごとに移行の選択肢と費用を比べられる。スライドや表計算の形で書き出せる。 【D（不正解）】 ？ 稼働中の資源の指標を可視化する機能。 誤り。性能の監視には役立つが、移行後の費用は見積もらない。

出典: Migration Center: TCO レポートを生成する

正解: A 【A（正解）】 ？ 必要な分だけ用意し、使った分だけ払う考え方。 正解。公式指針は、必要な資源だけを用意し、使った分だけ払うことを勧めている。自動スケーリングで需要の変化に合わせられる。 【B（不正解）】 ？ 償却期間を延ばして年額を下げる考え。 誤り。クラウドの費用は利用時に発生する OpEx が中心で、自社で機器を償却する前提ではない。 【C（不正解）】 ？ 大量購入による値引きを狙う考え。 誤り。ピークに合わせた先行購入は、平常時に資源が余るというオンプレミスの課題そのものである。 【D（不正解）】 ？ 運用の人手が完全に要らなくなるという考え。 誤り。クラウドでも運用や費用管理は必要で、公式指針も監視と継続的な最適化を求めている。

出典: Well-Architected Framework: 費用の最適化の柱／スケーラブルで復元力の高いアプリのパターン

正解: D 【A（不正解）】 ？ 費用管理を一つの部門に閉じる考え。 誤り。FinOps は技術・財務・ビジネスの各チームを結び付けることを重視する。 【B（不正解）】 ？ 削減額だけを成果とみなす考え。 誤り。公式解説は、単に費用を削るのではなく、支出の責任を分かち合い事業価値を高める取り組みだと述べている。 【C（不正解）】 ？ クラウドの利用そのものを減らす考え。 誤り。FinOps はクラウドの価値を最大化する運用の枠組みで、利用をやめるための基準ではない。 【D（正解）】 ？ 部門をまたいだ協力と文化に関する考え。 正解。公式解説は FinOps を、エンジニアリング・財務・ビジネスを結び付けてクラウド支出を管理する運用の枠組みと文化だとしている。

出典: What is Cloud FinOps?

正解: C 【A（不正解）】 ？ 請求先アカウントの所有者に当たるロール。 誤り。支払い方法やプロジェクトのリンク、他の人のロール管理までできてしまい、最小権限の原則に反する。 【B（不正解）】 ？ 費用と支払いの情報を読むだけのロール。 誤り。読み取り専用で、予算の作成や編集はできない。 【C（正解）】 ？ 予算と費用データの扱いに絞ったロール。 正解。予算の作成・編集・削除と、費用データの閲覧や書き出しができる。料金情報やプロジェクトのリンクは含まない。 【D（不正解）】 ？ プロジェクトを請求先アカウントに付け外しするロール。 誤り。プロジェクトの課金を有効・無効にするロールで、予算は作れない。

出典: Cloud Billing のアクセス制御と権限

正解: B 【A（不正解）】 ？ リクエストの遅延を追う機能。 誤り。性能の分析に使うもので、費用の節約額は表示しない。 【B（正解）】 ？ 請求の画面で節約の実績と機会をまとめる機能。 正解。前月に実現した節約額や、推奨事項を適用した場合の月あたりの見込み節約額をまとめて表示する。 【C（不正解）】 ？ アプリのエラーをまとめる機能。 誤り。エラーを集約して表示するもので、費用とは関係しない。 【D（不正解）】 ？ コードごとの CPU やメモリの使い方を調べる機能。 誤り。アプリの資源の使い方は分かるが、請求先アカウントの節約額は扱わない。

出典: FinOps ハブで費用を最適化する

正解: A 【A（正解）】 ？ 費用の持ち主をはっきりさせる考え。 正解。公式指針は、予算の一部を各チームに割り当てて当事者意識を持たせることを勧める。標準のラベルで費用を部署やコストセンターに結び付ける。 【B（不正解）】 ？ 費用情報の公開範囲を絞る考え。 誤り。公式解説は、組織のあらゆる階層が請求データをリアルタイムで見られることを文化の原則に挙げている。 【C（不正解）】 ？ 見直しの頻度を年1回にする考え。 誤り。公式指針は利用状況と費用を継続的に監視して調整することを求めており、年1回では遅すぎる。 【D（不正解）】 ？ 支払い元を担当者ごとに分ける考え。 誤り。組織として一元的に管理できなくなる。1つの請求先アカウントで複数のプロジェクトの費用を払える。

出典: 費用を意識する文化を育てる（Well-Architected Framework）／What is Cloud FinOps?／Cloud Billing の概要

正解: D 【A（不正解）】 ？ ログを別の保存先へ送る仕組み。 誤り。ログの転送に使うもので、使われていない資源を提案する機能ではない。 【B（不正解）】 ？ 資源の設定にかける制限。 誤り。作れる構成を制限するもので、使われていない資源を見つける機能ではない。 【C（不正解）】 ？ 使える資源の上限を変える手続き。 誤り。上限を上げると費用が増えやすくなる操作で、未使用の資源の発見とは関係ない。 【D（正解）】 ？ 利用状況を分析して改善案を示す仕組み。 正解。Recommender には、アイドル状態の VM・永続ディスク・IP アドレスを見つける費用の推奨事項がある。

出典: Recommender: 推奨事項の一覧／Recommender の概要

正解: A 【A（正解）】 ？ 請求先アカウント単位で排出量を推定するツール。 正解。対象サービスの利用に伴う推定排出量を、月別・リージョン別・プロジェクト別などで示す。BigQuery へ書き出すこともできる。 【B（不正解）】 ？ 費用をグラフで見る機能。 誤り。表示するのは費用で、温室効果ガスの排出量ではない。 【C（不正解）】 ？ 指標・ダッシュボード・アラートの機能。 誤り。システムの性能や状態を測るもので、排出量を報告する機能ではない。 【D（不正解）】 ？ セキュリティの状態を管理する機能。 誤り。脆弱性や脅威の把握に使うもので、排出量は扱わない。

出典: Carbon Footprint の概要／Carbon Footprint のデータをエクスポートする

正解: B 【A（不正解）】 ？ ツールで自動的に知らせる仕組み。 誤り。ツールの機能を使う取り組みで、「テクノロジー」に当たる。 【B（正解）】 ？ 役割や組織づくりに関する取り組み。 正解。公式解説は、財務とエンジニアリングが一体となって協力することを FinOps の文化の原則に挙げている。 【C（不正解）】 ？ データを分析基盤に送る仕組み。 誤り。データ連携の仕組みで、「テクノロジー」に当たる。 【D（不正解）】 ？ 繰り返し行う作業の段取り。 誤り。定期的な見直しの手順は「プロセス」に当たる。

出典: What is Cloud FinOps?

正解: C 【A（不正解）】 ？ 年1回の固定した予算の考え。 誤り。公式解説は、固定した年1回の周期ではなく、予算と予測を繰り返し見直すことを原則に挙げている。 【B（不正解）】 ？ 事前の計画を持たない考え。 誤り。予測と予算を持たないと、変動する費用を管理できない。 【C（正解）】 ？ 短い周期で計画を更新する考え。 正解。公式解説は、硬直した年次の周期ではなく、反復的な予算策定と予測を FinOps の文化の原則としている。 【D（不正解）】 ？ 過去の設備費を基準にする考え。 誤り。費用モデルが違うため、オンプレミスの CapEx をそのまま当てはめても実態に合わない。

出典: What is Cloud FinOps?／Well-Architected Framework: 費用の最適化の柱

正解: D 【A（不正解）】 ？ 作れる人を極端に絞る考え。 誤り。開発のアジリティを損なう。公式解説は、チームが自ら費用の最適化に責任を持つことを原則としている。 【B（不正解）】 ？ 費用の話を開発から切り離す考え。 誤り。公式指針は、あらゆる役割の人が自分の判断の費用への影響を意識すべきだとしている。 【C（不正解）】 ？ 失敗を罰で抑える考え。 誤り。公式解説は、失敗を学びとプロセス改善の機会と捉えることを文化の原則としている。 【D（正解）】 ？ 費用を意識する習慣を広げる考え。 正解。公式指針は、報告・アラート・ダッシュボードで費用データをチームに届けるよう勧める。設計や意思決定の場で費用を話し合うことも促している。

出典: 費用を意識する文化を育てる（Well-Architected Framework）／What is Cloud FinOps?

正解: C 【A（不正解）】 ？ プロジェクトの下にフォルダを置く並び。 誤り。フォルダは組織とプロジェクトの間に置き、プロジェクトをまとめる。 【B（不正解）】 ？ フォルダを組織より上に置く並び。 誤り。組織が階層の最上位（ルート）で、フォルダはその下に置く。 【C（正解）】 ？ フォルダでプロジェクトをまとめる並び。 正解。組織が最上位で、その下に任意のフォルダ、さらにプロジェクトがある。VM やバケットなどのリソースはプロジェクトに属する。 【D（不正解）】 ？ リソースをフォルダより上に置く並び。 誤り。VM などのリソースは階層の一番下で、プロジェクトの中に作る。

出典: リソース階層

正解: B 【A（不正解）】 ？ プロジェクト単位で一つずつ付与する方法。 誤り。できなくはないが付け忘れが起きやすく、新しいプロジェクトに自動では効かない。 【B（正解）】 ？ 上位の階層で一度だけ付与する方法。 正解。資源は親の許可ポリシーを継承する。フォルダで付与すれば、配下の既存と新規のプロジェクトに効く。 【C（不正解）】 ？ 資源に付けるキーと値の目印。 誤り。ラベルは整理や費用の追跡に使う目印で、アクセス権を与える仕組みではない。 【D（不正解）】 ？ 資源の構成に制限をかける仕組み。 誤り。組織のポリシーは「何を」構成できるかを制限する。「誰が」操作できるかはIAMで決める。

出典: リソース階層を使用したアクセス制御／リソース階層／組織のポリシー サービスの概要

正解: A 【A（正解）】 ？ 構成できる内容を階層の上から制限する方法。 正解。組織のポリシーは新しく作る資源の場所を制限できる。組織に設定すれば、配下のフォルダやプロジェクトに継承される。 【B（不正解）】 ？ 人ごとの権限と運用ルールで縛る方法。 誤り。IAM は「誰が」操作できるかを決めるもので、作る場所は制限できない。口頭のルールは守られない恐れがある。 【C（不正解）】 ？ 利用額に応じて通知する仕組み。 誤り。費用の通知であり、ほかの地域で資源が作られるのを防げない。 【D（不正解）】 ？ 費用を場所別に後から確かめる方法。 誤り。事後の確認にとどまり、作成そのものを防げない。

出典: 組織のポリシー サービスの概要／リソース階層

正解: C 【A（不正解）】 ？ 子の設定だけで権限が決まるという考え。 誤り。資源の実効的な許可ポリシーは、資源自身のポリシーと祖先から継承したポリシーの和集合になる。 【B（不正解）】 ？ 子の設定で親の権限が弱まるという考え。 誤り。子の許可ポリシーで、継承した付与を弱めることはできない。 【C（正解）】 ？ 親で与えた権限が子にも届くという考え。 正解。資源は親の許可ポリシーを継承し、実効的なポリシーは和集合になる。権限を外すならフォルダ側の付与を見直す。拒否ポリシーがあれば、その権限は使えなくなる。 【D（不正解）】 ？ 承認待ちの状態になるという考え。 誤り。そのような保留の仕組みはなく、継承された付与はそのまま有効になる。

出典: リソース階層を使用したアクセス制御／リソース階層

正解: B 【A（不正解）】 ？ 排出量の報告を見るツール。 誤り。Carbon Footprint は排出量を推定して報告するもので、資源を作れる場所は制限しない。 【B（正解）】 ？ 作れる場所を、あらかじめ決まった地域のまとまりで縛る方法。 正解。リソース ロケーション制限には「低炭素」の値グループがあり、低炭素の場所だけに限定できる。 【C（不正解）】 ？ 資源に付ける目印。 誤り。ラベルは整理や費用の追跡に使う目印で、作る場所は制限しない。 【D（不正解）】 ？ 利用額に応じた通知。 誤り。アラートのみの予算は通知するだけで利用を自動では止めず、場所の制限にもならない。

出典: Google Cloud リージョンのカーボンフリー エネルギー／組織のポリシー サービスの概要／組織のポリシーでのリソース ロケーションの制限（値グループ）

正解: C 【A（不正解）】 ？ 支払いを自動で止める動き。 誤り。アラートのみの予算は利用や課金を自動では止めない。止めるには、対応するサービスでの上限付きの予算や、通知を受けたプログラムなど別の仕組みが要る。 【B（不正解）】 ？ 請求を先送りする動き。 誤り。予算は費用を追跡して通知する機能で、請求の時期は変えない。 【C（正解）】 ？ 知らせるだけの動き。 正解。公式ドキュメントは、アラートのみの予算は利用や支出に自動で上限をかけないと説明している。 【D（不正解）】 ？ 一部の操作だけを止める動き。 誤り。予算アラートに作成を拒否する機能はない。使える量に上限を設けるのはクォータなどの仕組み。

出典: 予算と予算アラートの作成・編集・削除

正解: A 【A（正解）】 ？ 月末までの見込み額で判定する設定。 正解。しきい値は、実際の費用か、期間の終わりまでの予測費用のどちらかで判定できる。 【B（不正解）】 ？ すでに使った額で判定する設定。 誤り。実際の費用で判定すると、超えてから通知される。月の途中で超過の見込みは分からない。 【C（不正解）】 ？ 予算額の決め方の設定。 誤り。前の期間の実績を予算額にすることはできるが、月末の超過見込みを知らせる設定ではない。 【D（不正解）】 ？ 費用の計算に何を含めるかの設定。 誤り。費用の数え方が変わるだけで、超過の見込みを早く知る設定ではない。

出典: 予算と予算アラートの作成・編集・削除

正解: D 【A（不正解）】 ？ 予算の通知機能だけで止める方法。 誤り。アラートのみの予算は利用や課金を自動では止めない。 【B（不正解）】 ？ 使える資源の上限を変える手続き。 誤り。上限を上げると使える資源が増え、費用はむしろ増えやすくなる。 【C（不正解）】 ？ 人が画面を見て判断する方法。 誤り。人手に頼る方法で、自動化の要件を満たさない。費用データの反映にも遅れがある。 【D（正解）】 ？ 通知をきっかけに処理を動かす方法。 正解。予算は Pub/Sub のトピックに通知できる。それを受けてプロジェクトの課金を無効にするなどの自動対応ができる。

出典: 予算と予算アラートの作成・編集・削除

正解: B 【A（不正解）】 ？ 一定の利用を長期間約束して割引を受ける方法。 誤り。使っても使わなくても期間中は支払いが続くため、夜だけ動く処理には向きにくい。 【B（正解）】 ？ 余った資源を割安に使い、回収されることがある VM。 正解。Spot VM は大幅に割安だが、いつでも回収されうる。中断に強いバッチ処理に向く。 【C（不正解）】 ？ 割引のない VM を止めずに動かす方法。 誤り。使わない時間も費用がかかり、費用を下げる目的に合わない。 【D（不正解）】 ？ 複数のゾーンに同じ VM を並べる構成。 誤り。可用性を上げる構成で、費用はむしろ増える。

出典: Spot VM／確約利用割引の概要

正解: C 【A（不正解）】 ？ 回収されることがある割安な VM。 誤り。いつでも回収されうるうえ SLA の対象外で、止められない基幹システムには向かない。 【B（不正解）】 ？ 月の利用時間に応じた自動の割引を狙う方法。 誤り。対象のマシンシリーズは限られ、作り直す必要もない。長く安定した利用には確約の契約が想定されている。 【C（正解）】 ？ 決まった量の資源を長期で約束する割引。 正解。リソースベースの確約は、予測しやすく安定した利用に向く。期間は1年か3年で、購入後は取り消せない点に注意する。 【D（不正解）】 ？ 利用額の通知機能。 誤り。予算は通知のための機能で、単価そのものは下がらない。

出典: 確約利用割引の概要／Spot VM／継続利用割引

正解: A 【A（正解）】 ？ 月の利用時間に応じて段階的に増える割引。 正解。N1・N2 など一部のマシンシリーズが対象で、月の25%を超えて使うと自動で適用され、申し込みは要らない。確約利用割引が適用済みの利用には重ねて付かない。 【B（不正解）】 ？ 利用を約束する契約で得る割引。 誤り。1年または3年の契約を購入して初めて適用される。 【C（不正解）】 ？ 回収されうる VM の価格。 誤り。Spot VM として作った場合の価格で、通常の VM に自動で付く割引ではない。 【D（不正解）】 ？ 節約の状況をまとめる画面。 誤り。FinOps ハブは節約の実績や機会を表示する機能で、割引そのものではない。

出典: 継続利用割引

正解: B 【A（不正解）】 ？ 長期の利用を約束する割引。 誤り。短期の学習のために長期の支払いを約束することになり、目的に合わない。 【B（正解）】 ？ 必要な数のアクセラレータがそろった時点で起動する仕組み。 正解。必要な量と期間を指定してリクエストし、確保できた時点で VM をまとめて用意する。最長7日間動かせ、早く終われば止めて使った分だけ払える。対象の GPU では割引もある。 【C（不正解）】 ？ 利用額に応じた通知。 誤り。費用の通知はできるが、GPU を確保する仕組みではない。 【D（不正解）】 ？ コードの CPU やメモリの使い方を調べる機能。 誤り。性能の分析には役立つが、GPU を確保する仕組みではない。

出典: Compute Engine のプロビジョニング モデル（Flex-start）／Dynamic Workload Scheduler のご紹介（Google Cloud 公式ブログ）

正解: D 【A（不正解）】 ？ ログを検索して見る画面。 誤り。システムの記録を調べる画面で、費用の内訳は見られない。 【B（不正解）】 ？ リクエストの遅延を追う機能。 誤り。性能の分析に使う機能で、費用は扱わない。 【C（不正解）】 ？ 資源の構成を制限する仕組み。 誤り。構成の制限であり、費用の集計や表示はしない。 【D（正解）】 ？ 請求先アカウントの費用をグラフで表示する機能。 正解。期間やフィルタを指定し、プロジェクト・サービス・SKU・場所・ラベルごとに費用をまとめて表示できる。

出典: Cloud Billing レポートで費用の傾向を見る

正解: A 【A（正解）】 ？ 資源の使用量に上限を設ける仕組み。 正解。クォータはプロジェクトが使える資源の量を制限する。割り当て量の上限と、一定時間あたりのレートの上限がある。 【B（不正解）】 ？ 資源に付けるキーと値の目印。 誤り。整理や費用の追跡に使う目印で、使用量の上限は設けない。 【C（不正解）】 ？ 長く使うほど自動で付く割引。 誤り。単価を下げる仕組みで、使用量は制限しない。 【D（不正解）】 ？ リクエストの遅延を追う機能。 誤り。性能の分析に使う機能で、上限は設定できない。

出典: 割り当て（クォータ）の概要

正解: C 【A（不正解）】 ？ 通知の段階を増やす設定。 誤り。通知の回数が増えるだけで、資源単位の分析データは得られない。 【B（不正解）】 ？ 画面の表示を画像で残す方法。 誤り。画像では自由な集計や、ほかのデータとの結合ができない。 【C（正解）】 ？ 請求データを分析基盤へ自動で送る設定。 正解。詳細な使用料金のエクスポートは、標準の内容に加えて VM やディスクなど資源単位のデータを含む。SQL で自由に分析できる。 【D（不正解）】 ？ 資源の使用量の上限を変える設定。 誤り。使用量の制限であり、増加要因の分析にはならない。

出典: Cloud Billing データを BigQuery にエクスポートする

正解: B 【A（不正解）】 ？ システムやアプリの記録を保存・検索するサービス。 誤り。ログの保存と分析が中心。指標の収集やダッシュボード、アラートポリシーは Cloud Monitoring が担う。 【B（正解）】 ？ 数値の指標を一定の間隔で集めるサービス。 正解。健全性や性能の指標を集めてダッシュボードで見せ、条件を満たしたらアラートポリシーで通知する。試験ガイドでは「オペレーション スイート」という表記も使われている。 【C（不正解）】 ？ コードの CPU とメモリの使い方を調べるサービス。 誤り。どのコードが資源を使うかを分析するもので、アラートの中心ではない。 【D（不正解）】 ？ エラーをまとめて表示するサービス。 誤り。ログからエラーを見つけてまとめる機能で、指標全般の収集やダッシュボードは担わない。

出典: Google Cloud Observability のドキュメント

正解: C 【A（不正解）】 ？ 費用をグラフで見る機能。 誤り。費用の内訳を見る機能で、処理の遅延は分からない。 【B（不正解）】 ？ エラーをまとめて表示するサービス。 誤り。失敗したリクエストの把握には役立つが、成功した呼び出しの遅れの場所は分からない。 【C（正解）】 ？ リクエストが各部品を通る経路と時間を記録するサービス。 正解。分散アプリでのリクエストの経路を追い、どの下流の依存先が遅延を生んでいるかを特定できる。 【D（不正解）】 ？ ログを別の保存先へ送る仕組み。 誤り。転送の仕組みで、呼び出しごとの遅延を可視化する機能ではない。

出典: Cloud Trace の概要

正解: A 【A（正解）】 ？ 本番のアプリから CPU とメモリの使い方を集めるサービス。 正解。本番のアプリから CPU 使用とメモリ割り当ての情報を集め、コードのどこが資源を多く使うかを示す。負荷は小さく抑えられる。 【B（不正解）】 ？ リクエストの経路と時間を記録するサービス。 誤り。サービス間の遅延は分かるが、関数ごとの CPU やメモリの使い方は対象外。 【C（不正解）】 ？ 外部から応答の有無を確かめる機能。 誤り。外から応答を確かめるだけで、コード内部の資源の使い方は分からない。 【D（不正解）】 ？ エラーをまとめて表示するサービス。 誤り。エラーを集約する機能で、正常に動く処理の資源の使い方は分からない。

出典: Cloud Profiler について

正解: D 【A（不正解）】 ？ コードの CPU とメモリの使い方を調べるサービス。 誤り。資源の使い方の分析で、例外をまとめる機能ではない。 【B（不正解）】 ？ 費用をグラフで見る機能。 誤り。費用の内訳を見る機能で、アプリのエラーは扱わない。 【C（不正解）】 ？ リクエストの経路と時間を記録するサービス。 誤り。遅延の分析が中心で、例外をまとめて一覧にする機能ではない。 【D（正解）】 ？ 動いているサービスのエラーを集約して表示するサービス。 正解。Cloud Logging のログを分析してエラーを見つけ、エラー グループにまとめる。上位のエラーや新しいエラーを把握できる。

出典: Error Reporting のドキュメント／Google Cloud Observability のドキュメント

正解: B 【A（不正解）】 ？ 記録だけを残す方法。 誤り。記録はできても通知の仕組みがなく、気づくのが遅れる。 【B（正解）】 ？ 外から定期的に応答を確かめ、条件で通知する構成。 正解。稼働時間チェックは複数の場所から定期的に応答を確かめる。チェックだけでは通知されないため、アラートポリシーを付けて通知する。 【C（不正解）】 ？ リクエストの経路と時間を記録する方法。 誤り。遅延の分析には役立つが、応答停止を知らせる仕組みではない。 【D（不正解）】 ？ 費用の変化から異常を推測する方法。 誤り。費用データには反映の遅れがあり、停止の検知には使えない。

出典: 稼働時間チェックの概要

正解: A 【A（正解）】 ？ ログの写しを指定した保存先へ送る仕組み。 正解。ログシンクは BigQuery・Cloud Storage・Pub/Sub などへログを送れ、BigQuery なら SQL で分析できる。作成前のログは送られない点に注意する。 【B（不正解）】 ？ 画面からログを手で書き出す方法。 誤り。手作業では漏れが出やすく、全プロジェクトのログを継続して保管・分析する仕組みにならない。 【C（不正解）】 ？ エラーの集約画面を画像で残す方法。 誤り。エラーの一覧であり、ログ全体の保管にはならない。 【D（不正解）】 ？ CPU やメモリの使い方の記録を残す方法。 誤り。プロファイルのデータで、監査に使うログではない。

出典: ログの転送と保存の概要

正解: D 【A（不正解）】 ？ 障害がゼロであることを指す考え。 誤り。障害をゼロにするのではなく、決められた条件のもとで機能を果たし続けることを指す。 【B（不正解）】 ？ 費用の増え方に関する考え。 誤り。費用の性質の話で、信頼性の定義ではない。 【C（不正解）】 ？ 情報を守る性質に関する考え。 誤り。これは機密性の説明で、信頼性ではない。 【D（正解）】 ？ 決めた条件で期待どおり動き続ける性質。 正解。公式の信頼性の柱はこのように定義し、サービスを途切れなく保つことも含むとしている。

出典: Well-Architected Framework: 信頼性の柱

正解: B 【A（不正解）】 ？ 振り返りを省く考え。 誤り。インシデントの影響を抑え再発を防ぐため、振り返りと予防策を求めている。 【B（正解）】 ？ 本番を支える準備を計画的に整える取り組み。 正解。運用の卓越性の柱は、SLO の設定や十分な監視、性能テスト、容量計画で運用の準備を整えることを原則に挙げている。 【C（不正解）】 ？ 手作業を中心にする考え。 誤り。手作業を減らすため、自動化と変更管理の効率化を勧めている。 【D（不正解）】 ？ 最大の構成で固定する考え。 誤り。適切なサイズへの調整や自動スケーリング、費用の監視で資源を最適化することを勧めている。

出典: Well-Architected Framework: 運用の卓越性の柱

正解: A 【A（正解）】 ？ 平日の営業時間に技術支援を受ける有料プラン。 正解。小〜中規模で開発中のワークロード向けで、平日の現地の営業時間に英語で支援を受けられる。P2 の初回応答は4時間以内。 【B（不正解）】 ？ 重要なワークロードを持つ企業向けのプラン。 誤り。最速の応答や担当の TAM を含む上位のプランで、この要件には過剰。 【C（不正解）】 ？ 本番を運用する組織向けのプラン。 誤り。本番ワークロードを運用する中〜大規模の組織向けで、開発中心の要件には過剰。 【D（不正解）】 ？ すべての顧客に含まれる基本のサポート。 誤り。ドキュメントやコミュニティ、請求のサポートなどで、1対1の技術支援は含まれない。

出典: Cloud Customer Care でサポートを受ける／Standard Support の概要

正解: C 【A（不正解）】 ？ すべての顧客に含まれる基本のサポート。 誤り。1対1の技術サポートのケースを含まず、P1 の応答目標もない。 【B（不正解）】 ？ 平日の営業時間に技術支援を受けるプラン。 誤り。開発中のワークロード向けで、P2 の初回応答4時間が目安。P1 の1時間の要件を満たさない。 【C（正解）】 ？ 本番を運用する中〜大規模の組織向けのプラン。 正解。P1 の初回応答は1時間以内で、優先度と言語によっては24時間365日対応する。技術アドバイザーは別料金の追加サービス。 【D（不正解）】 ？ 重要なワークロードを持つ企業向けのプラン。 誤り。P1 は15分以内だが、担当の TAM が付く前提のプランで、置かない方針に合わない。

出典: Enhanced Support の概要／Cloud Customer Care でサポートを受ける

正解: B 【A（不正解）】 ？ 本番を運用する中〜大規模の組織向けのプラン。 誤り。P1 の初回応答は1時間以内。技術アドバイザーは別料金の追加サービスになる。 【B（正解）】 ？ 重要なワークロードを持つ企業向けのプラン。 正解。P1 の初回応答は15分以内で、担当の TAM が付く。顧客の構成を把握した支援（Customer Aware Support）も含む。 【C（不正解）】 ？ 平日の営業時間に技術支援を受けるプラン。 誤り。開発中のワークロード向けで、平日の営業時間内の支援が中心。 【D（不正解）】 ？ すべての顧客に含まれる基本のサポート。 誤り。1対1の技術サポートのケースを含まない。

出典: Premium Support の概要／Cloud Customer Care でサポートを受ける

正解: C 【A（不正解）】 ？ 専任の担当者による支援。 誤り。担当の TAM は Premium Support に含まれる。 【B（不正解）】 ？ 最も速い応答の目標。 誤り。15分以内は Premium Support の P1 の目標。 【C（正解）】 ？ 誰でも使える基本の情報と支援。 正解。Basic Support はすべての顧客に含まれる。ドキュメントやコミュニティ、Cloud Billing のサポート、Active Assist の推奨事項を使える。 【D（不正解）】 ？ 個別の技術的な問い合わせの窓口。 誤り。1対1の技術サポートは Standard Support 以上で提供される。

出典: Cloud Customer Care でサポートを受ける

正解: D 【A（不正解）】 ？ 性能の高い VM 1台にまとめる構成。 誤り。その VM やゾーンの障害で配信が止まる。 【B（不正解）】 ？ 同じ場所に予備を置く構成。 誤り。VM の故障には強くなるが、ゾーン全体の障害には耐えられない。 【C（不正解）】 ？ 割安な VM を手作業で運用する構成。 誤り。回収されうる VM で、手作業の復旧では配信が途切れる。 【D（正解）】 ？ 複数のゾーンに同じ VM を並べて負荷を分ける構成。 正解。リージョン MIG は複数ゾーンに VM を分散し、ゾーン障害から守る。故障した VM は自動修復で作り直され、負荷分散が健全な VM に通信を送る。

出典: インスタンス グループ／リージョンとゾーン／スケーラブルで復元力の高いアプリのパターン

正解: B 【A（不正解）】 ？ 読み取り用の複製を足す構成。 誤り。読み取りの分散用で、既定では高可用性の構成ではない。同じゾーンではゾーン障害にも弱い。 【B（正解）】 ？ 同じリージョンの別ゾーンに予備を置く構成。 正解。HA 構成は別ゾーンのスタンバイに書き込みを同期で複製する。障害時はスタンバイが新しいプライマリになる（フェイルオーバー）。 【C（不正解）】 ？ 1日1回データの写しを残す構成。 誤り。データは戻せるが自動の切り替えはできず、復旧まで時間がかかる。 【D（不正解）】 ？ 性能を上げる構成。 誤り。性能は上がるが、ゾーン障害への備えにはならない。

出典: Cloud SQL の高可用性について

正解: A 【A（正解）】 ？ 失ってよいデータを時間で表す目標。 正解。RPO は、障害でデータが失われうる許容の最大時間で、時間で表す。 【B（不正解）】 ？ 止まっていてよい時間の目標。 誤り。これはRTOの説明。 【C（不正解）】 ？ 使える時間の割合を表す指標。 誤り。可用性を表す指標の説明で、RPO ではない。 【D（不正解）】 ？ 写しを残しておく期間。 誤り。保持期間の話で、データ損失の許容時間とは異なる。

出典: 障害復旧計画ガイド

正解: C 【A（不正解）】 ？ すぐに切り替えられる予備を動かし続ける方法。 誤り。ほぼ即時に復旧できるが費用が最も高く、この緩い要件には過剰。 【B（不正解）】 ？ データの写しを常に最新に保つ方法。 誤り。RPO をほぼゼロにする構成で、前日の時点でよい要件には過剰で費用がかさむ。 【C（正解）】 ？ 障害が起きてから環境を用意する方法。 正解。RTO と RPO が小さいほど費用は上がる。要件が緩いなら、バックアップから戻すコールドな構成で費用を抑えられる。 【D（不正解）】 ？ 備えを持たない方法。 誤り。前日夜の時点のデータに戻すにはバックアップが要る。

出典: 障害復旧計画ガイド

正解: A 【A（正解）】 ？ 指定した2つのリージョンにデータを置く種類。 正解。デュアルリージョンは指定した2つのリージョンにデータを複製し、コピーの置き場所を正確に管理できる。災害復旧に向く。 【B（不正解）】 ？ 1つのリージョンにデータを置く種類。 誤り。リージョン内の複数ゾーンには冗長化されるが、リージョン全体の障害には備えられない。 【C（不正解）】 ？ 広い地域にまたがって複数のリージョンに置く種類。 誤り。複数のリージョンに冗長化されるが、広い地理的範囲が単位で、置き場所を特定の2地域に絞れない。 【D（不正解）】 ？ 1つのゾーンに置くディスク。 誤り。1つのゾーンに置かれる資源で、リージョン全体の障害には備えられない。

出典: Cloud Storage のバケットのロケーション

正解: D 【A（不正解）】 ？ 使い慣れた場所と権限で管理する方法。 誤り。権限が広いと、攻撃者に同じ権限で消される恐れがある。最小権限の原則にも反する。 【B（不正解）】 ？ 複製した構成だけに頼る方法。 誤り。冗長化は障害時の継続に役立つが、削除や改ざんの前の時点に戻すにはバックアップが要る。 【C（不正解）】 ？ 最新の写しだけを持つ方法。 誤り。感染後のデータで上書きすると、感染前の状態に戻せない。 【D（正解）】 ？ 一度書いたら変えられない保管場所を使う方法。 正解。バックアップ保管庫は書き込み後の変更や削除を防ぐ。ランサムウェアや誤削除があっても復元できるようにする。

出典: Backup and DR サービスの概要

正解: B 【A（不正解）】 ？ 資源の種類を並べたもの。 誤り。資源の種類の例で、ゴールデンシグナルではない。飽和度を測る材料にはなる。 【B（正解）】 ？ 応答の速さ・量・失敗・余裕を並べたもの。 正解。Google の SRE の考え方では、利用者向けのシステムをこの4つで監視することを勧めている。 【C（不正解）】 ？ システムの性質を並べたもの。 誤り。情報セキュリティや設計の性質で、監視の4指標ではない。 【D（不正解）】 ？ 復旧やサービスレベルの目標を並べたもの。 誤り。復旧目標やサービスレベルの用語で、監視の4指標ではない。

出典: スケーラブルで復元力の高いアプリのパターン

正解: C 【A（不正解）】 ？ リクエストへの応答にかかる時間。 誤り。応答の遅さを表す指標で、資源の使い切りの度合いではない。 【B（不正解）】 ？ サービスに届くリクエストの量。 誤り。負荷の量を表す指標で、資源の余裕は表さない。 【C（正解）】 ？ 資源がどれだけ使い切りに近いか。 正解。飽和度はサービスの資源がどれだけ満杯に近いかを表す。Cloud Run などでは CPU 使用率で見ることが多い。 【D（不正解）】 ？ 失敗したリクエストの割合。 誤り。失敗の割合を表す指標で、CPU の使い切りの度合いではない。

出典: Application Monitoring がサポートするインフラストラクチャ／スケーラブルで復元力の高いアプリのパターン

正解: A 【A（正解）】 ？ 応答の速さを表す指標。 正解。遅さは応答時間で測る。公式のアプリケーション監視でも P95 のレイテンシを表示する。 【B（不正解）】 ？ 負荷の量を表す指標。 誤り。負荷の量を表し、遅さそのものではない。原因の手がかりにはなる。 【C（不正解）】 ？ 失敗の多さを表す指標。 誤り。失敗の割合で、成功した応答の遅さは測れない。 【D（不正解）】 ？ 資源の余裕を表す指標。 誤り。遅さの原因になりうるが、利用者が感じる遅さを直接表す指標ではない。

出典: Application Monitoring がサポートするインフラストラクチャ／スケーラブルで復元力の高いアプリのパターン

正解: C 【A（不正解）】 ？ サービスの振る舞いを直接測った値。 誤り。SLI は測定値そのもので、約束ではない。 【B（不正解）】 ？ 測定値について決める目標。 誤り。SLO は社内で決める目標で、それ自体に罰則は伴わない。 【C（正解）】 ？ 利用者と交わす約束。 正解。SLA は一定期間に一定の水準を満たすという利用者への約束で、満たせないと返金などの罰則が生じる。 【D（不正解）】 ？ 目標の範囲で許される失敗の量。 誤り。SLO から決まる失敗の許容量で、利用者との約束ではない。

出典: SRE fundamentals: SLI vs SLO vs SLA（Google Cloud 公式ブログ）／SLO モニタリングのコンセプト

正解: D 【A（不正解）】 ？ 約束と同じ値にする考え。 誤り。同じ値だと、SLO を割り込んだ時点でもう約束違反で、手を打つ余裕がない。 【B（不正解）】 ？ 約束より緩い目標にする考え。 誤り。社内の目標が緩いと、約束違反を事前に防げない。 【C（不正解）】 ？ 失敗を一切認めない考え。 誤り。100% の SLO にはエラーバジェットがなく、公式に悪い慣行とされている。 【D（正解）】 ？ 約束より高い目標を持つ考え。 正解。SLO は公の約束より厳しくし、約束を破る前に問題に気づけるようにする。公式の記事も 99.9% の SLA に社内 99.95% の例を挙げている。

出典: SRE fundamentals: SLI vs SLO vs SLA（Google Cloud 公式ブログ）／SLO モニタリングのコンセプト

正解: B 【A（不正解）】 ？ 予定を優先する考え。 誤り。予算がほぼ尽きた状態での危険な変更は、SLO 違反につながりやすい。 【B（正解）】 ？ 変更を控えて安定を取り戻す考え。 正解。予算が尽きかけているときは、新しい更新のような危険な行動に適さない。信頼性の回復に力を振り向ける。 【C（不正解）】 ？ 目標の値を都合に合わせて変える考え。 誤り。目標をその場で変えると、SLO で判断する仕組みが機能しなくなる。 【D（不正解）】 ？ 測定をやめる考え。 誤り。問題を見えなくするだけで、信頼性は上がらない。

出典: SLO を設計する（Cloud Service Mesh）

正解: A 【A（正解）】 ？ 100万件に対する割合では 0.1% に当たる。 正解。エラーバジェットは（1 − SLO）× 対象件数で求める。(1 − 0.999) × 1,000,000 = 1,000 件。 【B（不正解）】 ？ 100万件に対する割合では 0.01% に当たる。 誤り。0.01% で計算しており、SLO 99.99% の場合の値になる。 【C（不正解）】 ？ 100万件に対する割合では 1% に当たる。 誤り。1% で計算しており、SLO 99% の場合の値になる。 【D（不正解）】 ？ 100万件に対する割合では 99.9% に当たる。 誤り。成功が求められる件数で、許される失敗の数ではない。

出典: SLO モニタリングのコンセプト

正解: C 【A（不正解）】 ？ 資源の使い切りの度合い。 誤り。資源の飽和度の指標で、利用者から見た成功の割合ではない。 【B（不正解）】 ？ リクエストの量。 誤り。トラフィックの量で、成功したかどうかは分からない。 【C（正解）】 ？ うまくいった応答の割合。 正解。可用性の SLI の一般的な例は、成功した応答の数 ÷ 全応答の数。 【D（不正解）】 ？ 開発の進み具合。 誤り。開発の量で、サービスの性能や信頼性を測るものではない。

出典: SLO モニタリングのコンセプト

正解: D 【A（不正解）】 ？ 個人の責任を問う進め方。 誤り。責めると人が正直に話さなくなる。非難しない文化が勧められている。 【B（不正解）】 ？ 記録だけを残す進め方。 誤り。目的は学びと再発防止で、対策を決めないと同じ障害を繰り返す。 【C（不正解）】 ？ 大きな障害だけを扱う進め方。 誤り。公式指針は徹底した振り返りを求めており、小さな障害からも学べる。 【D（正解）】 ？ 仕組みの改善に焦点を当てる進め方。 正解。非難しない文化のもとで、人を取り巻くシステムやツール、プロセスの改善に焦点を当てる。

出典: SRE の原則で本番インシデントの影響を小さくする（Google Cloud 公式ブログ）／Well-Architected Framework: 信頼性の柱

正解: D 【A（不正解）】 ？ 人を足して作業を分ける方法。 誤り。人を増やしても、繰り返し作業そのものは減らない。 【B（不正解）】 ？ 作業の頻度を下げる方法。 誤り。作業は減っても障害に気づくのが遅れ、信頼性が下がる。 【C（不正解）】 ？ 手順を整えて手作業を続ける方法。 誤り。手順書は役立つが、手作業が残る限りトイルは減らない。 【D（正解）】 ？ 人手の作業を仕組みに置き換える方法。 正解。公式ガイドは、SRE の勧めとしてトイルは自動化を増やして取り除くとしている。マネージドサービスの利用も運用者の時間を生む。

出典: Google Cloud への移行: 環境の最適化

正解: D 【A（不正解）】 ？ 外から応答の有無を確かめる仕組み。 誤り。外からの応答確認で、予算の減る速さは見ない。 【B（不正解）】 ？ 費用の予算に対する通知。 誤り。費用の予算の通知で、名前は似ているがエラーバジェットとは別物。 【C（不正解）】 ？ コードの資源の使い方を調べる仕組み。 誤り。性能の分析で、予算の消費は監視しない。 【D（正解）】 ？ 予算が減る速さを条件に通知する仕組み。 正解。エラーバジェットが望ましい速さより速く消費されているときに警告するアラートポリシーを作れる。

出典: SLO モニタリングのコンセプト

正解: B 【A（不正解）】 ？ データを取り出し、変換して読み込む処理。 誤り。データ連携の処理の名前で、運用の分野ではない。 【B（正解）】 ？ 信頼性の高い運用をエンジニアリングで実現する分野。 正解。公式ガイドは、効果的な DevOps の文化を実践する手引きとして SRE を挙げる。組織に合う一部から取り入れる方法も示している。 【C（不正解）】 ？ 設備など将来にわたって使う資産への支出。 誤り。費用の分類で、運用の分野ではない。 【D（不正解）】 ？ 検索した情報を生成 AI の回答に使う技術。 誤り。生成 AI の技術で、運用の分野ではない。

出典: Google Cloud への移行: 環境の最適化