Terraform/OpenTofu Guide

Terraform and OpenTofu can call Cloud Adapter through an origin cloud provider. Cloud Adapter is not a Terraform provider: it implements the supported cloud API operations that the provider calls. This walkthrough uses the AWS provider and one S3 object. It deliberately reuses an existing test bucket so the first test exercises a small data-plane lifecycle instead of bucket provisioning, account discovery, policy, and tagging all at once.

What this test proves

A successful run proves that the selected provider version can use the endpoint and that the exact create, read, refresh, and delete operations in this configuration work for the selected target. It does not prove that every AWS resource, every S3 feature, import, drift recovery, or backend migration works.

Prerequisites

Terraform 1.6+ or a compatible OpenTofu release;
AWS provider 5.100.0 for the exact configuration below;
an installed AWS-origin adapter endpoint;
a pre-created target bucket represented by an origin-facing bucket name;
origin-side credentials for the provider;
an isolated workspace and remote state policy suitable for test data.

Check S3 service coverage for your target before applying.

Configure the provider endpoint

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "= 5.100.0"
    }
  }
}

variable "adapter_endpoint" {
  type = string
}

variable "test_bucket" {
  type = string
}

provider "aws" {
  region = "us-east-1"

  endpoints {
    s3 = var.adapter_endpoint
  }

  s3_use_path_style = true

  # Keep provider startup on the configured S3 route. These switches avoid
  # metadata, region, credential-validation, and account-discovery calls.
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_region_validation      = true
  skip_requesting_account_id  = true
}

resource "aws_s3_object" "smoke" {
  bucket       = var.test_bucket
  key          = "terraform/cloud-adapter-smoke.txt"
  content      = "hello through Cloud Adapter\n"
  content_type = "text/plain"
}

output "object_etag" {
  value = aws_s3_object.smoke.etag
}

The four skip_* settings are deliberate for this bounded S3 fixture: they prevent this provider version from making startup calls to EC2 metadata, region validation, or AWS STS outside the configured adapter route. They do not weaken Cloud Adapter authentication. Validate the origin identity independently, and reassess the startup call graph before changing provider versions.

Run the lifecycle

export TF_VAR_adapter_endpoint="https://adapter.example.test"
export TF_VAR_test_bucket="adapter-smoke-test"
export AWS_PROFILE="adapter-test"
export AWS_REQUEST_CHECKSUM_CALCULATION="WHEN_REQUIRED"

terraform init
terraform fmt -check
terraform validate
terraform plan -out=adapter.tfplan
terraform apply adapter.tfplan

After apply:

Read the object through the origin API.
Inspect it in the native target service.
Confirm its bytes and content type.
Save the provider and adapter versions with the test evidence.

Prove read-back and drift behavior

Run a second plan:

terraform plan -detailed-exitcode

Exit code 0 means no diff, 2 means Terraform found a diff, and 1 means an error. If the provider cannot read a field it wrote, a perpetual diff can appear even though creation succeeded. Compare the diff with the target-specific fidelity and limitation tables. For a controlled drift test, change only a disposable object’s content through the native target API, run terraform plan, and observe whether the provider detects the change. Restore or destroy the object afterward.

Clean up safely

terraform plan -destroy -out=destroy.tfplan
terraform apply destroy.tfplan

Verify through both the origin API and target service that only the test object was removed. Retain or destroy the test bucket according to its separate ownership policy.

State and migration boundaries

Terraform state records provider-visible identity; it is not application data migration.
Changing the provider endpoint can cause refreshes, replacement plans, or identity mismatches.
Import requires compatible read and identity behavior, not only create support.
A clean plan does not prove unsupported fields are preserved.
Never point a production workspace at a new adapter endpoint before testing refresh and replacement behavior on a copy.

Troubleshooting

Failure stage	Likely boundary
`init`	Provider installation or state backend, before Cloud Adapter.
Provider configuration	Credentials, TLS, endpoint, region, or an unexpected discovery API such as STS.
`plan` refresh	Read/list coverage, identity translation, or target permissions.
`apply`	Create/update coverage, backend permissions, timeout, or target quota.
Second plan	Read-after-write fidelity, defaults, normalization, or identifier mapping.
Destroy	Delete coverage, retention policy, dependency ordering, or a target-side hold.

Capture diagnostic response headers and run the failing origin operation with the AWS CLI guide to separate provider behavior from adapter behavior.

Tensor9 Cloud Adapter

How It Works

Getting Started

Configuration

Deployment

Operations

Tuning

Debugging

Testing

AWS

Google Cloud

Azure

Reference

Guides

Terraform/OpenTofu Guide

What this test proves

Prerequisites

Configure the provider endpoint

Run the lifecycle

Prove read-back and drift behavior

Clean up safely

State and migration boundaries

Troubleshooting

​What this test proves

​Prerequisites

​Configure the provider endpoint

​Run the lifecycle

​Prove read-back and drift behavior

​Clean up safely

​State and migration boundaries

​Troubleshooting

What this test proves

Prerequisites

Configure the provider endpoint

Run the lifecycle

Prove read-back and drift behavior

Clean up safely

State and migration boundaries

Troubleshooting