宣言型のInfrastructure as Code（IaC）は、クラウドネイティブ環境における重要な原則です。プラットフォームチームが段階的な手順ではなく、インフラストラクチャの望ましい状態を定義できるためです。選択肢Aが正解です。宣言型IaCは、「どのように」作成するかではなく、「何」（必要なインフラストラクチャリソースなど）を記述することに重点を置いているためです。Terraform、Pulumi（宣言型モード）、Kubernetesマニフェストなどのツールは、このモデルを体現しています。
選択肢Bは誤りです。宣言型IaCは、調整ループがあるため、動的な環境に特に適しています。選択肢Cは誤解を招きやすいです。命令型メソッドは通常、よりきめ細かい制御を提供しますが、宣言型メソッドはそれを抽象化して簡潔にしています。選択肢Dは誤りです。宣言型IaCは通常、高レベルの抽象化を利用することでコーディングの労力を削減します。
このモデルは、一貫性と再現性のある環境を実現し、管理を簡素化し、GitOpsワークフローと自然に統合します。人的エラーを削減し、プラットフォームが常に望ましいインフラストラクチャ状態を維持することを保証します。
参考資料:- CNCF GitOps の原則- Kubernetes の宣言的管理モデル- クラウドネイティブ プラットフォーム エンジニアリングの学習ガイド

Crossplane は、インフラストラクチャ API を使用して Kubernetes を拡張することで、GitOps ワークフローと緊密に統合されます。
オプションBが正解です。インフラストラクチャリソース（データベース、ネットワーク、S3バケットなど）はGitリポジトリで宣言的に定義されます。Gitが唯一の信頼できる情報源となり、Crossplaneコントローラーがサポート対象のクラウドプロバイダー間で、望ましい状態を実際のインフラストラクチャに自動的に調整します。
オプションAは命令型のスクリプトを反映しており、GitOpsの原則に反しています。オプションC（手動プロビジョニング）は自動化、ガバナンス、そして再現性に欠けています。オプションDはkubectlを使用した手動適用であり、GitOpsの調整ループを回避します。
CrossplaneとGitOpsを活用することで、チームは一貫性、再現性、監査性を備えた大規模なインフラストラクチャプロビジョニングを実現できます。これにより、宣言型管理、セルフサービス、拡張性といったクラウドネイティブプラットフォームエンジニアリングの原則に完全に準拠することが可能になります。
参考資料:- CNCF Crossplane ドキュメント- CNCF GitOps の原則- クラウドネイティブ プラットフォーム エンジニアリング 学習ガイド

ポリシーエンジン（Open Policy Agent（OPA）やKyvernoなど）は、クラウドネイティブプラットフォーム全体にわたってガバナンス、セキュリティ、コンプライアンスを一貫して適用する上で重要な役割を果たします。選択肢Dが正解です。ポリシーエンジンは、クラスター、サービス、環境全体に適用できる、一元化された再利用可能なポリシーを提供します。これにより、開発者はこれらの制御を手動で管理することなく、コンプライアンスに準拠した安全な方法でプラットフォームサービスを利用できます。
選択肢Aは部分的に正しいものの、ポリシーの範囲が狭すぎます。ポリシーはコンプライアンスだけでなく、運用、セキュリティ、コスト管理といった対策も対象としているからです。選択肢Bはポリシーエンジンの主な機能ではありませんが、CI/CDとの統合は可能です。選択肢Cは誤りです。SLAはビジネス契約であり、ポリシーエンジンによって直接適用されるものではありません。
ポリシー エンジンは、イメージ署名、RBAC ルール、リソース クォータ、ネットワーク ポリシーなどのガードレールを自動的に適用し、開発者の認知負荷を軽減するとともに、プラットフォーム チームにコンプライアンスに対する自信を与えます。
これは、セルフサービスとガバナンスを組み合わせるというプラットフォーム エンジニアリングの原則をサポートします。
参考資料:- CNCF プラットフォームホワイトペーパー- CNCF セキュリティ TAG (OPA、Kyverno)- クラウドネイティブプラットフォームエンジニアリング学習ガイド

プラットフォームエンジニアリングアプローチの主な利点は、開発者のセルフサービスと組織のガバナンスおよび標準化のバランスをとれることです。選択肢Aは正解です。プラットフォームは、開発者がセキュリティ、コンプライアンス、運用上のガードレールを組み込みながら、インフラストラクチャとアプリケーション環境を個別にプロビジョニングすることを可能にするためです。これにより、多様なニーズ（異なるスケーリングパターン、コンプライアンス要件、環境など）を持つアプリケーションでも、統一されたガバナンスフレームワーク内で運用できるようになります。
オプションB（分離のみ）はコンプライアンス上必要な場合もありますが、柔軟性と標準化のバランスというより広範なメリットには対応していません。オプションCは統一性を強制するため、多様なワークロードへの適応性が低下します。オプションD（集中型デプロイメント）は、開発者の自律性とスケーラビリティを低下させます。
プラットフォームアプローチは、ゴールデンパス、キュレーションされた抽象化、そして再利用可能なサービスを可能にし、多様なアプリケーションが制御を維持しながら発展することを可能にします。このバランスは、認知負荷を軽減し、開発者の生産性を向上させるというプラットフォームエンジニアリングの目標の中核を成しています。
参考資料:- CNCF プラットフォームホワイトペーパー- CNCF プラットフォームエンジニアリング成熟度モデル- クラウドネイティブプラットフォームエンジニアリング学習ガイド

プラットフォーム導入の成功は、コラボレーションと継続的な改善を促進する文化的慣習に大きく依存します。選択肢Dは正解です。開発者とプラットフォームチーム間のフィードバックループにより、セキュリティとガバナンスのバランスを取りながら、開発者のニーズに合わせてプラットフォームが進化していくことが保証されます。これは、プラットフォームを製品として扱い、開発者エクスペリエンスを最優先するという原則と一致しています。
オプションA（義務化）は、多くの場合、抵抗やシャドーITにつながります。オプションBはプラットフォームチームを孤立させ、サイロ化を引き起こし、開発者ワークフローとの連携を阻害します。オプションCは誤解を招きやすいものです。セキュリティは重要ですが、それを過度に強調しすぎてユーザビリティを犠牲にすると、導入が妨げられます。
フィードバック主導のイテレーションは、信頼を築き、ユーザビリティを向上させ、有機的な採用を促進します。これにより、プラットフォームは、開発者が強制的に導入するのではなく、使いたいと思う価値ある製品へと変化します。
参考資料:- CNCF プラットフォームのホワイトペーパー- チームトポロジ (Platform as a Product モデル)- クラウドネイティブ プラットフォーム エンジニアリング スタディガイド