Terraform Certifications Overview: Positioning Associate vs Authoring / Operations Professional

Terraform certifications are easiest to study when you view them as three tiers: the Associate foundation and two role-focused Professionals (Authoring / Operations). Associate emphasizes concepts and basic operations, Authoring focuses on module design and code quality, and Operations focuses on team operations and platform use.

This article is built around stable concepts grounded in the official documentation, balancing exam preparation with real-world application. We avoid version-specific minutiae and concentrate on the durable fundamentals: providers, state management, and HCP Terraform (Terraform Cloud/Enterprise).

Big Picture: Tracks and Role Separation

The Terraform certifications are layered by depth of infrastructure-automation understanding and by role. Associate tests the fundamentals an individual developer needs to handle IaC safely. Authoring Professional evaluates the design, expressiveness, and quality control of reusable modules, and Operations Professional evaluates team and organization-scale operations, state and permissions, policy enforcement, and execution-platform selection and operation.

From a study perspective, the natural order is: first solidify CLI workflow and state management fundamentals, then expand code expressiveness (variables, types, dynamic constructs, modules), and finally move on to HCP Terraform workspaces, policy and RBAC, and remote execution and pipelines.

• Associate: concepts, CLI workflow, basic state management, and module-consumption fundamentals
• Authoring Pro: module design, input/output design, versioning and compatibility, dynamic constructs, and expressive HCL
• Operations Pro: backends, locking, and concurrent execution; HCP Terraform workspaces, RBAC, and policy; run orchestration

Positioning of the certification tracks (conceptual diagram)

Associate
   |
   v
Authoring Pro  <-->  Operations Pro
   (書く力)          (回す力)
        \________ 組織的な IaC 成熟度 ________/

Basic CLI workflow (the Associate foundation)

# ディレクトリ初期化とプラグイン解決
terraform init

# 変更のプレビュー
terraform plan -out=plan.out

# 適用（計画を固定して適用）
terraform apply plan.out

# 破棄（検証用環境など）
terraform destroy

Associate Exam Scope and Real-World Connection

Associate focuses on Terraform's core concepts and safe day-to-day operation. You're asked about how providers work, the difference between resource and data, variables and outputs, the role of state, the CLI workflow, module basics, and (as appropriate) HCP Terraform workspace and execution fundamentals.

In practice, the keys to safe operation are interpreting plan output, avoiding unintended destruction, choosing state location and lock/backup policy, and handling variables (environment variables and tfvars files) correctly.

• Reading diffs from plan output and understanding side effects
• Basic state operations (read, backup) and justifying placement choices
• Calling modules and passing inputs/outputs
• Workspace fundamentals when using HCP Terraform (VCS integration and manual runs)

Basic workflow (conceptual)

[コード] -> terraform init -> terraform plan -> レビュー -> terraform apply
                                   |
                                 state

Minimal example (easy-to-read main.tf)

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

provider "aws" {
  region = var.region
}

variable "region" {
  type    = string
  default = "us-east-1"
}

resource "aws_s3_bucket" "example" {
  bucket = "nl-associate-example-${random_id.suffix.hex}"
}

resource "random_id" "suffix" {
  byte_length = 2
}

output "bucket_name" {
  value = aws_s3_bucket.example.id
}

Authoring Professional: The Skill of Writing Reusable Code

Authoring Professional centers on module design and code quality. It tests input typing and validation, stable output contracts, version compatibility, for_each and dynamic blocks, and expressive use of conditionals and functions. Registry publishing and versioning, plus design decisions that avoid breaking changes, are also frequent targets.

In practice, the quality and delivery speed of modules hinge on boundary definition, the balance between defaults and required inputs, naming conventions, documentation, example code, and semantic-versioning-based compatibility management.

• Clarify the contract via input typing and validation
• Use locals and expressions to push toward declarative, low-side-effect code
• Use for_each / dynamic for idempotent, readable expansion
• Maintain a compatibility policy with SemVer and a CHANGELOG

Module publishing and consumption (conceptual)

Authoring Dev  -->  Private/公開 Registry  -->  Consumer
     |                    | versions: 1.2.3          |
     |-- README/例示 ---->| immutability              |-- version constraints

Module design snippet (types, validation, dynamic blocks)

# modules/vpc/variables.tf
variable "cidr" {
  type        = string
  description = "VPC CIDR"
  validation {
    condition     = can(cidrhost(var.cidr, 0))
    error_message = "cidr には有効な CIDR を指定してください。"
  }
}

variable "public_subnets" {
  type = map(object({
    cidr = string
    az   = string
  }))
}

# modules/vpc/main.tf
resource "aws_vpc" "this" {
  cidr_block = var.cidr
  tags       = { Name = "core-vpc" }
}

resource "aws_subnet" "public" {
  for_each          = var.public_subnets
  vpc_id            = aws_vpc.this.id
  cidr_block        = each.value.cidr
  availability_zone = each.value.az
  map_public_ip_on_launch = true
  tags = {
    Name = "public-${each.key}"
  }
}

