正解は次のとおりです。「自己署名証明書とそれに対応するキーを作成します。証明書とキーを使用して Kubernetes シークレットを作成します。次に、これらのアノテーションを Kubernetes サービスに追加します。 annotations:service.beta.kubernetes.io/oci-load -balancer-ssl-ports: '443' service.beta.kubernetes.io/oci-load-balancer-tls-secret: ssl 証明書シークレット。」OCI Container Engine for Kubernetes (OKE) クラスタで実行されているマイクロサービスベースのアプリケーションに対して安全な SSL 終端を作成するには、次の手順を実行できます。 自己署名証明書とそれに対応するキーを作成します。 自己署名 SSL 証明書を生成し、 OpenSSL などのツールを使用して秘密キーを取得します。Kubernetes シークレットの作成: 前の手順で取得した証明書とキーを使用して Kubernetes シークレットを作成します。このシークレットは、証明書とキーを Kubernetes クラスター内に安全に保存します。Kubernetes サービスにアノテーションを追加します。アプリケーションを公開する Kubernetes サービスを変更し、次のアノテーションを追加して SSL 終了を有効にします。 annotations: service.beta.kubernetes.io/oci-load-balancer-ssl-ports: '443' (指定します) SSL ポートは 443) アノテーション:service.beta.kubernetes.io/oci-load-balancer-tls-secret:sslcertificate-secret (証明書とキーを含む Kubernetes シークレットの名前を指定) 次の手順に従うことで、自己署名証明書と Kubernetes シークレットを使用して、アプリケーションの安全な SSL 終端を作成できます。Kubernetes サービスに追加されたアノテーションにより、SSL ポートが正しく構成され、トラフィックがロード バランサーに到達したときに SSL 終了に TLS シークレットが使用されることが保証されます。提供されている他のオプションは、OCI Container Engine for Kubernetes (OKE) クラスタで安全な SSL 終了を実現するための最適なアプローチではありません。OCI ロード バランサの SSL 秘密キーに関連するアノテーションの追加は、このシナリオでの SSL 終了の正しいアプローチではありません。Kubernetes シークレットを使用して Kubernetes クラスター内で SSL 証明書を作成および管理できる場合、Let's Encrypt を使用して自己署名証明書を生成し、それを OCI ロード バランサーで構成する必要はありません。

説明
kubectl のローカル インストールを使用して Container Engine for Kubernetes (OKE) クラスター アクセスを設定する場合に必要ない手順は、OCI コンソールから認証トークンを生成することです。kubectl を使用して OKE クラスターにアクセスするための認証は、OCI CLI 構成、特に API 署名キー ペアと kubeconfig ファイルを使用して実行できます。kubectl のローカル インストールを使用して OKE クラスター アクセスをセットアップするための正しい手順は次のとおりです。 kubeconfig ファイルのセットアップ: kubeconfig ファイルには、kubectl を使用して OKE クラスターを認証しアクセスするために必要な情報が含まれています。これには、クラスターのエンドポイント、認証方法、資格情報などの詳細が含まれます。API 署名キー ペアを生成し (まだ持っていない場合)、API 署名キー ペアの公開キーをアップロードします。 API 署名キー ペアは、OCI サービスでの認証に使用されます。キー ペアの公開キーを OCI コンソールにアップロードして、ユーザー アカウントに関連付ける必要があります。Oracle Cloud Infrastructure (OCI) CLIのインストールと構成: OCI CLIは、OCIサービスと対話するためのコマンドライン・インタフェースを提供します。ユーザーのOCID、テナンシーOCID、リージョン、API署名キー・ペアへのパスなどのOCI資格証明を使用してインストールおよび構成する必要があります。これらの手順を完了すると、OCI CLI 認証構成を使用してローカル マシンから OKE クラスターにアクセスして管理するように kubectl を構成できます。

正解は「サービスメッシュ」です。サービス メッシュは、マイクロサービスのネットワーク間の対話を制御する、構成可能な低遅延のインフラストラクチャ層です。マイクロサービスベースのアプリケーションに対して、サービス検出、負荷分散、トラフィック管理、セキュリティ、可観測性などの機能を提供します。これは、通信を改善し、分散システム内のサービス間の複雑な相互作用を管理するように設計されています。Istio や Linkerd などのサービス メッシュ フレームワークは、サービス メッシュ アーキテクチャの実装によく使用されます。

正解は、「一度ローテーションされると、削除されるまで古いバージョンの鍵を暗号化に使用できます。」です。OCI Vault サービスでのキーのローテーションに関して無効なステートメントは、「一度ローテーションすると、古いキー バージョンは削除されるまで暗号化に使用できます。」です。OCI Vault サービスでは、マスター暗号化キー (MEK) をローテーションすると、新しいキー バージョンが自動的に生成されます。ただし、キーがローテーションされて新しいバージョンが作成されると、古いキー バージョンは暗号化に使用できなくなります。キーのローテーションの目的は、暗号化キーが定期的に更新され、機密データの保護に古いキーが使用されないようにすることです。これにより、潜在的なキー侵害の影響が最小限に抑えられ、セキュリティが強化されます。言及されている他のステートメントは有効です。ソフトウェアおよびハードウェア セキュリティ モジュール (HSM) で保護された MEK は両方ともローテーションできます。これにより、MEK のタイプを柔軟に選択できるようになり、使用される暗号化方式に関係なくキーのローテーションを実行できるようになります。各キーのバージョンは、個別の一意の OCID (Oracle Cloud Identifier) を使用して内部的に追跡されます。これにより、OCI Vault サービス内のさまざまなキー バージョンの管理と追跡が容易になります。要約すると、無効なステートメントは、古いキー バージョンが削除されるまで暗号化に引き続き使用できることを示唆するステートメントです。キーのローテーションは、最新のキー バージョンを確実に使用し、古いキー バージョンを廃止してセキュリティを強化するように設計されています。

正解は、「Docker CLI から呼び出す」です。Oracle Functionsにデプロイされた関数の実行は、通常、次のオプションを使用して実行されます。 Fn Project CLIからの起動: Fn Project CLIは、Oracle Functionsと対話するために特別に設計されたコマンドライン・インタフェースを提供します。fn invoke などのコマンドを使用して関数を呼び出すことができます。Oracle Cloud Infrastructure (OCI)イベント・サービスのイベントによるトリガー: OCIでイベントを構成し、オブジェクト・ストレージ・イベント、リソース状態の変更、スケジュールされたイベントなどのさまざまな基準に基づいて関数をトリガーできます。OCI CLIからの起動: OCI CLI (コマンドライン・インタフェース)を使用すると、Oracle Functionsを含むOracle Cloud Infrastructureのさまざまなサービスと対話できます。fn invoke コマンドを使用して関数を呼び出すことができます。署名された HTTP リクエストを関数の呼び出しエンドポイントに送信します。Oracle Functions は、関数の呼び出しに使用できる HTTP エンドポイントを提供します。HTTP リクエストの作成をサポートするツールまたはプログラミング言語を使用して、署名付き HTTP リクエストをこのエンドポイントに送信できます。一方、Docker CLI を使用して Oracle Functions にデプロイされた関数を呼び出すことは有効なオプションではありません。Docker CLI は主に Docker コンテナとイメージの管理に使用され、Oracle Functions の関数を呼び出すための直接メカニズムは提供しません。