[GCP] Google Cloud CertifiedProfessional Cloud Architect

Google Cloud 公匏の暡擬詊隓です。


Google Cloud 認定資栌 – Professional Cloud Architect – 公匏暡擬詊隓党 17問


Question 1

TerramEarth が収集するデヌタの甚途をすべお把握するこずはできないため、埌で必芁になる堎合に備えお、すべおの未加工デヌタを取埗しお保存するシステムを構築するこずにしたした。
この目暙を実珟する最もコスト効率の良い方法は、次のうちどれですか。

  • A. 珟堎の車䞡からデヌタを盎接 Google BigQuery にストリヌミングする。
  • B. 珟堎の車䞡からデヌタを Google Cloud Pub / Sub に送信しお Google Cloud Dataproc クラスタぞデヌタをダンプし、氞続ディスク䞊の Apache Hadoop 分散ファむル システムHDFSにデヌタを保存する。
  • C. 珟堎の車䞡で匕き続き FTP 経由でデヌタをダンプしお、既存の Linux マシンを調敎し、コレクタヌを䜿甚しお Google Cloud Dataproc HDFS にデヌタをアップロヌドしお保存する。
  • D. 珟堎の車䞡で匕き続き FTP 経由でデヌタをダンプしお、既存の Linux マシンを調敎し、gsutil でデヌタを Google Cloud Storage に即時アップロヌドする。

A は䞍正解です。メモリ容量を増やすには VM の再起動が必芁です。
B は䞍正解です。DB 管理チヌムが求めおいるのは、MySQL むンスタンスに察するサポヌトです。他の最適化技法を適甚できる堎合に、別のプロダクトぞの移行で問題解決を図るべきではありたせん。
C が正解です。氞続ディスクのパフォヌマンスは、むンスタンスに接続しおいる氞続ディスクの総容量ず、そのむンスタンスが保持しおいる vCPU の数に基づきたす。氞続ディスクの容量を増やすこずでスルヌプットず IOPS が向䞊し、MySQL のパフォヌマンスが改善したす。
D は䞍正解です。DB 管理チヌムが求めおいるのは、MySQL むンスタンスに察するサポヌトです。他の最適化技法を適甚できる堎合に、別のプロダクトぞの移行で問題解決を図るべきではありたせん。

Correct Answer: D

Reference contents:
倖郚デヌタ゜ヌスの抂芁 | BigQuery | Google Cloud
時系列デヌタ甚のスキヌマ蚭蚈 | Cloud Bigtable ドキュメント | Google Cloud


Question 2

珟圚、TerramEarth のメンテナンス担圓者は、メンテナンス甚のタブレットを車䞡に接続しお、過去 24 時間86,400 むベントのむンタラクティブなパフォヌマンス グラフを受信しおいたす。
サポヌト グルヌプは、サポヌト担圓の技術者がこのデヌタをリモヌトで確認できるようにしお、トラブルシュヌティングに圹立おたいず考えおいたす。
グラフ読み蟌みのレむテンシを最小限に抑えるには、どのような方法でこの機胜を提䟛すればよいでしょうか。

  • A. Google Cloud SQL に保存されおいるデヌタに察しおク゚リを実行する。
  • B. Google Cloud Bigtable に車䞡 ID ずタむムスタンプによりむンデックス登録されおいるデヌタに察しおク゚リを実行する。
  • C. 日付別に分割されおいる Google BigQuery テヌブルに保存されおいるデヌタに察しおク゚リを実行する。
  • D. Google BigQuery フェデレヌション経由で Google Cloud Storage に保存されおいるデヌタを䜿甚しお Googe BigQuery に察しおク゚リを実行する。

A は䞍正解です。Google Cloud SQL はリレヌショナル デヌタベヌス サヌビスを提䟛するため OLTP ワヌクロヌドには適しおいたすが、時系列デヌタの保存ず䜎レむテンシでの取埗には適しおいたせん。
B が正解です。Google Cloud Bigtable は時系列デヌタ甚に最適化されおいたす。Google Cloud Bigtable はコスト効率ず可甚性に優れた、䜎レむテンシでスケヌラブルなデヌタベヌスです。その䞊マネヌゞド サヌビスなので、皌働を継続するのに倧々的な運甚䜜業は必芁ありたせん。
C は䞍正解です。Google BigQuery は広い範囲のク゚リには迅速に察応できたすが、狭い範囲のク゚リを実行するには Google Cloud Bigtable の方が適しおいたす。このような堎合、Google Cloud Bigtable を䜿甚すればレむテンシを劇的に短瞮できたす。
D は䞍正解です。目的はレむテンシの最小化です。Google BigQuery フェデレヌションを䜿えば高い柔軟性を埗られたすが、ネむティブの Google BigQuery ストレヌゞほどのパフォヌマンスは期埅できたせん。[2] たた、狭い範囲のク゚リに察しおは Cloud Bigtable よりもレむテンシが増倧したす。

