ケーススタディ -
これはケーススタディです。ケーススタディは個別に時間が設定されるわけではありません。各ケースを完了したいだけ試験時間を費やすことができます。ただし、この試験には追加のケーススタディやセクションが存在する場合があります。この試験に含まれるすべての質問を指定された時間内に完了できるように時間を管理する必要があります。
ケーススタディに含まれる質問に答えるには、ケーススタディで提供される情報を参照する必要があります。ケース スタディには、ケース スタディで説明されているシナリオに関する詳細情報を提供する展示やその他のリソースが含まれる場合があります。このケーススタディでは、各質問は他の質問から独立しています。
このケーススタディの最後に、レビュー画面が表示されます。この画面では、試験の次のセクションに進む前に、回答を確認し、変更を加えることができます。新しいセクションを開始した後は、このセクションに戻ることはできません。
ケーススタディを開始するには -
このケーススタディの最初の質問を表示するには、「次へ」ボタンをクリックします。質問に答える前に、左側のペインのボタンを使用してケーススタディの内容を調べてください。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題の説明などの情報が表示されます。ケーススタディに [すべての情報] タブがある場合、表示される情報は後続のタブに表示される情報と同じであることに注意してください。質問に答える準備ができたら、「質問」ボタンをクリックして質問に戻ります。
会社概要 -
HipLocal は、近くにいる人々の間のコミュニケーションを促進するように設計されたコミュニティ アプリケーションです。スポーツイベントの企画や開催、企業が地域社会とつながるために利用されています。 HipLocal は最近ダラスのいくつかの地域でサービスを開始し、急速に世界的な現象に成長しています。ハイパーローカルなコミュニティコミュニケーションとビジネスアウトリーチのユニークなスタイルは、世界中で需要があります。
エグゼクティブステートメント -
私たちはナンバーワンのローカルコミュニティアプリです。地域コミュニティ サービスをグローバルに展開する時が来ました。私たちのベンチャー キャピタルの投資家は、メンバーが互いに 10 マイルまたは 10,000 マイル離れていても、急速な成長と、オンラインになる新しいローカル コミュニティや仮想コミュニティに同様の素晴らしい体験を提供したいと考えています。
ソリューションコンセプト -
HipLocal は、世界中の顧客により良いサービスを提供するために、最新の機能を備えた既存のサービスを新しい地域で拡張したいと考えています。彼らは、これらの地域をタイムゾーンでサポートするための新しいチームを雇用してトレーニングしたいと考えています。アプリケーションがスムーズに拡張され、明確な稼働時間データが提供されることを確認し、発生した問題を分析して対応する必要があります。
既存の技術環境 -
HipLocal の環境は、オンプレミスのハードウェアと Google Cloud Platform で実行されるインフラストラクチャが混在しています。 HipLocal チームはアプリケーションをよく理解していますが、世界規模のアプリケーションの経験は限られています。現在の技術環境は次のとおりです。
• 既存の API は、GCP でホストされている Compute Engine 仮想マシン インスタンス上で実行されます。
• 状態は、GCP の単一インスタンスの MySQL データベースに保存されます。
• リリース サイクルには、QA テストを可能にする開発の凍結が含まれます。
• アプリケーションにはログが記録されません。
• アプリケーションは、平日の夕方のトラフィックが少ない時間帯に、インフラストラクチャ エンジニアによって手動で展開されます。
• 稼働時間の基本的な指標があります。 API が応答しない場合、アラートが頻繁に発生します。
ビジネス要件 -
HipLocal の投資家は、事業展開を拡大し、見られる需要の増加をサポートしたいと考えています。彼らの要件は次のとおりです。
• アプリケーションの利用可能性を新しい地域に拡大します。
• 10 倍の同時ユーザーをサポートします。
• ユーザーが異なる地域に旅行する場合でも、一貫したエクスペリエンスを確保します。
• ユーザーアクティビティの指標を取得して、製品を収益化する方法をより深く理解します。
• 新しい地域の規制 (GDPR など) への準拠を確保します。
• インフラストラクチャ管理の時間とコストを削減します。
• Google が推奨するクラウド コンピューティングのプラクティスを採用します。
○ アプリケーションのライフサイクル管理に関する標準化されたワークフローとプロセスを開発します。
○ サービス レベル指標 (SLI) とサービス レベル目標 (SLO) を定義します。
技術的要件 -
• オンプレミスのデータセンターとクラウドでホストされているアプリケーションおよびインフラストラクチャの間で安全な通信を提供します。
• アプリケーションは使用状況のメトリクスと監視を提供する必要があります。
• API には認証と認可が必要です。
• 新しい機能のより迅速かつ正確な検証を実装します。
• ロギングとパフォーマンスのメトリクスは、デバッグ情報とアラートを提供できるように実用的な情報を提供する必要があります。
• ユーザーの需要に合わせて拡張する必要があります。
この質問については、HipLocal のケーススタディを参照してください。
HipLocal のアプリケーションは、Cloud クライアント ライブラリを使用して Google Cloud と対話します。 HipLocal は、アプリケーションに最小特権アクセスを実装するために、クラウド クライアント ライブラリで認証と認可を構成する必要があります。彼らは何をすべきでしょうか？
-
A.
APIキーを作成します。 API キーを使用して Google Cloud とやり取りします。
-
B.
デフォルトのコンピューティング サービス アカウントを使用して、Google Cloud とやり取りします。
-
C.
アプリケーションのサービス アカウントを作成します。アプリケーションの秘密キーをエクスポートしてデプロイします。サービス アカウントを使用して Google Cloud とやり取りします。
-
D.
アプリケーションと、アプリケーションで使用される各 Google Cloud API のサービス アカウントを作成します。アプリケーションで使用される秘密キーをエクスポートして展開します。 1 つの Google Cloud API でサービス アカウントを使用して、Google Cloud と対話します。
Case study -
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an All Information tab, note that the information displayed is identical to the information displayed on the subsequent tabs. When you are ready to answer a question, click the Question button to return to the question.
Company Overview -
HipLocal is a community application designed to facilitate communication between people in close proximity. It is used for event planning and organizing sporting events, and for businesses to connect with their local communities. HipLocal launched recently in a few neighborhoods in Dallas and is rapidly growing into a global phenomenon. Its unique style of hyper-local community communication and business outreach is in demand around the world.
Executive Statement -
We are the number one local community app; it's time to take our local community services global. Our venture capital investors want to see rapid growth and the same great experience for new local and virtual communities that come online, whether their members are 10 or 10000 miles away from each other.
Solution Concept -
HipLocal wants to expand their existing service, with updated functionality, in new regions to better serve their global customers. They want to hire and train a new team to support these regions in their time zones. They will need to ensure that the application scales smoothly and provides clear uptime data, and that they analyze and respond to any issues that occur.
Existing Technical Environment -
HipLocal's environment is a mix of on-premises hardware and infrastructure running in Google Cloud Platform. The HipLocal team understands their application well, but has limited experience in global scale applications. Their existing technical environment is as follows:
• Existing APIs run on Compute Engine virtual machine instances hosted in GCP.
• State is stored in a single instance MySQL database in GCP.
• Release cycles include development freezes to allow for QA testing.
• The application has no logging.
• Applications are manually deployed by infrastructure engineers during periods of slow traffic on weekday evenings.
• There are basic indicators of uptime; alerts are frequently fired when the APIs are unresponsive.
Business Requirements -
HipLocal's investors want to expand their footprint and support the increase in demand they are seeing. Their requirements are:
• Expand availability of the application to new regions.
• Support 10x as many concurrent users.
• Ensure a consistent experience for users when they travel to different regions.
• Obtain user activity metrics to better understand how to monetize their product.
• Ensure compliance with regulations in the new regions (for example, GDPR).
• Reduce infrastructure management time and cost.
• Adopt the Google-recommended practices for cloud computing.
○ Develop standardized workflows and processes around application lifecycle management.
○ Define service level indicators (SLIs) and service level objectives (SLOs).
Technical Requirements -
• Provide secure communications between the on-premises data center and cloud-hosted applications and infrastructure.
• The application must provide usage metrics and monitoring.
• APIs require authentication and authorization.
• Implement faster and more accurate validation of new features.
• Logging and performance metrics must provide actionable information to be able to provide debugging information and alerts.
• Must scale to meet user demand.
For this question, refer to the HipLocal case study.
HipLocal's application uses Cloud Client Libraries to interact with Google Cloud. HipLocal needs to configure authentication and authorization in the Cloud Client Libraries to implement least privileged access for the application. What should they do?
-
A.
Create an API key. Use the API key to interact with Google Cloud.
-
B.
Use the default compute service account to interact with Google Cloud.
-
C.
Create a service account for the application. Export and deploy the private key for the application. Use the service account to interact with Google Cloud.
-
D.
Create a service account for the application and for each Google Cloud API used by the application. Export and deploy the private keys used by the application. Use the service account with one Google Cloud API to interact with Google Cloud.
コメント 1Comment 1
帯域幅（バイナリ形式）が低いため、C（gRPC）の方が優れているのではありませんか？
モバイルアプリで使用でき、HTTP(s)をサポートします。
In't C (gRPC) better because of the lower bandwidth (binary format)?
It can be used in mobile apps and supports HTTP(s)
コメント 1.1Comment 1.1
「モバイル アプリと簡単に統合する」という要件には、おそらく A が最適なソリューションです。
Probably A is the best solution for "Integrate easily with mobile apps" requirement
コメント 2Comment 2
A と C は両方とも適切なソリューションですが、帯域幅コストを最小限に抑えることができるため、C を選択します。
Both A and C are suitable solution but since it reads minimise bandwidth cost, I'd go with C
コメント 3Comment 3
概要を説明した要件を満たすモバイル アプリ向けに設計された API の場合、RESTful API アーキテクチャが最適な選択です。その理由は次のとおりです。
RESTful API の利点:
HTTPs のサポート: REST API は HTTP 上に構築されているため、HTTPS の統合がシームレスになります。
帯域幅の最小化: REST API は、効率的なデータ転送のために設計されています。 CRUD 操作には標準の HTTP メソッド (GET、POST、PUT、DELETE) を使用し、ネットワーク経由で送信されるデータの量を最小限に抑えます。
簡単なモバイル統合: REST API は広く理解されており、モバイル開発フレームワーク (Android の Retrofit や iOS の Alamofire など) によってサポートされています。標準データ形式として JSON が使用されており、モバイル アプリで簡単に解析できます。
For an API designed for mobile apps with the requirements you've outlined, a RESTful API architecture is the most suitable choice. Here's why:
RESTful API Advantages:
HTTPs Support: REST APIs are built on top of HTTP, making HTTPS integration seamless.
Bandwidth Minimization: REST APIs are designed for efficient data transfer. They use standard HTTP methods (GET, POST, PUT, DELETE) for CRUD operations, minimizing the amount of data sent over the network.
Easy Mobile Integration: REST APIs are widely understood and supported by mobile development frameworks (like Android's Retrofit and iOS's Alamofire). They use JSON as a standard data format, which is easily parsed by mobile apps.
コメント 3.1Comment 3.1
他のアーキテクチャが理想的ではない理由:
SOAP: SOAP は HTTPS をサポートしていますが、より複雑で冗長であるため、帯域幅の使用量が増加し、モバイル アプリとの統合がより困難になる可能性があります。
GraphQL: GraphQL は柔軟なデータ取得に優れていますが、実装がより複雑になる可能性があり、モバイル開発フレームワークでは REST ほど広くサポートされていない可能性があります。
帯域幅の最適化に関する追加のヒント:
データ圧縮: gzip 圧縮を使用して、転送されるデータのサイズを削減します。
キャッシュ: サーバー側とクライアント側の両方にキャッシュ メカニズムを実装して、冗長なデータ要求を削減します。
API のバージョニング: バージョン管理を使用して、重大な変更を回避し、段階的な更新を可能にします。
ページネーション: 大規模なデータセットの場合は、ページネーションを実装して、データをより小さなチャンクでフェッチします。
Why Other Architectures Might Not Be Ideal:
SOAP: While SOAP supports HTTPS, it's more complex and verbose, leading to higher bandwidth usage and potentially more difficult integration with mobile apps.
GraphQL: GraphQL is excellent for flexible data fetching, but it can be more complex to implement and might not be as widely supported by mobile development frameworks as REST.
Additional Tips for Bandwidth Optimization:
Data Compression: Use gzip compression to reduce the size of data transferred.
Caching: Implement caching mechanisms on both the server and client sides to reduce redundant data requests.
API Versioning: Use versioning to avoid breaking changes and allow for gradual updates.
Pagination: For large datasets, implement pagination to fetch data in smaller chunks.
コメント 4Comment 4
C. gRPC ベースの API は、効率的で拡張可能な形式で構造化データをシリアル化する方法であるプロトコル バッファーを使用して、帯域幅を最小限に抑えるように設計されています。 gRPC は最新で高速で、デフォルトで HTTPS をサポートします。また、ストリーミングや効率的な接続管理などの機能も提供しており、帯域幅やバッテリー寿命の効率的な使用が必要なモバイル アプリにとって有利です。
C. gRPC-based APIs are designed to minimize bandwidth by using Protocol Buffers, a method of serializing structured data in an efficient and extensible format. gRPC is modern, fast, and supports HTTPS by default. It also provides features like streaming and efficient connection management, which can be advantageous for mobile apps that require efficient use of bandwidth and battery life.
コメント 5Comment 5
gRPC を使用するのは、それが Google プロダクトであり、GCP 試験について話しているためです。
ただし、REST API は依然としてその目的を果たします。
I'm going with gRPC was it is a Google Product, and we're talking about a GCP exam, so...
REST APIs would still serve the purpose though.
コメント 6Comment 6
A、https://www.exam-answer.com/api-architecture-for-android-ios-apps によると
A, according to https://www.exam-answer.com/api-architecture-for-android-ios-apps
コメント 7Comment 7
C は正解です。低遅延で IOS と Android をサポートしています。
C is correct as it supports IOS and Android with low latency.
コメント 8Comment 8
答えは C です。gRPC は、IOS と Android もサポートする、高性能のオープンソースのユニバーサル RPC フレームワークです。
Answer is C: gRPC is a high-performance, open-source universal RPC framework which supports IOS and Android as well.
コメント 9Comment 9
https://www.exam-answer.com/api-architecture-for-android-ios-apps#:~:text=The%20most%20suitable%20API%20architecture,used%20for%20building%20web%20API。
https://www.exam-answer.com/api-architecture-for-android-ios-apps#:~:text=The%20most%20suitable%20API%20architecture,used%20for%20building%20web%20APIs.
コメント 10Comment 10
gRPC ベースの API
gRPC-based APIs
コメント 11Comment 11
gRPC は ios と android もサポートします。
gRPC supports ios and andriod also.
コメント 12Comment 12
正解はCです
The correct is C
コメント 13Comment 13
HTTPS をサポートし、帯域幅コストを最小限に抑え、モバイル アプリと簡単に統合するには、gRPC ベースの API (C) を使用する必要があります。
gRPC (gRPC リモート プロシージャ コール) は、API の構築に使用できる最新の高パフォーマンスのオープンソース リモート プロシージャ コール (RPC) フレームワークです。基盤となるトランスポート プロトコルとして HTTP/2 を使用し、エンコード形式としてプロトコル バッファーを使用します。 gRPC は、低帯域幅、低遅延で、モバイル アプリと簡単に統合できるように設計されています。そのままの状態で HTTPs もサポートします。
RESTful API (A) は API を構築するための一般的な選択肢ですが、特に大量のデータを転送する API の場合、帯域幅の使用量の点で gRPC ほど効率的ではない可能性があります。 MQTT (B) は、IoT アプリケーションでよく使用される軽量のメッセージング プロトコルですが、API の構築には gRPC ほど適していない可能性があります。 SOAP ベースの API (D) は古いスタイルの API であり、gRPC などの最新の代替手段に大部分が置き換えられています。
To support HTTPS, minimize bandwidth cost, and integrate easily with mobile apps, you should use gRPC-based APIs (C).
gRPC (gRPC Remote Procedure Calls) is a modern, high-performance, open-source remote procedure call (RPC) framework that can be used to build APIs. It uses HTTP/2 as the underlying transport protocol and Protocol Buffers as the encoding format. gRPC is designed to be low-bandwidth, low-latency, and easily integrable with mobile apps. It also supports HTTPs out of the box.
RESTful APIs (A) are a popular choice for building APIs, but they may not be as efficient as gRPC in terms of bandwidth usage, especially for APIs that transfer large amounts of data. MQTT (B) is a lightweight messaging protocol that is often used in IoT applications, but it may not be as well-suited for building APIs as gRPC. SOAP-based APIs (D) are an older style of API that has largely been replaced by more modern alternatives like gRPC.
コメント 14Comment 14
最良の答えは C だと思います。
- gRPC は HTTPS をサポートします。
- バイナリペイロードを使用するため、帯域幅を最小限に抑えます。
- 接続の詳細を隠すスタブとスケルトンを生成するため、統合が簡単です。
https://cloud.google.com/blog/products/api-management/ Understanding-grpc-openapi-and-rest-and-when-to-use-them
I think that the best answer is C:
- gRPC supports HTTPS;
- minimize bandwidth because use a binary payload;
- It is easy to integrate because it generate stubs and skeletons that hide the connection details.
https://cloud.google.com/blog/products/api-management/understanding-grpc-openapi-and-rest-and-when-to-use-them
コメント 15Comment 15
REST API はクライアント側のテクノロジーに拘束されません。これにより、クライアント側 Web プロジェクト、iOS アプリ、IoT デバイス、または Windows Phone からこれらの API にアクセスできるようになります。
問題の声明の中で、彼らは iOS と Android について言及しました。
gRPC では正式にサポートされていません
したがって、これはオプション A を指します。そうでない場合は、C が最も近いです。
REST APIs are not bound to client-side technology. This allows you to access these APIs from a client-side web project, iOS app, IoT device, or Windows phone.
In the problem statement, they mentioned iOS and Android.
It is not officially supported by gRPC
So that points to option A, otherwise, C is nearest.
コメント 16Comment 16
Aが正しいです
A is correct
コメント 17Comment 17
合意された選択肢 A は正しいです
Agreed Option A is correct