Pulumi vs Terraform em 2026: Infrastructure as Code com TypeScript e Perguntas de Entrevista

Pulumi vs Terraform representa a decisão central de infrastructure as code para equipes DevOps em 2026. Ambas as ferramentas provisionam recursos cloud de forma declarativa, mas diferem no suporte a linguagens, gerenciamento de estado e maturidade do ecossistema. Este comparativo cobre os trade-offs técnicos, exemplos de código em TypeScript e HCL, e as perguntas de entrevista que surgem quando candidatos discutem escolhas de IaC.

Arquitetura Central: Motor do Pulumi vs Ciclo Plan-Apply do Terraform

Terraform utiliza uma linguagem específica de domínio (HCL) e um fluxo de trabalho em duas fases: terraform plan gera um plano de execução, terraform apply o executa. O arquivo de estado rastreia os metadados dos recursos e é armazenado localmente ou em backends remotos como S3 ou Terraform Cloud.

Pulumi integra seu motor em runtimes de propósito geral. Programas escritos em TypeScript, Python, Go ou C# executam diretamente contra as APIs cloud através dos providers do Pulumi. O estado é armazenado no Pulumi Cloud por padrão, com opções para backends autogerenciados incluindo S3, Azure Blob Storage e arquivos locais.

A diferença arquitetural aparece imediatamente na forma como cada ferramenta lida com loops, condicionais e abstrações. O for_each e count do Terraform funcionam dentro das restrições do HCL. Programas Pulumi usam construções nativas da linguagem: for...of em TypeScript, list comprehensions em Python, range em Go.

import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

// Native TypeScript array methods work directly
const environments = ["dev", "staging", "prod"];

const buckets = environments.map(env => 
  new aws.s3.BucketV2(`data-${env}`, {
    bucket: `myapp-data-${env}-${pulumi.getStack()}`,
    tags: {
      Environment: env,
      ManagedBy: "pulumi",
    },
  })
);

// Export bucket ARNs as stack outputs
export const bucketArns = buckets.map(b => b.arn);

A configuração equivalente em Terraform requer sintaxe HCL para iteração:

# main.tf - Terraform HCL example
variable "environments" {
  type    = list(string)
  default = ["dev", "staging", "prod"]
}

resource "aws_s3_bucket" "data" {
  for_each = toset(var.environments)

  bucket = "myapp-data-${each.key}-${terraform.workspace}"

  tags = {
    Environment = each.key
    ManagedBy   = "terraform"
  }
}

output "bucket_arns" {
  value = [for b in aws_s3_bucket.data : b.arn]
}

Ambos os snippets criam três buckets S3. A versão Terraform é concisa e legível para qualquer pessoa familiarizada com HCL. A versão Pulumi usa TypeScript padrão, o que significa autocompletar no IDE, verificação de tipos e integração com bases de código existentes sem aprender uma nova linguagem.

Suporte TypeScript: Linguagem Nativa vs CDKTF (Descontinuado)

Pulumi suportou TypeScript desde seu primeiro lançamento público. O SDK expõe classes de recursos tipadas, e pulumi.Output<T> encapsula valores assíncronos que são resolvidos durante o deploy. Ferramentas de refatoração, linters e frameworks de teste do ecossistema TypeScript aplicam-se diretamente.

A resposta do Terraform ao suporte de linguagens de propósito geral foi o CDKTF (Cloud Development Kit for Terraform). CDKTF permitia que equipes escrevessem TypeScript ou Python que compilava para JSON do Terraform. A HashiCorp descontinuou o CDKTF em dezembro de 2025 e arquivou o repositório. Projetos CDKTF existentes ainda funcionam, mas nenhuma atualização é publicada para novas versões do Terraform ou mudanças de providers.

Para equipes que querem TypeScript IaC em 2026, Pulumi é a opção ativamente mantida. Equipes já investidas em CDKTF podem continuar executando suas stacks, mas a migração para HCL ou Pulumi é o caminho a seguir para novos desenvolvimentos.

import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

