[bruno-andrade-azion]

What & why

Related issue: MM-16216

Pages affected: 14 pages, in both languages (28 files), under apps/docs/src/content/docs/{en,pt-br}/pages/:

• devtools/terraform/: terraform.mdx, how-it-works.mdx, examples.mdx, troubleshooting.mdx, terraformV3.mdx
• devtools/terraform/guides/: getting-started.mdx, best-practices.mdx, migration-v3-to-v4.mdx
• devtools/terraform/resources/: applications.mdx, certificates.mdx, connectors.mdx, security.mdx, workloads.mdx
• secure-journey/automate/terraform.mdx (secure-jornada/automatizar/terraform.mdx in Portuguese)

The samples. Every Terraform HCL sample is rewritten for the nested schema of aziontech/azion 2.10.0, and every page pins that version. On main, 76 of the 88 samples fail terraform validate. Samples that are wrong on purpose or depend on files outside the page carry an MDX comment, {/* terraform-validate: skip */}, that the markdown twin drops:

• the v1.x "before" blocks in the migration guide;
• the three fences of the v1.x page;
• two certificate samples that read PEM files with file();
• one call to a local module in the best practices.

The IDs in the domain-to-workload migration pair come from variables instead of literals.

The resource catalog.

• The names of resources and data sources match the provider documentation of 2.10.0. Examples are azion_application_function_instance(s), azion_firewall_function_instance and azion_firewall_functions_instance, and azion_applications_main_settings.
• azion_workload binds its application only through azion_workload_deployment, in deployment.strategy.attributes.application.
• Certificates gain azion_certificate_request, azion_certificate_signing_request, and azion_crl. The resources and data sources page gains Object Storage and Data Stream.

WAF. The pages use the platform's name for the object, a rule set, which Azion Console lists under WAF Rules and the provider manages as azion_waf. azion_waf_rule_set is a WAF exception. The migration guide now maps the v1.x azion_waf_rule_set, which was the rule set itself, to azion_waf, and its azion_waf_rule_sets data source to azion_wafs. It lists the v2 azion_waf_rule_set with the resources that v2 adds. The state and import steps cover the rule set, and the WAF mode moves to the set_waf behavior of a firewall rule.

Migration guide.

• azion_environment_variable and its data source move to Removed, because v2 has no such resource. So does the azion_waf_domains data source.
• The resources added after 2.0.0 are listed under "Resources added in v2".
• The two rule order resources take their arguments at the top level, so the nested-block rule applies to the resources with a v1.x counterpart.

How the provider applies a configuration. how-it-works gains "Configuration is the desired state". An omitted field that a resource enforces returns to its default on apply. An omitted field that it does not enforce, such as domains on azion_workload, keeps the value that the API holds. This follows the "Configuration is the desired state" and "Drift and enforcement" notes of each resource in the provider documentation.

How I checked it.

• pnpm lint:terraform, from chore(scripts): add pnpm lint:terraform to validate Terraform samples #2637, which adds the validator, reported 70 of 70 samples valid against 2.10.0 and 22 skipped by marker. It was not run again after the review fixes, which changed the migration pair, one IP range in the examples, and code comments.
• Internal links: 0 broken, 0 cross-language. The en and pt-br code blocks are identical. The headings and table rows match across each pair, and so do the namespaces.
• Every value that the schema does not enumerate appears in the provider's own documentation for 2.10.0. Examples are http, force_https, blocking, any_url, generic, set_connector, bypass_cache, deny, deliver, honor, override, and default.

Not verified.

• No sample was applied against an Azion account. That is MM-16196, which this pull request unblocks.
• pnpm build:local was not run locally.
• For the DevTools reviewer (MM-16194):
  • Confirm the v1 to v2 mappings cname_access_only = false → workload_domain_allow_access = true and origin_protocol → transport_policy.
  • Confirm that the top-level id of azion_network_list is the ID that is_in_list expects.

Out of scope:

• The import sections of the migration guide for the renamed application resources.
• The data-source rows of the renamed v1.x application and firewall resources.
• A CI job that runs pnpm lint:terraform, which belongs to the CI owners.

Type of change

• 🆕 New content (feat) — no new page
• 🩹 Fix (fix) — typo, broken link, wrong information
• ♻️ Content update (docs) — rewrite, expansion, upkeep
• 🌐 Translation sync (i18n) — pt-br changes travel with the English ones
• 🏗️ Platform / structure (refactor / chore) — reviewed by UXE, no content mixed in — the validator script is in chore(scripts): add pnpm lint:terraform to validate Terraform samples #2637

Author checklist

• PR title follows type(scope): summary (see GOVERNANCE.md §4)
• Frontmatter complete: title, description, meta_tags, namespace, permalink, last_reviewed — no page in the repository carries last_reviewed; the other five fields are present on every page
• No legacy "edge-" product names in the copy — v1.x resource types such as azion_edge_function appear only as code in the migration guide and the v1.x page
• How-to/tutorial content includes at least one runnable, copy-paste-tested code block — the samples pass terraform validate but were not applied against an account (MM-16196)
• Screenshots (if any) have alt text and follow image standards — no screenshot is added or changed
• Internal links are relative and resolve locally — root-relative, 0 broken
• If any permalink changed or page moved: redirect added in this PR — no permalink changed
• i18n: pt-br updated in this PR or follow-up i18n issue created: pt-br updated in this PR
• I ran pnpm build:local (build + frontmatter check) without errors — not run; the CI Build check covers it