これは、ブロック内で指定された設定を使用してインフラストラクチャ オブジェクトを作成する種類の構成ブロックです。その他のオプションは、インフラストラクチャ オブジェクトの作成には使用されませんが、プロバイダーの構成、状態データへのアクセス、またはデータ ソースのクエリに使用されます。

これは、for_each 引数を使用してコレクション値を反復処理し、各要素のネストされたブロックを生成することにより、ネストされた構成ブロックのコレクションを構築するために使用されるブロックのタイプです。たとえば、動的ブロックを使用して、セキュリティ グループ リソースに対して複数のイングレス ルールを作成できます。

Terraform の状態は、Terraform が管理するインフラストラクチャの表現です。Terraform は状態を使用して、作成するリソースの現在の状態を追跡し、将来の変更を計画します。ただし、Terraform の状態は、Azure Cloud Console、Azure CLI、Azure API など、Terraform の外部でリソースに加えられた変更を認識しません。そのため、Azure Cloud Console 経由でリソースを変更しても、現在の状態ファイルは更新されず、Terraform の目的の構成との不整合や競合が発生する可能性があります。これを回避するには、リソースを Terraform のみで管理するか、terraform import コマンドを使用して既存のリソースを Terraform の制御下に置くことをお勧めします。
Azure Cloud Console から Terraform 管理対象リソースを変更した場合、Terraform は変更を反映するためにすぐに状態ファイルを更新しません。ただし、次回 terraform plan または terraform apply を実行すると、Terraform は状態ファイルを Azure のリソースの実際の状態と比較し、ずれや相違を検出します。次に、Terraform はリソースの現在の状態と一致するように状態ファイルを更新し、実行プランで提案された変更を表示します。構成と変更に応じて、Terraform は変更を元に戻したり、リソースをさらに変更したり、リソースを完全に再作成したりすることがあります。予期しない変更や破壊的な変更を回避するには、実行プランを適用する前に慎重に確認するか、terraform refresh コマンドを使用して変更を適用せずに状態ファイルを更新することをお勧めします。
参照 = Terraform State の目的、Terraform State、状態の管理、インフラストラクチャのインポート、
[コマンド: plan]、[コマンド: apply]、[コマンド: refresh]

構成で別のファイル名または場所を指定しない限り、デフォルトでは、Terraform ローカル バックエンドが状態を保存する場所です。ローカル バックエンドは、状態ファイルをローカル ディスクに保存する最も単純なバックエンド タイプです。

これは、パブリッククラウド リソースをプロビジョニングするための標準的な方法として AWS CloudFormation を採用する場合に、このチームにとって課題となるシナリオです。CloudFormation は AWS のサービスとリソースのみをサポートしており、Azure などの他のクラウド プラットフォーム上のインフラストラクチャのプロビジョニングには使用できません。