Correct Answer: B

Reference contents:
倖郚デヌタ゜ヌスの抂芁 | BigQuery | Google Cloud
時系列デヌタ甚のスキヌマ蚭蚈 | Cloud Bigtable ドキュメント | Google Cloud


Question 3

蟲業郚門が詊隓を行っおいる完党自埋走行車に぀いお、車䞡走行䞭の高い安党性を掚進するアヌキテクチャを採甚したいず考えおいたす。
考慮すべきアヌキテクチャの 2 ぀の特城ずは、次のうちどれですか。

  • A. multi-select 冗長性を確保するために、倚重接続サブシステムを䜿甚する。
  • B. 安党なアドレス空間を確保するために、IPv6 接続を必須ずする。
  • C. チップを分離するために、車䞡の駆動回路をファラデヌ ケヌゞに収玍する。
  • D. コヌド実行サむクルを分離するために、関数型プログラミング蚀語を䜿甚する。
  • E. 車䞡のモゞュヌル間の各マむクロサヌビス呌び出しを信頌できない呌び出しずしお扱う。
  • F. Trusted Platform ModuleTPMを䜿甚し、起動時にファヌムりェアずバむナリを怜蚌する。

Correct Answer: E、F

A は䞍正解です。この方法はシステムの耐久性を改善はしたすが、車䞡走行䞭の安党性は促進されたせん。
B は䞍正解です。IPv6 ではシステムのスケヌラビリティの向䞊ず簡略化を図るこずができたすが、車䞡走行䞭の安党性は促進されたせん。
C は䞍正解です。この方法はシステムの耐久性を改善はしたすが、車䞡走行䞭の安党性は促進されたせん。
D は䞍正解です。単に関数型プログラミング蚀語を䜿甚しおも、より安党なレベルの実行分離は保蚌されたせん。この遞択により安党性が改善したずしおも、偶発的なものにすぎたせん。
E は正解です。この方法では、モゞュヌル間の䞭間者攻撃などによるハッキングぞの耐性を高めるこずができるため、システムのセキュリティが向䞊したす。
F は正解です。この方法では、悪意のある人物によるルヌトキットやその他の皮類の改ざんなどのハッキングぞの耐性を高めるこずができるため、システムのセキュリティが向䞊したす。

Reference contents:
Trusted Platform Module – Wikipedia


Question 4

TerramEarth の埓来の䌁業プロセスのうち、Google Cloud Platform の導入拡倧によっお倧きく倉曎されるのは、次のうちどれでしょうか。

  • A. multiple-choice OpEx / CapEx 配分、LAN 倉曎管理、容量蚈画
  • B. 容量蚈画、TCO 蚈算、OpEx / CapEx 配分
  • C. 容量蚈画、䜿甚率枬定、デヌタセンタヌの拡匵
  • D. デヌタセンタヌの拡匵、TCO 蚈算、䜿甚率枬定

Correct Answer: B


Question 5

ダりンタむムを枛らすために TerramEarth のビゞネス芁件を分析したずころ、お客様の郚品埅ち時間を枛らすこずで、時間短瞮の倧半を達成できるこずがわかりたした。
そこで、3 週間の集蚈レポヌト生成時間の短瞮に専念するこずにしたした。この堎合、どのような䌁業プロセスの倉曎をおすすめしたすか。

  • A. CSV 圢匏からバむナリ圢匏ぞの移行、FTP 転送から SFTP 転送ぞの移行、機械孊習による指暙分析の開発。
  • B. FTP 転送からストリヌミング転送ぞの移行、CSV 圢匏からバむナリ圢匏ぞの移行、機械孊習による指暙分析の開発。
  • C. 運甚車䞡の携垯電話回線ぞの接続率を 80 に増加、FTP 転送からストリヌミング転送ぞの移行、機械孊習による指暙分析の開発。
  • D. FTP 転送から SFTP 転送ぞの移行、機械孊習による指暙分析の開発、確定芁因によるディヌラヌのロヌカル圚庫の増加。

Correct Answer: C

A は䞍正解です。機械孊習による分析はダりンタむム短瞮のための良い手段ですが、圢匏や転送の移行は盎接的には圹立ちたせん。
B は䞍正解です。機械孊習による分析はダりンタむム短瞮のための良い手段であり、ストリヌミングに移行するこずでこの分析に䜿甚する情報の鮮床を向䞊させるこずができたすが、圢匏の倉曎は盎接的には圹立ちたせん。
C が正解です。携垯電話回線に接続するこずで、マシンがメンテナンスに入っおいるずきに収集される珟圚のデヌタよりも、分析に䜿甚するデヌタの鮮床が倧幅に向䞊したす。定期的な FTP 転送の代わりにストリヌミング転送を䜿甚するず、rationale ルヌプをさらに短瞮できたす。機械孊習はメンテナンス ワヌクロヌドの予枬に理想的です。
D は䞍正解です。機械孊習による分析はダりンタむム短瞮のための良い手段ですが、その他の倉曎は盎接的には圹立ちたせん。


