CV0-004 Deployment Practice Question
A DevOps team uses Terraform to manage cloud infrastructure. They want to store the state file in a remote backend to enable team collaboration. Which backend configuration stores Terraform state in an S3 bucket?
⚠ Common exam trap
The CompTIA Cloud+ exam often tests the specific backend names mapped to cloud providers, and the trap here is that candidates may confuse 's3' with a generic storage term or assume 'azurerm' or 'gcs' are interchangeable, when each is tied to a distinct cloud platform.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
backend 's3'
Terraform's 's3' backend is specifically designed to store state files in an AWS S3 bucket, enabling team collaboration through remote state locking and versioning. This backend uses the AWS SDK to interact with S3, supporting features like DynamoDB-based state locking and encryption with KMS.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
backend 'consul'
Why it's wrong here
The consul backend stores state in a Consul key-value store rather than an S3 bucket, so it does not meet the requirement. It is tempting because Consul is a valid remote backend offering locking and collaboration, and would be correct where HashiCorp Consul already underpins service discovery.
- ✗
backend 'azurerm'
Why it's wrong here
The azurerm backend stores state in Azure Blob Storage, not S3, so it cannot satisfy the S3 requirement. It is tempting because it is a legitimate remote backend offering the same collaboration and locking benefits, and would be correct for a team running its infrastructure on Azure rather than AWS.
- ✓
backend 's3'
Why this is correct
Configuring `backend "s3"` writes the Terraform state file directly to an Amazon S3 bucket, satisfying the remote-backend requirement for shared team access. Terraform's S3 backend also supports state locking via DynamoDB, preventing concurrent runs from corrupting state. Other backend types target different storage services, so they cannot store state in S3.
- ✗
backend 'gcs'
Why it's wrong here
The gcs backend writes state to a Google Cloud Storage bucket, not Amazon S3, so it fails the stated requirement. It is tempting because it is a fully featured remote backend providing the same collaboration and state-locking capabilities, and would be the right choice for teams standardised on Google Cloud.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
Courseiva writes every CV0-004 question from scratch — 834 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CV0-004 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CV0-004 exam.