Bicep, ARM and Terraform practice questions
Fifteen free infrastructure as code practice questions with explained answers, written as short Azure scenarios about ARM templates, Bicep and Terraform. Infrastructure as code means describing the desired end state of resources in files that a tool deploys repeatably. The topic is tested in AZ-104, AZ-400 and AZ-900, with a smaller share in other Microsoft exams.
How to use these questions
Try each question before opening the explanation and commit to one letter. Underline the constraint word in the stem, such as “no state file”, “preview”, “delete resources removed from the file” or “several clouds”, because that word usually separates Bicep, ARM JSON and Terraform. Read why each wrong option fails, since the same distractors return on real exams. The guide ARM templates vs Bicep vs Terraform holds the theory behind these fifteen.
Warm-up: what each tool is
Question 1. A colleague asks how Bicep relates to Azure Resource Manager templates. Which statement is correct?
- A. Bicep is a provider that lets Terraform deploy Azure resources
- B. Bicep replaces Azure Resource Manager as the deployment engine
- C. Bicep files are compiled to ARM JSON templates before Resource Manager deploys them
- D. Bicep stores a state file that must be kept in a storage account
Show answer
Answer: C
Bicep is a Microsoft language that is transpiled to an ARM JSON template, which Azure Resource Manager then deploys, so the two are different spellings of one engine. Bicep is not a Terraform provider, and it does not replace Resource Manager. Bicep also keeps no state file, because Azure itself is the record of what exists.
Question 2. Which of these tools keeps its own state file that the team must store securely and protect from concurrent changes?
- A. Terraform
- B. Bicep
- C. An ARM JSON template
- D. A Bicep file deployed with az deployment group create
Show answer
Answer: A
Terraform records the resources it manages in a state file and compares it with the real world, so teams keep it in a remote backend with locking. Bicep and ARM JSON templates have no state file, because Azure Resource Manager holds the state. Running a Bicep file with az deployment group create does not create one either.
Question 3. A resource group contains a storage account and a virtual machine. An engineer deploys a Bicep file that declares only the storage account, without setting a deployment mode. What happens to the virtual machine?
- A. It is deleted because it is not in the file
- B. It is stopped until it is added to the file
- C. The deployment fails because the resource group contains unmanaged resources
- D. It is left unchanged
Show answer
Answer: D
The default mode is incremental, which adds or updates the resources in the template and leaves other resources in the resource group untouched. Only complete mode deletes resources that are not in the template. The deployment does not fail because of extra resources, and nothing stops or restarts the virtual machine.
Question 4. Before deploying a Bicep file to a production resource group, a team wants to see which resources would be created, modified or deleted, without changing anything. Which command does this?
- A. terraform plan
- B. az deployment group what-if
- C. az bicep build
- D. az deployment group validate
Show answer
Answer: B
The what-if operation, for example az deployment group what-if, predicts the changes of a deployment without making any. The validate command checks that the template and deployment are valid but does not list the resource changes. terraform plan previews Terraform deployments, not Bicep. az bicep build only converts the Bicep file to JSON.
Question 5. An organization has a library of ARM JSON templates and wants to move future development to Bicep. Which command gives the team a starting Bicep file from an existing template?
- A. az bicep build
- B. az bicep decompile
- C. az deployment group export
- D. terraform import
Show answer
Answer: B
az bicep decompile converts a JSON ARM template to a Bicep file, which is a starting point that may need revising to follow best practice. az bicep build goes the other direction, from Bicep to JSON. az deployment group export creates a template from deployed resources, and terraform import brings existing resources into Terraform state.
Scenarios: choosing and configuring
Question 6. A company runs workloads in Azure, AWS and a SaaS platform. The team already has HCL code and wants one language and workflow for all three environments. Which option fits best?
- A. Bicep
- B. ARM JSON templates
- C. Azure Policy
- D. Terraform
Show answer
Answer: D
Terraform supports many clouds and services through providers and uses HCL, so one workflow covers all three environments. Bicep and ARM JSON templates are Azure only. Azure Policy evaluates and enforces rules on resources and does not provision resources across clouds.
Question 7. A Bicep file takes the administrator password for a virtual machine as a parameter. The value must not be saved in the deployment history or logged. What should be added to the parameter?
- A. The @secure() decorator
- B. The @allowed decorator
- C. The @description decorator
- D. The @minLength decorator
Show answer
Answer: A
The @secure() decorator marks a string or object parameter as secure, so its value is not saved to the deployment history and is not logged. @allowed restricts the values that can be supplied, @description only documents the parameter, and @minLength limits the length. None of them hides the value.
Question 8. A Bicep file deploys a web app that needs the blob endpoint of a storage account that already exists in a different resource group and must not be redeployed or changed. What is the correct approach?
- A. Declare the storage account as a normal resource with the same name
- B. Add the storage account to the dependsOn array of the web app
- C. Declare the storage account with the existing keyword and set its scope to the other resource group
- D. Add an output for the blob endpoint to the Bicep file
Show answer
Answer: C
Declaring the storage account with the existing keyword and a scope for the other resource group lets the file read its properties without deploying it again. Redeclaring it as a normal resource would deploy it and reapply its properties. A dependsOn entry only orders resources and does not provide the endpoint value. An output returns a value from this deployment and cannot read another resource.
Question 9. An existing resource was deployed earlier with several customized properties. An engineer redeploys it in incremental mode from a Bicep file that lists only its name, location and SKU. What happens to the properties the file does not mention?
- A. They are kept because incremental mode only adds properties
- B. The deployment fails because the file is incomplete
- C. They are reset to their default values
- D. Azure merges them with the values in the file
Show answer
Answer: C
In incremental mode all properties of a redeployed resource are reapplied, because the template always represents the final state of the resource. Properties that are not specified are reset to their default values, so every non-default value must be listed. They are not merged or kept, and the deployment does not fail just because properties are missing.
Question 10. In a Bicep file, a web app resource uses the property app_plan.id of an App Service plan declared in the same file. A teammate suggests adding a dependsOn entry so the plan is deployed first. What is the best response?
- A. Do nothing, because referencing the plan by its symbolic name already creates the dependency
- B. Add dependsOn, because Bicep never infers dependencies
- C. Split the file into two deployments that run one after the other
- D. Declare the plan above the web app, because file order sets the deployment order
Show answer
Answer: A
Referencing another resource through its symbolic name creates an implicit dependency, so Resource Manager already deploys the plan first. Microsoft advises against unnecessary dependsOn entries because they can slow deployments by preventing parallel deployment. The order in which resources are written in the file does not decide the deployment order, and splitting the deployment is not needed.
Edge cases and traps
Question 11. A platform team wants resources that are removed from the Bicep file to be deleted from Azure on the next update, and wants to block other users from manually deleting the managed resources. Which solution fits?
- A. Incremental mode with what-if before every deployment
- B. A template spec shared through Azure RBAC
- C. Complete mode on the resource group deployment
- D. A deployment stack with actionOnUnmanage set to deleteResources and deny settings set to denyDelete
Show answer
Answer: D
A deployment stack with actionOnUnmanage set to deleteResources deletes resources that are no longer in the template, and deny settings such as denyDelete block manual deletion of the managed resources. Complete mode also deletes, but Microsoft recommends stacks instead, and complete mode cannot block deletions by others. Incremental mode with what-if leaves removed resources in place. A template spec only stores and shares a template.
Question 12. Four engineers run Terraform against the same Azure environment, each with the state file on their own laptop, and applies sometimes overwrite each other. What should the team do?
- A. Commit the state file to the Git repository
- B. Move the state to a remote backend in an Azure Storage blob container
- C. Set the deployment mode to complete
- D. Let each engineer run terraform plan locally before applying
Show answer
Answer: B
Storing the state in a remote backend such as an Azure Storage blob container gives the team one shared state and locking against concurrent operations. Terraform documents that a local state file makes teamwork complicated, because everyone must have the latest state and nobody may run Terraform at the same time. Locking is a feature of the backend, and a state file committed to Git is not a backend, so nothing locks it; state can also contain sensitive values in plain text. Complete mode is an ARM concept, not a Terraform setting. Running plan locally does not stop two applies at once.
Question 13. A team that standardized on Terraform for Azure needs a new Azure feature that the AzureRM provider does not yet support. They want to stay in Terraform. Which provider is intended for this?
- A. AzAPI
- B. AzureRM with complete mode
- C. AzureAD
- D. AzureDevops
Show answer
Answer: A
The AzAPI provider manages Azure resources by calling the Azure Resource Manager APIs directly, so it can reach new Azure functionality without waiting for a provider update. AzureRM is the provider that lacks the feature in this scenario. AzureAD manages Microsoft Entra objects such as users and groups, and AzureDevops manages Azure DevOps projects and pipelines.
Question 14. A platform team wants app teams to deploy a tested, versioned template from the Azure portal or CLI without access to the source repository, with access controlled through Azure RBAC. Which option provides this?
- A. A deployment stack
- B. A template exported from the resource group
- C. A template spec
- D. A JSON file in a blob container shared with a SAS link
Show answer
Answer: C
A template spec is an Azure resource that stores a template for later deployment, supports versioning and is shared with Azure RBAC. A deployment stack manages the lifecycle of deployed resources and is not a way to publish a template. Exporting a template from a resource group creates a snapshot of existing resources, not a versioned shared template. A blob with a SAS link has no versioning of templates and no RBAC on the template itself.
Question 15. After an incident, an administrator needs an exact copy of the ARM template that was used for a specific past deployment, ready to redeploy unchanged and without any manual changes made since. Which export option should be used?
- A. Export the template from the resource group
- B. Run az bicep decompile on the resource group
- C. Run what-if against the resource group
- D. Save the template from the deployment history
Show answer
Answer: D
Saving the template from the deployment history returns an exact copy of the template that was deployed, as it was written, and does not include later manual changes. Exporting from the resource group generates a new template from the current state, which includes manual changes and is autogenerated. az bicep decompile converts JSON to Bicep and does not retrieve a past template. What-if only previews changes.
Where to go next
Review the theory in ARM templates vs Bicep vs Terraform, then continue with CI/CD and Git practice questions and Azure RBAC practice questions. The free 20-question AZ-400 practice test mixes this topic with the rest of the exam, and multiple-choice exam tips cover how to handle the constraint words.