// Custom component encapsulating VPC, subnets, and routing
export class StandardVpc extends pulumi.ComponentResource {
  public readonly vpcId: pulumi.Output<string>;
  public readonly publicSubnetIds: pulumi.Output<string>[];

  constructor(name: string, args: { cidr: string; azCount: number }, opts?: pulumi.ComponentResourceOptions) {
    super("mycompany:network:StandardVpc", name, {}, opts);

    const vpc = new aws.ec2.Vpc(`${name}-vpc`, {
      cidrBlock: args.cidr,
      enableDnsHostnames: true,
      tags: { Name: name },
    }, { parent: this });

    this.vpcId = vpc.id;

    // Create public subnets across availability zones
    const azs = aws.getAvailabilityZones({ state: "available" });
    this.publicSubnetIds = [];

    for (let i = 0; i < args.azCount; i++) {
      const subnet = new aws.ec2.Subnet(`${name}-public-${i}`, {
        vpcId: vpc.id,
        cidrBlock: `10.0.${i}.0/24`,
        availabilityZone: azs.then(az => az.names[i]),
        mapPublicIpOnLaunch: true,
        tags: { Name: `${name}-public-${i}` },
      }, { parent: this });
      this.publicSubnetIds.push(subnet.id);
    }

    this.registerOutputs({ vpcId: this.vpcId });
  }
}

Este componente Pulumi cria uma abstração VPC reutilizável. Os consumidores instanciam com new StandardVpc("prod", { cidr: "10.0.0.0/16", azCount: 3 }). O equivalente em Terraform é um diretório de módulo com variáveis, outputs e arquivos HCL. Ambas as abordagens permitem reutilização; a versão Pulumi herda as ferramentas do TypeScript para documentação, testes e versionamento.

Gerenciamento de Estado e Opções de Backend

O gerenciamento de estado é onde as diferenças operacionais aparecem. O estado do Terraform contém IDs de recursos, metadados de providers e valores sensíveis. As equipes devem configurar backends remotos para habilitar colaboração e implementar locking para prevenir modificações concorrentes.

A configuração de backend do Terraform suporta S3, Azure Blob, Google Cloud Storage, Terraform Cloud e outros. Cada backend requer sua própria configuração de autenticação. O locking de estado usa DynamoDB para backends S3, leases de blob para Azure, ou locking nativo no Terraform Cloud.

Pulumi Cloud gerencia armazenamento de estado, locking e histórico por padrão. As equipes criam uma conta gratuita, executam pulumi login, e o gerenciamento de estado fica configurado. Para equipes que requerem estado autogerenciado, Pulumi suporta S3, Azure Blob, GCS e backends de arquivos locais com o comando pulumi login.

# Pulumi: login to self-managed S3 backend
pulumi login s3://my-pulumi-state-bucket

# Terraform: configure S3 backend in HCL
# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Pulumi Cloud fornece uma interface web para histórico de stacks, visualização de recursos e permissões de equipe. Terraform Cloud oferece recursos similares com aplicação de políticas via Sentinel. Opções auto-hospedadas existem para ambos: o backend auto-hospedado do Pulumi e Terraform Enterprise.

Ecossistema de Providers e Suporte Multi-Cloud

O ecossistema de providers do Terraform é o maior em IaC. O Terraform Registry lista mais de 4.000 providers cobrindo AWS, Azure, GCP, Kubernetes e centenas de plataformas SaaS. A qualidade dos providers varia: providers oficiais da HashiCorp e fornecedores cloud recebem atualizações regulares, enquanto providers comunitários podem ficar defasados em relação às mudanças de API.

Os providers do Pulumi encapsulam providers do Terraform usando uma bridge que gera SDKs tipados. O Pulumi Registry expõe providers para os principais clouds, Kubernetes, bancos de dados e serviços de monitoramento. Como Pulumi faz bridge com providers do Terraform, a cobertura do ecossistema é comparável, embora novas versões de providers do Terraform requeiram atualizações da bridge antes que os SDKs do Pulumi reflitam as mudanças.