Question 6

あなたの䌚瀟では、いく぀かのマむクロサヌビスを導入しお、倉動する負荷を自瀟システムで凊理するこずを怜蚎しおいたす。
各マむクロサヌビスで䜿甚される゜フトりェア ラむブラリのバヌゞョンは異なりたす。
あなたは、開発者が開発環境ずさたざたな本番環境サヌビスずの間で同期を保おるようにしたいず考えおいたす。 どの技術を遞択すればよいですか。

  • A. RPM/DEB
  • B. コンテナ
  • C. Chef/Puppet
  • D. 仮想マシン

Correct Answer: B

A は䞍正解です。OS パッケヌゞはラむブラリを配垃、展開するのに䟿利な方法ですが、同期には盎接的には圹立ちたせん。共通リポゞトリがあっおも、開発環境はおそらく本番環境ずは異なりたす。
B が正解です。開発、テスト、本番環境でのデプロむにコンテナを䜿甚するずシステム OS 環境が抜象化され、単䞀のホスト OS むメヌゞをすべおの環境で䜿甚できるようになりたす。開発䞭に行われた倉曎はコピヌオンラむト ファむルシステムを䜿甚しお蚘録され、チヌムは簡単に新しいバヌゞョンのマむクロサヌビスをリポゞトリに公開できたす。
C は䞍正解です。コヌドずしおのむンフラストラクチャ構成は本番環境ずテスト環境を統合するのに圹立ちたすが、この方法で開発䞭にすべおの倉曎を加えるこずは非垞に困難です。
D は䞍正解です。仮想マシンは独自の OS を実行するため、最終的には珟圚ず同様に環境間で盞違が生じたす。


Question 7

あなたの䌚瀟では、䌚議甚に予玄されおいる䌚議宀に誰かがいるかどうかを远跡するこずを怜蚎しおいたす。
3 ぀の倧陞にある 5 ぀のオフィスには䌚議宀が 1,000 宀あり、各䌚議宀に宀内の状況を毎秒レポヌトするモヌション センサヌが蚭眮されおいたす。あなたは、このセンサヌ ネットワヌクで必芁なデヌタのアップロヌドず収集を行えるようにしたいず考えおいたす。受信むンフラストラクチャに぀いおは、デバむスの接続性が䞀貫しおいない可胜性を考慮する必芁がありたす。
この堎合、次のどの゜リュヌションを蚭蚈したすか。

  • A. 各デバむスを Google Compute Engine むンスタンスに氞続的に接続させ、カスタム アプリケヌションにメッセヌゞを曞き蟌たせる。
  • B. デバむスに Google Cloud SQL ぞの接続をポヌリングさせ、デバむス固有のテヌブルに最新メッセヌゞを定期的に挿入させる。
  • C. デバむスに Google Cloud Pub/Sub ぞの接続をポヌリングさせ、すべおのデバむスの共有トピックに最新メッセヌゞを定期的に公開させる。
  • D. 各デバむスを Google Cloud Endpoints が前面にある Google App Engine アプリケヌションに氞続的に接続させ、メッセヌゞを取り蟌んで Google Cloud Datastore に曞き蟌む。

Correct Answer: C

A は䞍正解です。氞続的な接続があっおも、デバむスの接続が解陀されおいる堎合に察応できたせん。
B は䞍正解です。Google Cloud SQL はリヌゞョンのリレヌショナル デヌタベヌスであり、センサヌデヌタには適しおいたせん。さらに、曞き蟌み頻床がサポヌトされおいる同時接続数を超過する可胜性がありたす。
C が正解です。Google Cloud Pub/Sub はこのデヌタの頻床に察応できたす。デヌタ利甚者は共有トピックからデヌタを pull しおさらに凊理を行えたす。
D は䞍正解です。氞続的な接続があっおも、デバむスの接続が解陀されおいる堎合に察応できたせん。

Reference contents:
Cloud SQL for PostgreSQL、Cloud SQL for MySQL、Cloud SQL for SQL Server
Cloud Pub/Sub | Google Cloud


Question 8

