Simulado · HashiCorp
Simulado HashiCorp Certified: Terraform Associate (003)
Resposta curta
O simulado de HashiCorp Certified: Terraform Associate (003) tem 50 questões em 60 minutos, com nota de corte de 70%, conforme configurado aqui. O jeito mais rápido de saber se você está pronto é fazer uma prova completa no relógio e ler a nota por domínio, não só o total.
Domínios cobrados
- HCP Terraform Capabilities
- IaC Concepts and Terraform Purpose
- Interact with Terraform Modules
- Read, Generate, and Modify Configuration
- Terraform CLI and Core Workflow
- Terraform State
Questões de exemplo, com explicação
Três questões do banco, abertas para ler.
A platform team wants to standardize that all modules consuming the internal 'mycorp/vault' provider use any version in the 1.x line but never automatically jump to 2.0, which contains breaking changes. They add the constraint to required_providers. Which version constraint string correctly expresses 'any 1.x release, including future 1.x patches and minors, but not 2.0'?
- version = "~> 1.0" ✓ (correta)
- version = "= 1.0"
- version = "~> 1.2.0"
- version = ">= 1.0"
Por que esta é a correta
The pessimistic constraint operator '~>' with two version segments, '~> 1.0', allows the rightmost specified component (the minor) and the patch component to increment while pinning the leftmost (major) component, meaning >= 1.0.0 and < 2.0.0. That is exactly 'any 1.x but not 2.0'. '~> 1.2.0' is wrong because with three segments it only allows the patch to increment, meaning >= 1.2.0 and < 1.3.0, which excludes future minors like 1.4. '>= 1.0' is wrong because it permits 2.0 and beyond, exactly the breaking upgrade the team wants to block. '= 1.0' is wrong because it pins to a single exact version (1.0.0) and forbids any later 1.x patch or minor release.
An engineer wants to guarantee that the exact set of changes reviewed during planning is what actually gets applied, with no chance of drift or a recomputed diff between review and execution. Which workflow achieves this?
- Run `terraform plan -refresh=false` then `terraform apply -refresh=false`
- Run `terraform plan -out=tfplan`, then `terraform apply tfplan` ✓ (correta)
- Run `terraform apply -auto-approve` twice and compare outputs
- Run `terraform plan` then immediately `terraform apply` and type 'yes'
Por que esta é a correta
Saving a plan with `-out` and then applying that saved plan file makes Terraform execute exactly the recorded set of actions; no new plan is computed at apply time, so review and execution are identical. Running a bare `plan` then a bare `apply` is wrong because the apply recomputes a fresh plan against current state, which can differ from what was reviewed. Running `apply -auto-approve` twice is wrong because each apply computes its own plan and auto-approves it — comparing outputs does not lock the reviewed change set and skips review entirely. Using `-refresh=false` on both commands is wrong because, although it skips refresh, the apply still recomputes the diff from configuration and state and may not match the earlier plan; only a saved plan file guarantees identical actions.
A resource attribute requires a value that may be absent. The author writes `bucket = coalesce(var.custom_bucket, "default-bucket")` expecting it to fall back to the literal when `var.custom_bucket` is an empty string. The plan errors or behaves unexpectedly with an empty string. What is the correct understanding?
- `coalesce` returns the first non-null, non-empty argument, so an empty string is skipped only if `coalesce` is given a non-empty fallback — but it errors when all arguments are empty/null. ✓ (correta)
- `coalesce` is not a valid Terraform function; the author should have used `try` to provide a fallback.
- `coalesce` always returns its last argument, so the default literal is what gets used regardless of the variable.
- `coalesce` only skips `null`, not empty strings, so an empty `var.custom_bucket` is returned and the default is never used.
Por que esta é a correta
`coalesce` returns the first argument that is neither null nor an empty string; given `("", "default-bucket")` it skips the empty string and returns `default-bucket`, but if every argument is empty/null it raises an error because there is nothing to return. That matches the described 'errors or behaves unexpectedly' when inputs are empty. The claim that `coalesce` only skips `null` and not empty strings is the misconception — that behavior describes a different fallback approach (e.g. `var.x != "" ? var.x : default` or `try`), not `coalesce`. `coalesce` does not 'always return its last argument'; it returns the first usable one. `coalesce` is indeed a real Terraform function, so the option claiming it is invalid is wrong, even though `try` is a legitimate but different tool for handling errors rather than empties.
Faça o simulado completo
- 50 questões sorteadas do banco, com cronômetro de 60 minutos
- Nota por domínio e revisão de cada questão
- Tutor de IA para conversar sobre cada questão que você errar
- O que você errou alimenta seu plano de estudo
Simulado independente e não oficial. HashiCorp e o nome da prova são marcas de seus donos; o UpSkillScore não é afiliado a eles. Formato e nota de corte são a configuração do simulado no UpSkillScore, não uma declaração oficial.
Perguntas frequentes
Quantas questões tem o simulado de HashiCorp Certified: Terraform Associate (003)?
Tem 50 questões e limite de 60 minutos. A nota de corte do simulado é 70%.
Este é o exame oficial de HashiCorp Certified: Terraform Associate (003)?
Não. É um simulado independente, montado para espelhar a estrutura da prova real. Ele não substitui o exame oficial.
Preciso de conta para fazer?
Você lê a estrutura e as questões de exemplo sem conta. Fazer o simulado completo cronometrado, a nota por domínio e o tutor de IA exigem conta.