SOA-C02 Deployment, Provisioning, and Automation Practice Question
An organization uses AWS CloudFormation to manage infrastructure. They have a stack that includes an Amazon RDS DB instance. The administrator wants to update the DB instance's allocated storage without downtime. The DB instance is currently using gp2 storage. Which action should the administrator take?
⚠ Common exam trap
It's easy for candidates to assume any storage modification requires downtime or a manual snapshot/restore, but AWS RDS allows online storage scaling for gp2 volumes, making a direct CloudFormation update the correct zero-downtime approach.
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
✓
Modify the storage size in the CloudFormation template and update the stack.
Modifying the allocated storage size in the CloudFormation template and updating the stack triggers a storage modification on the RDS DB instance. For gp2 storage, increasing allocated storage does not require downtime; RDS performs the modification while the instance remains available. This approach aligns with the requirement to avoid downtime and leverages CloudFormation's infrastructure-as-code capabilities.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a read replica with the new storage size and promote it.
Why it's wrong here
Creating a read replica with the desired storage size and then promoting it turns the replica into a standalone instance, but this path introduces an extra database node, replication lag, and a new endpoint that requires application reconfiguration. Promotion itself does not preserve the original instance's in-flight transactions to the same point as a direct modification and can force a brief cutover. For a simple capacity increase, this is unnecessarily risky and far more complex than a single online storage modification.
- ✓
Modify the storage size in the CloudFormation template and update the stack.
Why this is correct
Updating the CloudFormation stack with a larger AllocatedStorage value invokes RDS's online storage scaling, so the disk can be expanded while the instance remains available. CloudFormation translates the template change into a ModifyDBInstance operation; with ApplyImmediately not set to true, the change is applied during the next scheduled maintenance window, avoiding an unplanned outage. This keeps the existing endpoint and replication topology intact and is the least disruptive, infrastructure-as-code-friendly approach.
- ✗
Stop the DB instance, modify the storage, and start it.
Why it's wrong here
Stopping the DB instance takes the database completely offline, and RDS does not allow storage-size modifications for a stopped instance; you must start it before calling ModifyDBInstance. Even if you were able to modify storage while stopped, the required stop and start cycle would cause unnecessary downtime for a change that RDS can perform online. This is therefore both operationally disruptive and technically invalid for the typical workflow.
- ✗
Take a manual snapshot and restore it with the new storage size.
Why it's wrong here
A manual snapshot and restore creates a brand-new DB instance with a different endpoint, and any transactions committed after the snapshot is taken are lost unless the snapshot happens to be current. Restoring with a larger storage allocation also requires you to redirect all application traffic and re-point DNS, causing an avoidable outage. RDS supports direct storage expansion on a live instance, so snapshot/restore is a blunt, disruptive tool that should only be used for migration or rebuild scenarios.
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 SOA-C02 question from scratch — 1,169 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 SOA-C02 practice question is part of Courseiva's free Amazon Web Services 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 SOA-C02 exam.