# root/main.tf（利用側）
module "vpc" {
  source = "appcorp/vpc/aws"
  version = "~> 1.2"
  cidr    = "10.0.0.0/16"
  public_subnets = {
    a = { cidr = "10.0.1.0/24", az = "us-east-1a" }
    b = { cidr = "10.0.2.0/24", az = "us-east-1b" }
  }
}

output "vpc_id" { value = module.vpc.vpc_id }

Operations Professional: Going Deep on Operations and Platform

Operations Professional evaluates the ability to run team operations safely: state management, remote backends, locking and concurrency control, HCP Terraform (Terraform Cloud/Enterprise) workspaces, RBAC, policy (Sentinel) and run tasks, and VCS integration with execution-queue control.

The crucial piece is governance that prevents unintended concurrent applies and out-of-band manual changes. Backend selection, workspace strategy, separation of execution permissions, policy-set enforcement, protection of variables and secrets, and exploitation of execution logs and audit data are central to both the exam and real-world operation.

• Remote backend and locking (for example S3 + DynamoDB, or HCP Terraform's built-in locking)
• Workspaces, VCS integration, and understanding queues and approval flows
• Sentinel policy enforcement levels (advisory / soft-mandatory / hard-mandatory)
• Governance over state operations (safe use of mv / rm / import)

Operations pipeline (HCP Terraform usage)

Dev PR -> VCS webhook -> HCP Terraform workspace
                           |-> plan -> policy check -> apply
                                   |            ^
                                   v            |
                               remote state  Sentinel

Backend and cloud-integration configuration examples (stable features)

# 例1: S3 バックエンド（DynamoDB ロック）
terraform {
  backend "s3" {
    bucket         = "tfstate-bucket"
    key            = "prod/network/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tfstate-lock"
    encrypt        = true
  }
}

# 例2: Terraform Cloud/HCP Terraform の cloud ブロック
terraform {
  cloud {
    organization = "acme"
    workspaces {
      name = "prod-network"
    }
  }
}

# 代表的な state メンテナンス（要計画・要バックアップ）
# terraform state list
# terraform state mv aws_subnet.public["a"] aws_subnet.public["az-a"]
# terraform state rm aws_eip.legacy

Study Plan: Grow from Associate to Pro in Stages

The most efficient path is to first get comfortable with state and workflow in a single project, then move to modularization and versioning, and finally extend into team operations with HCP Terraform and policy. Pair each stage with real tasks and always verify plan review and rollback feasibility.

Keep mock environments small and limited to ones you can create and destroy quickly. Setting measurable goals (automated lint/validate/plan, module version-bump exercises, workspace RBAC setup) keeps both exam and real-world skills moving in parallel.

• Run small weekly experiments and append your learnings to README each time
• Always save plan-diff screenshots and plan.out artifacts
• Templatize module updates as PRs aligned with SemVer policy

Staging the learning path

Foundation --> Authoring --> Operations
   state/CLI     modules       TFC/TFE + policy/RBAC

Example of a minimum CI quality gate (language-agnostic shell)

# フォーマットと構文検証
terraform fmt -check
terraform validate

# 計画作成とアーティファクト化
terraform plan -out=plan.out
terraform show -no-color plan.out > plan.txt

# 失敗時に PR をブロックする（CI の失敗で評価）
# exit 1 を返すだけで十分なガードになる

Common Pitfalls and Countermeasures (Exam and Field)

Most pitfalls come from resource-address changes, manual state edits, version mismatches, and misuse of workspaces or variables. The exam tends to ask about designs and procedures that avoid unintended recreation and breaking changes, and the field is exactly the same.

In the Operations area specifically, concurrent execution, over- or under-permissioning, and misconfigured policy-enforcement levels lead directly to incidents. Make pre-run review and post-run audit-log checks routine.

• Understand cases where changing a for_each key causes resources to be recreated
• Don't reach for state rm casually (it can cause drift)
• Pin provider and module versions with explicit ranges
• Agree as a team on policy-violation behavior (advisory / mandatory)

How reproducibility-breaking factors relate

Versions -----> Plan reproducibility <----- State location
    |                    ^                          |
    v                    |                          v
 Module/API changes   Drift risk               Concurrency

Minimal example of S3 backend and a Sentinel policy

# backend（再掲：状態の一元化）
terraform {
  backend "s3" {
    bucket         = "tfstate-bucket"
    key            = "dev/app/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tfstate-lock"
    encrypt        = true
  }
}

# Sentinel（Terraform Cloud/Enterprise 用の例、適用レベルは運用で設定）
# ファイル: restrict-instance-type.sentinel
import "tfplan/v2" as tfplan

allowed = ["t3.micro", "t3.small", "t3.medium"]

main = rule {
  all tfplan.resources.aws_instance as r {
    all r.applied as inst { inst.instance_type in allowed }
  }
}

Check with a Sample Question

Frequently Asked Questions