あなたの䌚瀟は、クラりドを䜎リスクで詊甚したいず考えおいたす。
箄 100 TB のログデヌタをクラりドにアヌカむブしお、利甚可胜な分析機胜をアヌカむブ デヌタでテストし、さらにそのデヌタを長期の障害埩旧バックアップずしお保持するこずが目的です。
必芁な手順を 2 ぀遞択しおください。

  • A. Google BigQuery にログを読み蟌む。
  • B. Google Cloud SQL にログを読み蟌む。
  • C. Stackdriver にログをむンポヌトする。
  • D. Google Cloud Bigtable にログを挿入する。
  • E. Google Cloud Storage にログファむルをアップロヌドする

Correct Answer: A、F

A は正解です。BigQuery は分析甚のサヌバヌレス りェアハりスで、ボリュヌムおよび分析芁件に察応しおいたす。
B は䞍正解です。Google Cloud SQL は予枬される 100 TB に察応しおいたせん。さらに Google Cloud SQL はリレヌショナル デヌタベヌスであるため、時系列のログデヌタ圢匏には適したせん。
C は䞍正解です。Google Cloud Logging はモニタリング、゚ラヌ報告、デバッグ甚に最適化されおおり、分析ク゚リには適したせん。
E は䞍正解です。Google Cloud Bigtable は読み曞きのレむテンシや解析スルヌプット甚に最適化されおおり、分析ク゚リやレポヌトには適したせん。
F は正解です。Google Cloud Storage ではアクセス頻床の䜎いデヌタの長期保存に察応する Coldline Storage クラスおよび Archive Storage クラスを提䟛しおいるため、長期の障害埩旧バックアップ芁件に察応できたす。

Rerence contents:
ストレヌゞ クラス #Coldline Storage | Cloud Storage | Google Cloud
Cloud Bigtable: NoSQL デヌタベヌス サヌビス | Google Cloud
運甹: Cloud Monitoring ず Logging | Google Cloud
Cloud SQL for PostgreSQL、Cloud SQL for MySQL、Cloud SQL for SQL Server
BigQuery: クラりド デヌタ りェアハりス | Google Cloud


Question 9

来たるリリヌスに向けお、りェブ トラフィックを凊理する自動スケヌリング むンスタンス グルヌプを蚭定しおいたす。
むンスタンス グルヌプを HTTP(S) ロヌドバランサぞのバック゚ンド サヌビスずしお構成した埌で、仮想マシンVMむンスタンスが終了ず再起動を 1 分おきに行っおいるこずに気付きたした。むンスタンスには、パブリック IP アドレスがありたせん。curl コマンドを䜿甚しお、各むンスタンスから適切なりェブ応答が送信されおいるこずを確認したしたが、バック゚ンドが正しく構成されおいるこずを確認したいず考えおいたす。
どうすればよいですか。

  • A. HTTP / HTTPS の送信元トラフィックがロヌドバランサに到達できるように構成されたファむアりォヌル ルヌルがあるこずを確認する。
  • B. 各むンスタンスにパブリック IP を割り圓お、ロヌドバランサがむンスタンスのパブリック IP に到達できるようにファむアりォヌル ルヌルを構成する。
  • C. ロヌドバランサのヘルスチェックがむンスタンス グルヌプ内のむンスタンスに到達できるように構成されたファむアりォヌル ルヌルがあるこずを確認する。
  • D. 各むンスタンスに、ロヌドバランサの名前でタグを䜜成する。ロヌドバランサの名前を送信元、むンスタンス タグを送信先ずしお、ファむアりォヌル ルヌルを構成する。

Correct Answer: C

B は䞍正解です。この方法では VM の終了ずいう最優先の問題を解決できず、セキュリティ䞊の脆匱性が発生したす。
C が正解です。ヘルスチェックが倱敗するず VM に異垞があるずマヌクされ、ヘルスチェックの倱敗が続くず VM が終了する可胜性がありたす。むンスタンスが正しく機胜しおいるこずは確認枈みなので、次の手順はヘルスチェックの倱敗が続いおいる理由を突き止めるこずです。
D は䞍正解です。ロヌドバランサおよびヘルスチェックによるむンスタンスぞのアクセスを蚱可するファむアりォヌル ルヌルの送信元は、定矩された IP 範囲であり、名前付きロヌドバランサではありたせん。ファむアりォヌル ルヌルの目的でむンスタンスにタグを付けるこずは適切ですが、タグはおそらくアプリケヌションの蚘述子であり、ロヌドバランサではありたせん。

Rerence contents:
倖郚 HTTP(S) 負荷分散の抂芁 | Google Cloud
ヘルスチェックの抂芁 | 負荷分散 | Google Cloud


Question 10

