説明
特定のシナリオでは、開発者はトークンベースの承認を使用して承認者関数を作成するアプローチを使用する必要があります。トークンベースの認可は、API リクエストを認証するために一般的に使用されるアプローチです。これには、トークンの生成と API 呼び出し元への発行が含まれ、API 呼び出し元はそのトークンを API へのリクエストに含めることができます。トークンは認証の証拠として機能し、呼び出し元の ID とアクセス権を保証するためにサーバーによって検証されます。トークンベースの認可を使用して認可関数を作成することにより、開発者は API 呼び出し元から文字列ベースのパラメータを受け入れるカスタム スキームを実装できます。これにより、開発者は独自の認証ロジックを定義し、要件に従って提供されたトークンを検証できます。オーソライザー関数は、リクエストをWebアプリケーションに転送する前に呼び出されるようにOCI API Gatewayで構成できます。必要なトークンの検証と認証チェックを実行し、承認されたリクエストのみが Web アプリケーションの保護されたリソースにアクセスできるようにします。

正解は「複数のマイクロサービスを 1 つのプロセスで実行できる」です。マイクロサービスに関する間違いは、「複数のマイクロサービスを 1 つのプロセスで実行できる」です。マイクロサービスは、個別にデプロイ、スケーリング、管理できる独立した自律的なサービスになるように設計されています。通常、各マイクロサービスは独自の個別のプロセスとして実行されます。この分離により、個々のサービスの疎結合と独立したスケーラビリティが可能になります。単一のプロセスで複数のマイクロサービスを実行すると、サービスの分離と独立性を重視するマイクロサービス アーキテクチャの基本原則に違反します。複数のマイクロサービスを 1 つのプロセスに結合すると、それらが密に結合されるため、各サービスを個別に管理、拡張、更新することが困難になります。提供されている他のステートメントは、マイクロサービスに関して当てはまります。マイクロサービスが HTTP と通信するのは非常に一般的です。マイクロサービスは、HTTP/REST などの軽量プロトコルを使用して相互に通信することがよくあります。これにより、相互運用性、柔軟性、マイクロサービス間の通信が容易になります。マイクロサービスは通常、ビジネス機能を中心に設計されます。マイクロサービス アーキテクチャは、特定のビジネス機能または機能に基づいてサービスを設計することを推奨します。各マイクロサービスは特定のビジネス ドメインまたはタスクに焦点を当てており、モジュール式でスケーラブルな開発を可能にします。独立してデプロイ可能: マイクロサービスは、独立してデプロイ可能なユニットになるように設計されています。これは、他のサービスに影響を与えることなく、各マイクロサービスを個別に開発、テスト、デプロイ、更新できることを意味します。この柔軟性により、開発サイクルの短縮とより効率的なスケーラビリティが可能になります。

説明
ローリング アップデートは、ダウンタイムなしでアプリケーションの古いバージョンを新しいバージョンに徐々に置き換える展開戦略です4。OKE は、kubectl rollout コマンドを使用したローリング アップデートをサポートしています4。ローリング アップデートでは、新しいバージョンで問題が発生した場合に、以前のバージョンにロールバックできます4。
したがって、kubectlでローリング更新戦略を使用すると、新しいイメージがデプロイ後に機能しなくなった場合でも、確実にPythonアプリケーションの前のバージョンにロールバックできます。

説明
Oracle Functionsは現在、関数コードを記述するための言語としてPL/SQLをサポートしていません。PL/SQLは、Oracle Databaseでストアド・プロシージャ、トリガーおよびその他のデータベース関連コードを開発するために使用される手続き型言語です。ただし、Oracle Functionsは、Go、Node.js、Python、Javaなど、他のいくつかの一般的なプログラミング言語をサポートしているため、開発者はアプリケーションの要件や言語の習熟度に最も適した言語を選択できます。PL/SQL は Oracle データベースの操作には強力ですが、Oracle Functions サーバーレス アーキテクチャで関数コードを作成する場合はオプションではありません。

正解は「密結合」です。密結合は、マイクロサービスが通常満たす基準ではありません。実際、マイクロサービスは疎結合になるように設計されています。疎結合とは、依存関係を減らし、異なるコンポーネントまたはサービス間の直接の相互作用を最小限に抑えることを指します。マイクロサービスは独立性と自律性を促進し、各サービスが他のサービスに強く束縛されることなく独立して動作できるようにします。リストされている他のオプションは、マイクロサービスによって通常満たされる基準です。 ビジネス機能を中心に編成: マイクロサービス アーキテクチャは、特定のビジネス機能または機能を中心にサービスを設計することを提案します。これにより、組織のビジネス ニーズに合わせた、集中的で専門的なサービスが可能になります。独立してデプロイ可能: マイクロサービスは、独立してデプロイ可能なユニットになるように設計されています。各マイクロサービスは、他のサービスに影響を与えることなく、個別に開発、テスト、デプロイできます。これにより、展開プロセスの俊敏性と拡張性が可能になります。高度な保守性: マイクロサービスは多くの場合、高度な保守性を実現するように設計されています。これらは範囲が小さく、特定のタスクに焦点を当てているため、個々のサービスの管理と維持が容易になります。さらに、システム全体に影響を与えることなくマイクロサービスを更新、パッチ適用、または交換できるため、アプリケーションのメンテナンスと進化が容易になります。したがって、マイクロサービスが通常満たさない基準は密結合されています。