Pulumi também oferece providers nativos escritos diretamente contra APIs cloud. Os providers nativos para AWS, Azure e Kubernetes entregam suporte no mesmo dia para novos recursos de API. O trade-off é que providers nativos existem apenas para os principais clouds; serviços menos comuns usam providers com bridge.

// Using Pulumi's native AWS provider for Lambda
import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

const role = new aws.iam.Role("lambda-role", {
  assumeRolePolicy: aws.iam.assumeRolePolicyForPrincipal({
    Service: "lambda.amazonaws.com",
  }),
});

const lambdaFunction = new aws.lambda.Function("api-handler", {
  runtime: aws.lambda.Runtime.NodeJS20dX,
  handler: "index.handler",
  role: role.arn,
  code: new pulumi.asset.AssetArchive({
    "index.js": new pulumi.asset.StringAsset(
      `exports.handler = async () => ({ statusCode: 200, body: "OK" });`
    ),
  }),
});

export const functionArn = lambdaFunction.arn;

Testando Código de Infraestrutura

Os testes são onde a escolha da linguagem cria divergência. Programas Pulumi são código padrão, então testes unitários usam frameworks familiares. O módulo @pulumi/pulumi/runtime fornece mocking para criação de recursos, permitindo que testes verifiquem configuração sem fazer deploy de recursos.

import { describe, it, expect, beforeAll } from "vitest";
import * as pulumi from "@pulumi/pulumi";

// Mock Pulumi runtime
pulumi.runtime.setMocks({
  newResource: (args: pulumi.runtime.MockResourceArgs) => {
    return { id: `${args.name}-id`, state: args.inputs };
  },
  call: (args: pulumi.runtime.MockCallArgs) => {
    return args.inputs;
  },
});

describe("S3 Bucket Configuration", () => {
  let bucketTags: Record<string, string>;

  beforeAll(async () => {
    // Import the Pulumi program after mocks are set
    const infra = await import("../infra/index");
    // Extract outputs for testing
    bucketTags = await new Promise(resolve => {
      infra.buckets[0].tags.apply(tags => resolve(tags as Record<string, string>));
    });
  });

  it("should tag buckets with Environment", () => {
    expect(bucketTags).toHaveProperty("Environment");
  });

  it("should tag buckets with ManagedBy", () => {
    expect(bucketTags.ManagedBy).toBe("pulumi");
  });
});

Os testes do Terraform usam terraform test (introduzido no Terraform 1.6) ou ferramentas externas como Terratest. terraform test executa arquivos de teste HCL que criam recursos reais em configurações isoladas. Terratest é uma biblioteca Go que encapsula comandos do Terraform e fornece assertions.

# tests/bucket.tftest.hcl - Terraform native test
run "bucket_tags" {
  command = plan

  assert {
    condition     = aws_s3_bucket.data["dev"].tags["Environment"] == "dev"
    error_message = "Bucket must be tagged with Environment"
  }

  assert {
    condition     = aws_s3_bucket.data["dev"].tags["ManagedBy"] == "terraform"
    error_message = "Bucket must be tagged with ManagedBy"
  }
}

Ambas as abordagens validam a configuração de infraestrutura. A vantagem do Pulumi é a integração com runners de teste do TypeScript e ferramentas de cobertura. Os testes nativos do Terraform executam sem dependências externas mas requerem sintaxe HCL.

Perguntas de Entrevista: Pulumi vs Terraform

As entrevistas DevOps em 2026 frequentemente incluem comparações de ferramentas IaC. Aqui estão perguntas que distinguem candidatos que usaram ambas as ferramentas em produção.

"O que acontece quando o estado do Terraform diverge da infraestrutura real?"

Resposta esperada: terraform plan detecta a divergência comparando o estado com a infraestrutura real. O plano mostra recursos para atualizar, criar ou destruir. A divergência ocorre quando mudanças são feitas fora do Terraform (console, CLI, outras ferramentas). As opções incluem terraform refresh para atualizar o estado, terraform import para trazer recursos sob gerenciamento, ou aceitar o plano para restaurar o estado desejado.