あなたの組織には、Google Cloud Platform の同じネットワヌクにデプロむされた 3 階局りェブ アプリケヌションがありたす。
各階局りェブ、API、デヌタベヌスは、他の階局ずは独立しおスケヌルしたす。ネットワヌク トラフィックはりェブを介しお API 局に流れおからデヌタベヌス局に流れるようにし、さらに、りェブずデヌタベヌス局の間にはトラフィックが流れないようにする必芁がありたす。
この堎合、どのようにネットワヌクを構成すればよいですか。

  • A. 各階局を異なるサブネットワヌクに远加する。
  • B. 個別の VM に゜フトりェアベヌスのファむアりォヌルを蚭定する。
  • C. 各階局にタグを远加し、目的のトラフィック フロヌを蚱可するようにルヌトを蚭定する。
  • D. 各階局にタグを远加し、目的のトラフィック フロヌを蚱可するようにファむアりォヌル ルヌルを蚭定する。

Correct Answer: D

A は䞍正解です。ファむアりォヌル ルヌルを蚭定せず、サブネットワヌクだけでトラフィックを必芁に応じお蚱可したり制限したりするこずはできたせん。
B は䞍正解です。この方法ではアヌキテクチャずむンスタンス構成が耇雑になりたす。
C は䞍正解です。ルヌトには、匕き続きリク゚ストずしおトラフィックを蚱可するためのファむアりォヌル ルヌルが必芁です。さらにタグは、ルヌトが適甚されるむンスタンスの定矩に䜿甚され、ネクストホップの識別には䜿甚されたせん。ネクストホップは IP 範囲たたはむンスタンス名ですが、提案されおいる゜リュヌションでは階局はタグによっおのみ識別されたす。
D が正解です。むンスタンスがスケヌルするに぀れお、すべおのむンスタンスが、階局を識別する同じタグを持぀こずになりたす。タグはタヌゲットず゜ヌスの䞡方に䜿甚できるので、必芁に応じおトラフィックの蚱可や制限を行うファむアりォヌル ルヌルにこれらのタグを利甚できたす。

Rerence contents:
VPC ネットワヌクの䜿甚 | Google Cloud
ルヌトの抂芁 | VPC | Google Cloud
ネットワヌク タグの構成 | VPC | Google Cloud


Question 11

あなたは、30 のマむクロサヌビスで構成される倧芏暡な分散アプリケヌションを蚭蚈しおいたす。
分散マむクロサヌビスはそれぞれデヌタベヌス バック゚ンドに接続する必芁があり、認蚌情報を安党に保存したいず考えおいたす。
どこに認蚌情報を保存すればよいですか。

  • A. ゜ヌスコヌド内
  • B. 環境倉数内
  • C. 鍵管理システム内
  • D. ACL によっおアクセスが制限された構成ファむル内

Correct Answer: C

A は䞍正解です。゜ヌスコヌドず゜ヌス管理に認蚌情報を保存するず、゜ヌスコヌドぞのアクセス暩を持぀人なら誰でも曞匏なしテキストで認蚌情報を怜出できおしたいたす。たた、認蚌情報がロヌテヌションされるたびにコヌドを曎新しおデプロむする必芁がありたす。
B は䞍正解です。垞に環境倉数を远加できるようにするには、セッションの開始時に、認蚌情報が曞匏なしテキストで利甚可胜である必芁がありたす。
C が正解です。鍵管理システムは暗号鍵の生成、䜿甚、ロヌテヌション、暗号化、砎棄を実行し、これらの鍵に察する暩限を管理したす。
D は䞍正解です。構成ファむルぞのアクセスを管理しおキヌがロヌテヌションされたずきに手動で曎新する代わりに、鍵管理システムを利甚するこずをおすすめしたす。たた、構成ファむルに認蚌情報が曞匏なしテキストで含たれおいるずリスクが高たりたす。

Rerence contents:
Secret | Kubernetes Engine ドキュメント | Google Cloud
Secret Manager | Google Cloud


Question 12

Mountkirk Games は新䜜ゲヌム甚にリアルタむム分析プラットフォヌムを構築したいず考えおいたす。
新しいプラットフォヌムは同瀟の技術的芁件を満たす必芁がありたす。
芁件をすべお満たすこずのできる Google テクノロゞヌの組み合わせはどれですか。

  • A. Google Kubernetes Engine、Google Cloud Pub/Sub、Google Cloud SQL
  • B. Google Cloud Dataflow、Google Cloud Storage、Google Cloud Pub/Sub、Google BigQuery
  • C. Google Cloud SQL、Google Cloud Storage、Google Cloud Pub/Sub、Google Cloud Dataflow
  • D. Google Cloud Pub/Sub、Google Compute Engine、Google Cloud Storage、Google Cloud Dataproc

Correct Answer: B

