Cloud Infrastructure Fundamentals · Module 11 of 12

Cloud with Terraform and safe automation

Connect Terraform fundamentals to cloud providers, credentials, remote state, plans, policy checks and CI/CD without teaching unsafe static-key workflows.

Learning objectives

By the end of this module, you should be able to:

Explain provider authentication without embedding credentials in HCL.
Describe remote state, locking and plan review for teams.
Design a safe CI/CD flow using temporary identity and reviewed plans.

Provider credentials are runtime identity, not Terraform configuration data

Terraform providers discover credentials through documented mechanisms such as environment/configuration, workload identity or role assumption. Do not hard-code access keys in .tf files or commit them to repositories.

Remote state enables collaboration but needs protection

Team state should use a backend/service with access control, encryption and concurrency protection. State may contain sensitive values even when outputs are marked sensitive.

CI/CD should separate plan evidence from controlled apply

A pipeline can format/validate/test, create a plan, run policy/security checks and require approval before apply. Prefer temporary federated credentials for the automation identity.

OpenTofu can be evaluated as an IaC-compatible alternative, but migration is a change

HashiCorp changed Terraform's source-code license for future releases from MPL 2.0 to the Business Source License (BSL/BUSL) 1.1 in 2023. This course is not giving legal advice: organizations should review the current Terraform license and their own intended use before standardizing on a tool.

OpenTofu aims to maintain compatibility with Terraform configurations and many configurations work without modification. A migration still requires state/code backup, initialization, plan comparison, provider/module compatibility checks and a small controlled test before broader adoption.

Do not assume bidirectional state compatibility forever or mix Terraform/OpenTofu casually in the same state workflow. Follow the migration guidance for the exact versions in use and document which implementation owns each state.

Worked examples

See the idea in practice.

Safe delivery shape

Git change → fmt/validate/test → plan → policy/security checks → approval → temporary cloud role → apply → post-change verification

The apply identity should be narrower than a human administrator.
Plan artifacts and state require sensitive handling.

Migration safety shape

backup code/state → install OpenTofu → tofu init → tofu plan → compare for unexpected changes → test small non-critical change

Compatibility is something to verify, not a reason to skip change control.
The course continues to use Terraform commands because the preceding Academy course is Terraform Fundamentals; the architecture principles apply to both tools where their workflows are compatible.

Core lab · Modes 1–2 · Concept + local simulation

Lab — Audit a Terraform cloud workflow

Goal: Inspect a synthetic CI workflow for static credentials and missing gates.

Before you start

No Terraform or cloud account required for this audit exercise.

STEP 1

Create unsafe workflow

cat > /tmp/cloud-iac-workflow.txt <<'EOF'
checkout
AWS_ACCESS_KEY_ID=hardcoded-example
terraform plan
terraform apply -auto-approve
EOF

STEP 2

Detect unsafe signals

python3 - <<'PY'
t=open('/tmp/cloud-iac-workflow.txt').read()
issues=[]
if 'AWS_ACCESS_KEY_ID=' in t: issues.append('static credential')
if 'apply -auto-approve' in t and 'approval' not in t.lower(): issues.append('no approval gate')
print(issues)
assert len(issues)==2
PY

STEP 3

Design replacement

Replace static credentials with OIDC/federated role assumption; add fmt/validate/test, saved plan, approval and post-apply verification.

Verify

The synthetic workflow is flagged for a static credential and missing approval gate.
Your replacement uses temporary identity and separates plan from controlled apply.

Expected outcome

You can connect the Terraform, Git and CI/CD courses into one safer cloud change workflow.

Diagnose / troubleshoot

If plan/apply uses a static key, replace it with federated/temporary identity rather than hiding the key in another file.
If OpenTofu/Terraform plans differ unexpectedly during migration, stop before apply and investigate provider, module, state and version compatibility.

Real-world connection

Production IaC pipelines add policy-as-code, secret scanning, provider/plugin pinning, protected environments and audit evidence.

Mode 3 · Optional AWS lab

Optional AWS — verify Terraform authentication prerequisites

Validate the active AWS identity and inspect Terraform-related environment configuration without applying infrastructure.

Resources created

None — this is a read-only inspection lab.

Estimated cost / risk

Expected incremental resource cost: none because the supplied commands are read-only.
Existing resources in the account can still incur their normal charges; confirm current AWS pricing for the selected Region/account.

Prerequisites

Optional sandbox AWS account and AWS CLI.
Use a least-privilege or federated identity; do not paste long-lived access keys into course files.

AWS 1

aws sts get-caller-identity

AWS 2

env | grep -E '^(AWS_PROFILE|AWS_REGION|AWS_DEFAULT_REGION)=' || true

Verify

The caller identity is recognized and no long-lived secret needs to be embedded in Terraform code.
No AWS resources are created by the supplied commands.

Cleanup

No AWS cleanup is required because this lab creates no AWS resources.

Warnings

Optional only: not required for course completion or the main validator.
Do not run terraform apply as part of this optional inspection lab.
Use remote state only after reviewing backend encryption, access control and locking requirements.

Avoid these traps

Common mistakes

Hard-coding cloud credentials in Terraform.
Using local state for a multi-person production workflow.
Applying unreviewed infrastructure changes from every commit.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1Where should cloud access keys be stored in HCL?

They generally should not be hard-coded in HCL; use supported runtime identity/credential mechanisms.

2Why protect remote state?

It contains authoritative infrastructure mapping and can include sensitive values.

3Why save/review a plan?

It provides explicit evidence of proposed changes before controlled apply.

4Scenario: a team wants to try OpenTofu against an existing Terraform configuration. What should happen before any apply?

Back up state/code, initialize OpenTofu, run and compare a plan for unexpected differences, verify provider/module compatibility, and test a small controlled change.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Core lab attemptedRecord this after meaningfully completing or attempting the module's core lab.Knowledge checks attemptedThis is marked automatically after you open every answer in the module; you can also record it manually.

Attempt the core lab and knowledge checks before marking the module complete.