説明
モジュールは、入力変数を明示的に宣言し、親モジュールの引数から値を割り当てる必要があるため、親モジュールで宣言されたすべての変数を常に参照できるわけではありません。モジュールは、入力引数として渡されない限り、親モジュールの変数に直接アクセスすることはできません。

説明
required_providers ブロックは、構成が使用できるプロバイダーのバージョンを指定するために使用されます。
バージョン引数は、二重引用符で囲む必要があるバージョン制約文字列を受け入れます。バージョン制約文字列では、>=、~>、= などの演算子を使用して、プロバイダーの最小バージョン、最大バージョン、または正確なバージョンを指定できます。たとえば、version = ">= 3.1" は、構成が 3.1 以上の任意のプロバイダー バージョンで機能することを意味します。参照 = [プロバイダーの要件] および [バージョン制約]

セキュア文字列は、Terraform 設定ファイルからシークレットを除外するための有効なオプションではありません。セキュア文字列は、KMS キーで暗号化された機密データを保存できる AWS Systems Manager パラメータストアの機能です。ただし、Terraform はセキュア文字列をネイティブでサポートしておらず、それらを取得するにはカスタムデータソースが必要です。その他のオプションは、Terraform 設定ファイルからシークレットを除外するための有効な方法です。Terraform プロバイダーは、設定で参照できるデータソースとしてシークレットを公開できます。環境変数を使用して、シークレットを含む入力変数の値を設定できます。-var フラグを使用して、コマンドラインまたはファイルからシークレットを含む入力変数の値を渡すことができます。参照 = [AWS Systems Manager パラメータストア]、[Terraform AWS プロバイダーの問題 #55]、[Terraform プロバイダー]、[Terraform 入力変数]

説明
選択肢に挙げられていない Infrastructure as Code の重要な原則は、ゴールデン イメージです。ゴールデン イメージは、特定のソフトウェアと構成のセットを含む、事前構成済みのすぐに使用できる仮想マシン イメージです。テストや本番環境など、同じ環境の複数の同一インスタンスを作成するためによく使用されます。ただし、ゴールデン イメージは Infrastructure as Code の原則ではなく、Infrastructure as Code の有無にかかわらず使用できる手法です。その他の選択肢はすべて、以下に説明する Infrastructure as Code の重要な原則です。
自己記述型インフラストラクチャ: これは、インフラストラクチャが、それを作成する手順を記述するスクリプトではなく、望ましい状態を記述するコードで定義されることを意味します。これにより、インフラストラクチャの理解、保守、再現が容易になります。
べき等性: これは、同じインフラストラクチャ コードを複数回適用すると、初期状態に関係なく、常に同じ状態になることを意味します。これにより、インフラストラクチャの一貫性と予測可能性が高まり、繰り返しのアクションによって発生するエラーや競合を回避できます。
バージョン管理されたインフラストラクチャ: これは、インフラストラクチャ コードが Git などのバージョン管理システムに保存され、コードの変更と履歴を追跡することを意味します。これにより、インフラストラクチャ コードは再利用、監査、共同作業が可能になり、分岐、マージ、ロールバックなどのプラクティスが可能になります。参考文献
= [Terraform を使用した Infrastructure as Code の概要]、[プライベート クラウドまたはパブリック クラウドでの Infrastructure as Code]

説明
Terraform によって削除されるすべてのリソースを表示するには、次の 2 つのコマンドのいずれかを使用します。
terraform destroy は破棄の計画を表示し、続行する前に確認を求めます。
リソースを破棄したくない場合は、コマンドをキャンセルできます。
terraform plan -destroy は、確認を求めずに破棄の計画を表示します。このコマンドを使用して、terraform destroy を実行する前に変更を確認できます。参照 = : インフラストラクチャの破棄 : 計画コマンド: オプション