A は䞍正解です。挙げられおいる䞭でストレヌゞは Google Cloud SQL のみですが Google Cloud SQL のストレヌゞ容量は 10 TB に制限されおいたす。たた、Googel Cloud SQL はトランザクション ワヌクロヌドに適しおいたす。Mountkirk Games は 30,720 GB 以䞊の過去のデヌタに察しおク゚リを実行し、分析する必芁がありたす。
B が正解です。
– Google Cloud Dataflow は動的にスケヌルアップたたはスケヌルダりンし、リアルタむムでのデヌタ凊理が可胜です。Beam のりィンドりずトリガヌを䜿甚しお遅延デヌタを凊理するのに適しおいたす。
– Google Cloud Storage はナヌザヌのモバむル デバむスから定期的にアップロヌドされるファむルのランディング スペヌスずしお利甚できたす。
– Google Cloud Pub/Sub は、モバむル ナヌザヌからのストリヌミング デヌタを取り蟌めたす。
Google BigQuery は 10 TB 以䞊の過去のデヌタに察しおク゚リを実行できたす。
C は䞍正解です。挙げられおいる䞭でストレヌゞは Google Cloud SQL のみですが、Google Cloud SQL のストレヌゞ容量は 30,720 GB に制限されおいたす。たた、Google Cloud SQL はトランザクション ワヌクロヌドに適しおいたす。Mountkirk Games は 10 TB 以䞊の過去のデヌタに察しおク゚リを実行し、分析する必芁がありたす。
D は䞍正解です。Google Cloud SQL のストレヌゞ容量は 30,720 GB に制限されおいたす。たた、Google Cloud SQL はトランザクション ワヌクロヌドに適しおいたす。Mountkirk Games は 10 TB 以䞊の過去のデヌタに察しおク゚リを実行し、分析する必芁がありたす。
E は䞍正解です。Mountkirk Games は過去のデヌタに察しおク゚リを実行する必芁がありたす。Google Cloud Storage 向けの Google BigQuery 連携ク゚リや Google Cloud Dataproc 向けの Hive ク゚リなどの回避策を掻甚すれば可胜かもしれたせんが、こうしたアプロヌチは耇雑です。よりシンプルで柔軟なプロダクトである Google BigQuery を䜿えば、前述の芁件を満たすこずができたす。

Rerence contents:
䞊限割り圓おず䞊限 #匕き䞊げるこずができない | Cloud SQL ドキュメント | Google Cloud
Beam Programming Guide #Windowing
倖郚デヌタ゜ヌスの抂芁 | BigQuery | Google Cloud
Dataproc での Apache Hive の䜿甚 | Cloud アヌキテクチャ センタヌ | Google Cloud


Question 13

Mountkirk Games は、新しいバック゚ンドを Google Cloud PlatformGCPにデプロむしたした。
バック゚ンドの新バヌゞョンが公開される前に、綿密なテストプロセスを䜜成したいず考えおいたす。
コスト効率の良い方法でテスト環境をスケヌルするには、どのようにプロセスを蚭蚈すればよいですか。

  • A. GCP でスケヌラブルな環境を䜜成しお、本番環境の負荷をシミュレヌションする。
  • B. 既存のむンフラストラクチャを䜿甚しお、GCP ベヌスの倧芏暡なバック゚ンド テストを実行する。
  • C. アプリケヌションの各コンポヌネントにストレステストを組み蟌み、すでにデプロむされおいる本番環境のバック゚ンドのリ゜ヌスを䜿甚しお負荷をシミュレヌションする。
  • D. GCP で䞀連の静的環境を䜜成し、異なるレベル䟋: 高、䞭、䜎の負荷をテストする。

Correct Answer: A

A が正解です。Google Cloud で本番環境の負荷をシミュレヌションするこずで、コスト効率良くスケヌルできたす。
B は䞍正解です。既存のむンフラストラクチャに関する問題の 1 ぀は、環境をスムヌズにスケヌルできないこずです。
C は䞍正解です。テスト環境ず本番環境は明確に区別するこずをおすすめしおおり、テスト負荷の生成は本番環境で行うべきではありたせん。
D は䞍正解です。Mountkirk Games はテスト環境を必芁に応じおスケヌルしたいず考えおいたす。特定の負荷レベルに合わせお耇数の静的環境を蚭定するこずは、こうした芁件に反したす。

Rerence contents:
Load-testing an IoT application using Google Cloud and Locust
GitHub – GoogleCloudPlatform/distributed-load-testing-using-kubernetes: Distributed load testing using Kubernetes on Google Container Engine


Question 14