"Como o Pulumi lida com secrets de forma diferente do Terraform?"

Resposta esperada: Pulumi criptografa secrets no estado por padrão usando uma passphrase ou KMS cloud. A função pulumi.secret() marca valores como sensíveis, e eles permanecem criptografados em repouso. Terraform armazena secrets em texto plano nos arquivos de estado; as equipes dependem de criptografia do backend (criptografia server-side do S3) e controles de acesso. Terraform 1.4 adicionou marcação de variável sensitive, mas os valores ainda aparecem não criptografados no estado.

"Por que a HashiCorp descontinuou o CDKTF, e quais são as opções de migração?"

Resposta esperada: CDKTF adicionava overhead de manutenção sem igualar a cadência de atualização do Terraform. Novas versões de providers e recursos do Terraform requeriam atualizações manuais aos bindings do CDK. HashiCorp escolheu focar em HCL e Terraform Cloud. As opções de migração são: converter para HCL usando cdktf convert, reescrever em Pulumi se TypeScript for necessário, ou continuar executando stacks CDKTF existentes sem atualizações.

"Quando você escolheria Pulumi ao invés de Terraform para um novo projeto?"

Resposta esperada: Escolher Pulumi quando a equipe já usa TypeScript/Python/Go e quer IaC na mesma linguagem do código da aplicação, quando abstrações complexas requerem construções de programação reais (generics, interfaces, frameworks de teste), ou quando criptografia integrada de secrets é um requisito. Escolher Terraform quando a equipe conhece HCL, quando o ecossistema de providers deve incluir providers de nicho ou comunitários, ou quando as ferramentas organizacionais (Atlantis, Spacelift) integram com Terraform.

Para mais preparação de entrevistas sobre infrastructure as code, consulte Perguntas de Entrevista Terraform: Guia Completo Infrastructure as Code e o módulo Terraform Avançado.

Estratégias de Migração: Terraform para Pulumi

Pulumi fornece pulumi import para trazer recursos cloud existentes sob gerenciamento sem recriá-los. Para equipes com estado Terraform, pulumi convert traduz HCL para programas Pulumi. A conversão não é perfeita: módulos complexos e blocos dinâmicos requerem ajuste manual.

# Convert Terraform HCL to Pulumi TypeScript
pulumi convert --from terraform --language typescript

# Import existing AWS resources into Pulumi state
pulumi import aws:s3/bucketV2:BucketV2 my-bucket my-existing-bucket-name

Uma migração por fases permite que as equipes executem ambas as ferramentas durante a transição. Terraform gerencia stacks existentes enquanto Pulumi provisiona nova infraestrutura. Uma vez que as equipes ganham experiência com Pulumi, elas convertem stacks do Terraform incrementalmente. O estado não é compartilhado entre ferramentas, então o gerenciamento de recursos deve ser claramente dividido para evitar conflitos.

Framework de Decisão para 2026

Pontos-Chave para Infrastructure as Code em 2026

• Terraform 1.16 é a escolha estável para IaC baseado em HCL com o maior ecossistema de providers e ferramentas maduras (Atlantis, Spacelift, env0).
• Pulumi v3.263 oferece TypeScript, Python, Go e C# com testes nativos da linguagem, integração IDE e criptografia integrada de secrets.
• CDKTF está descontinuado desde dezembro 2025. Equipes querendo TypeScript IaC devem avaliar Pulumi ao invés de iniciar novos projetos CDKTF.
• Ambas as ferramentas suportam deploys multi-cloud, backends de estado remotos e colaboração de equipe. A escolha depende da preferência de linguagem e expertise existente da equipe.
• Discussões de entrevista devem demonstrar entendimento de gerenciamento de estado, detecção de divergência, ecossistemas de providers e os trade-offs entre simplicidade de DSL e poder de linguagens de propósito geral.
• A migração de Terraform para Pulumi é possível usando pulumi convert e pulumi import, mas requer planejamento cuidadoso e rollout por fases.