CertPass

Question 172

あなたの開発チームは、サービスのAPIの新しいバージョンを作成しました。サードパーティの開発者や、サードパーティ製のインストール済みアプリケーションのエンドユーザーへの影響を最小限に抑えつつ、APIの新バージョンをデプロイする必要があります。どうすべきですか？

新しいバージョンのAPIを導入する。旧バージョンのAPIの非推奨化を発表する。旧バージョンのAPIを非推奨化する。旧APIの残りのユーザーに連絡する。旧APIのユーザーにベストエフォートでサポートを提供する。旧バージョンのAPIを停止する。

旧バージョンのAPIの非推奨化を発表する。新しいバージョンのAPIを導入する。旧APIの残りのユーザーに連絡する。旧バージョンのAPIを非推奨化する。旧バージョンのAPIを停止する。旧APIのユーザーにベストエフォートでサポートを提供する。

旧バージョンのAPIの非推奨化を発表する。旧APIの残りのユーザーに連絡する。新しいバージョンのAPIを導入する。旧バージョンのAPIを非推奨化する。旧APIのユーザーにベストエフォートでサポートを提供する。旧バージョンのAPIを停止する。

新しいバージョンのAPIを導入する。旧APIの残りのユーザーに連絡する。旧バージョンのAPIの非推奨化を発表する。旧バージョンのAPIを非推奨化する。旧バージョンのAPIを停止する。旧APIのユーザーにベストエフォートでサポートを提供する。

Question 173

あなたはCompute Engine上でアプリケーションを実行し、Stackdriver経由でログを収集しています。特定のログエントリのフィールドに、一部の個人情報 (PII) が漏洩していることを発見しました。これらのフィールドが新しいログエントリに書き込まれるのを、できるだけ早く防ぎたいと考えています。何をすべきでしょうか？

filter-record-transformer Fluentd フィルタープラグインを使用して、処理中のログエントリからフィールドを削除します。

fluent-plugin-record-reformer Fluentd 出力プラグインを使用して、処理中のログエントリからフィールドを削除します。

アプリケーション開発者がアプリケーションにパッチを適用するのを待ち、その後、ログエントリがPIIを公開しなくなったことを確認します。

ログエントリをCloud Storageにステージングし、Cloud Functionsをトリガーしてフィールドを削除し、Stackdriver Logging API経由でエントリをStackdriverに書き込みます。

Question 174

あなたは最近障害が発生したサービスをサポートしています。障害の原因は、サービスのメモリリソースを枯渇させた新しいリリースでした。ユーザーへの影響を軽減するために、リリースのロールバックに成功しました。あなたは現在、この障害の事後検証を担当しています。事後検証を作成するにあたり、サイト信頼性エンジニアリング（SRE）のプラクティスに従いたいと考えています。何をすべきでしょうか？

障害の再発防止よりも、新機能の開発に注力する。

原因となった個人を特定するのではなく、インシデントの寄与原因の特定に注力する。

関係したすべてのエンジニアと個別にミーティングを計画する。誰が新しいリリースを承認し、本番環境にプッシュしたかを特定する。

Gitの履歴を使用して関連するコードコミットを見つける。そのコミットを行ったエンジニアが本番サービスで作業できないようにする。

Question 175

あなたは高トラフィックのウェブアプリケーションをサポートしており、ホームページが適切な時間内に読み込まれるようにしたいと考えています。最初のステップとして、ホームページのリクエストレイテンシを表すサービスレベル指標（SLI）を実装することにしました。許容されるページ読み込み時間は100ミリ秒に設定されています。このSLIを計算するためのGoogleが推奨する方法は何ですか？

リクエストのレイテンシを範囲ごとにバケット化し、その後100ミリ秒でのパーセンタイルを計算する。

リクエストのレイテンシを範囲ごとにバケット化し、その後中央値と90パーセンタイルを計算する。

100ミリ秒未満で読み込まれるホームページのリクエスト数をカウントし、それをホームページの総リクエスト数で割る。

100ミリ秒未満で読み込まれるホームページのリクエスト数をカウントし、それをウェブアプリケーションのすべてのリクエストの総数で割る。

Question 176

あなたはユーザー向けのウェブアプリケーションをサポートしています。過去6ヶ月間のアプリケーションのエラーバジェットを分析したところ、どの期間においてもアプリケーションがエラーバジェットの5%以上を消費したことがないことに気づきました。ビジネス関係者とサービスレベル目標（SLO）のレビューを行い、SLOが適切に設定されていることを確認しました。あなたは、アプリケーションのSLOが観測された信頼性をより密接に反映するようにしたいと考えています。開発速度、信頼性、およびビジネスニーズのバランスを取りながら、その目標を推進するためにどのような手段を講じることができますか？（2つ選択してください。）

アプリケーションのすべてのゾーンにサービングキャパシティを追加する。

より頻繁な、または潜在的にリスクのあるアプリケーションリリースを行う。

観測されたアプリケーションの信頼性に一致するようにSLOを厳しくする。

アプリケーションの追加のサービスレベル指標（SLI）を実装し、測定する。

より多くのエラーバジェットを消費するために計画停止を発表し、ユーザーがより厳しいSLOに依存していないことを確認する。

Professional Cloud DevOps Engineer