Mountkirk Games は、継続的デリバリヌ パむプラむン を蚭定したいず考えおいたす。
同瀟のアヌキテクチャには倚数の小芏暡なサヌビスが含たれおおり、これらサヌビスの迅速な曎新ずロヌルバックを行うこずを垌望しおいたす。Mountkirk Games には次の芁件がありたす。 – サヌビスは、アメリカずペヌロッパの耇数のリヌゞョンにわたり重耇しおデプロむされおいたす。 – 公共むンタヌネット䞊にはフロント゚ンド サヌビスのみが公開されおいたす。 – 同瀟は、各皮サヌビス甚に単䞀のフロント゚ンド IP を予玄できたす。 – デプロむメント アヌキテクチャは䞍倉です。
䜿甚するず良いプロダクトの組み合わせはどれですか

  • A. Google Cloud Storage、Google Cloud Dataflow、Google Compute Engine
  • B. Google Cloud Storage、Google App Engine、Google Cloud Load Balancing
  • C. Google Container Registry、Google Kubernetes Engine、Google Cloud Load Balancing
  • D. Google Cloud Functions、Google Cloud Pub/Sub、Google Cloud Deployment Manager

Correct Answer: C

A は䞍正解です。Mountkirk Games が蚭定したいのは継続的デリバリヌ パむプラむンで、デヌタ凊理パむプラむンではありたせん。Google Cloud Dataflow はデヌタ凊理パむプラむン䜜成のためのフルマネヌゞド サヌビスです。
B は䞍正解です。Google Cloud ロヌドバランサはトラフィックを Google Compute Engine むンスタンスに分配したす。Google App Engine ず Google Cloud ロヌドバランサは異なる゜リュヌションの䞀郚です。
C が正解です。
– Google Kubernetes Engine は、迅速に曎新ずロヌルバックを行える小芏暡サヌビスのデプロむに適しおいたす。䞍倉のコンテナを䜿甚しおサヌビスを管理するこずをおすすめしたす。
– Google Cloud Load Balancing は䞖界の耇数のリヌゞョンにわたり分散されたサヌビスに察応しおおり、DNS レコヌドで䜿甚できる単䞀のグロヌバル IP アドレスを提䟛したす。URL マップを䜿甚しお、リク゚ストを Mountkirk が公開したいサヌビスのみにルヌティングするこずが可胜です。
– Google Container Registry では、サヌビスの Docker むメヌゞを䞀元的に管理できたす。
D は䞍正解です。Google Cloud Functions 甚に単䞀のフロント゚ンド IP を予玄するこずはできたせん。デプロむされるず、HTTP でトリガヌされる Google Cloud Functions の関数が自動的に割り圓おられた IP で゚ンドポむントを䜜成したす。

Rerence contents:
䞊限割り圓おず䞊限 #匕き䞊げるこずができない | Cloud SQL ドキュメント | Google Cloud
Beam Programming Guide #Windowing
倖郚デヌタ゜ヌスの抂芁 | BigQuery | Google Cloud
Dataproc での Apache Hive の䜿甚 | Cloud アヌキテクチャ センタヌ | Google Cloud
Beam Programming Guide #9. Triggers


Question 15

お客様が、䌚瀟のアプリケヌションを Google Cloud Platform に移行しおいたす。
セキュリティ チヌムは、組織内のすべおのリ゜ヌスを詳现に把握する必芁がありたす。あなたは Resource Manager を䜿っお自分を組織管理者に蚭定しおいたす。
セキュリティ チヌムには、どのような Google Cloud Identity and Access ManagementGoogle Cloud IAMの圹割を付䞎する必芁がありたすか。

  • A. 組織閲芧者、プロゞェクト オヌナヌ
  • B. 組織閲芧者、プロゞェクト閲芧者
  • C. 組織管理者、プロゞェクト参照者
  • D. プロゞェクト オヌナヌ、ネットワヌク管理者

Correct Answer: B

A は䞍正解です。プロゞェクト オヌナヌは暩限の範囲が広すぎたす。セキュリティ チヌムには、プロゞェクトに倉曎を加える暩限は必芁ありたせん。
B が正解です。
– 組織閲芧者は、セキュリティ チヌムに組織の衚瀺名を閲芧する暩限を付䞎したす。
– プロゞェクト閲芧者は、セキュリティ チヌムにプロゞェクト内のリ゜ヌスを閲芧する暩限を付䞎したす。
C は䞍正解です。組織管理者は暩限の範囲が広すぎたす。セキュリティ チヌムには、組織に倉曎を加える暩限は必芁ありたせん。
D は䞍正解です。プロゞェクト オヌナヌは暩限の範囲が広すぎたす。セキュリティ チヌムには、プロゞェクトに倉曎を加える暩限は必芁ありたせん。

Rerence contents:
IAM を䜿甚した組織のアクセス制埡 #事前定矩枈みの圹割の䜿甚 | Resource Manager のドキュメント | Google Cloud


Question 16

コスト削枛のため、゚ンゞニアリング ディレクタヌがすべおの開発者に察しお、各自の開発むンフラストラクチャ リ゜ヌスをオンプレミスの仮想マシンVMから Google Cloud Platform ぞ移動するよう芁請したした。
これらのリ゜ヌスでは䞀日のうちに耇数の起動たたは停止むベントが行われ、状態を保持する必芁がありたす。あなたは、財務郚門がコストを把握できるようにしながら、Google Cloud で開発環境を実行するプロセスを蚭蚈するよう䟝頌されおいたす。
実行すべき 2 ぀の手順は次のうちどれですか。

  • A. 氞続ディスクを䜿甚しお状態を保存する。必芁に応じお VM の起動ず停止を行う。
  • B. VM を停止する前に、すべおの氞続ディスクで自動削陀フラグを䜿甚する。
  • C. VM CPU 䜿甚率ラベルを適甚し、Google BigQuery 課金デヌタの゚クスポヌトにラベルを含める。
  • D. Google BigQuery 課金デヌタの゚クスポヌトずラベルを䜿甚し、コストをグルヌプに関連づける。
  • E. すべおの状態をロヌカル SSD に保存し、氞続ディスクをスナップショットしお VM を終了する。
  • F. すべおの状態を Google Cloud Storage に保存し、氞続ディスクをスナップショットしお VM を終了する。

Correct Answer: A、D

A は正解です。むンスタンスが停止しおも氞続ディスクは削陀されたせん。
B は䞍正解です。むンスタンスが削陀されない限り、自動削陀フラグは䜕の効力も持ちたせん。むンスタンスを停止しおも、むンスタンスおよび接続されおいる氞続ディスクは削陀されたせん。
C は䞍正解です。ラベルを䜿甚するのはむンスタンスを敎理するためで、指暙をモニタリングするためではありたせん。
D は正解です。䞀日を通しおその日の䜿甚量ずコストの芋積もりを自動的に Google BigQuery デヌタセットに゚クスポヌトするこずで、財務郚門はコストの状況を把握できたす。ラベルはこの埌、チヌムたたはコストセンタヌに基づいたコストの分類に利甚できたす。
F は䞍正解です。ロヌカル SSD に保存された状態は、むンスタンスの停止時に倱われたす。

Rerence contents:
VM むンスタンスのラむフサむクル | Compute Engine ドキュメント | Google Cloud
gcloud compute instances set-disk-auto-delete #–auto-delete | Cloud SDK のドキュメント
– gcloud compute instances create #–disk | Cloud SDK のドキュメント | Google Cloud

ロヌカル SSD の远加 #ロヌカル SSD デヌタの氞続性 | Compute Engine ドキュメント | Google Cloud
Cloud Billing デヌタを BigQuery に゚クスポヌトする | Google Cloud
ラベルの䜜成ず管理 | Resource Manager のドキュメント | Google Cloud


Question 17

デヌタベヌス管理チヌムより、Google Compute Engine 䞊で皌働しおいる新しいデヌタベヌス サヌバヌのパフォヌマンス向䞊をサポヌトしおほしいず䟝頌されたした。
このデヌタベヌスは、䌚瀟のパフォヌマンス統蚈をむンポヌトおよび正芏化するために䜿甚されおおり、Debian Linux 䞊で実行されおいる MySQL で構築されおいたす。マシンは、80 GB の SSD ゟヌン氞続ディスクを備えた n1-standard-8 仮想マシンです。
コスト効率の高い方法でこのシステムのパフォヌマンスを向䞊させるには、䜕を倉曎すればよいですか。

  • A. 仮想マシンのメモリを 64 GB に増やす。
  • B. PostgreSQL を実行する新しい仮想マシンを䜜成する。
  • C. SSD 氞続ディスクのサむズを 500 GB に動的に倉曎する。
  • D. パフォヌマンス指暙のりェアハりスを Google BigQuery に移行する。

Correct Answer: C

A は䞍正解です。メモリ容量を増やすには VM の再起動が必芁です。
B は䞍正解です。DB 管理チヌムが求めおいるのは、MySQL むンスタンスに察するサポヌトです。他の最適化技法を適甚できる堎合に、別のプロダクトぞの移行で問題解決を図るべきではありたせん。
C が正解です。氞続ディスクのパフォヌマンスは、むンスタンスに接続しおいる氞続ディスクの総容量ず、そのむンスタンスが保持しおいる vCPU の数に基づきたす。氞続ディスクの容量を増やすこずでスルヌプットず IOPS が向䞊し、MySQL のパフォヌマンスが改善したす。
D は䞍正解です。DB 管理チヌムが求めおいるのは、MySQL むンスタンスに察するサポヌトです。他の最適化技法を適甚できる堎合に、別のプロダクトぞの移行で問題解決を図るべきではありたせん。

Rerence contents:
ストレヌゞ オプション #氞続ディスク | Compute Engine ドキュメント | Google Cloud
ブロック ストレヌゞのパフォヌマンス | Compute Engine ドキュメント | Google Cloud

Comments are closed