SOA-C02 Deployment, Provisioning, and Automation Practice Question
A company uses AWS CloudFormation to deploy a stack that includes an Amazon RDS DB instance with Multi-AZ enabled. During a stack update, the database engine version is changed. The update fails with a rollback. What is the most likely cause?
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
✓
The engine version upgrade is not supported for Multi-AZ deployments.
Changing the database engine version on a Multi-AZ RDS instance is not supported directly through a CloudFormation stack update without additional steps. Multi-AZ deployments require both primary and standby instances to be upgraded, and if the new engine version is not compatible or the upgrade path is not supported, the update fails and triggers a rollback. Option B is incorrect because instance class availability is not the primary issue; the error relates to the engine version change, not the instance class. Option C is incorrect because storage type compatibility is not the relevant factor; the storage type remains unchanged. Option D is incorrect because the DB subnet group is not involved in engine version upgrades, and IP address availability is not a typical cause for this failure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The engine version upgrade is not supported for Multi-AZ deployments.
Why this is correct
Amazon RDS rejects certain major engine version upgrades on Multi-AZ deployments because the in-place upgrade path is not available for all database engine versions when a standby replica is present. CloudFormation surfaces this as a generic engine version upgrade failure, but the root cause is a service-side limitation, not a misconfigured resource property. To complete the upgrade, you must typically create a snapshot, restore from it, promote the restored instance, or use a blue/green deployment, after which you can update the CloudFormation stack to reference the new instance.
- ✗
The DB instance class is not available for the new engine version.
Why it's wrong here
If the requested DB instance class were unavailable for the target engine version, CloudFormation would raise an error such as 'InvalidDBInstanceClass' or 'The specified DB instance class is not supported by the engine version,' not a generic upgrade-support failure. An engine version upgrade alone does not change the DB instance class; the class remains as originally deployed unless you explicitly modify it in the same stack update. Since the question's error text focuses exclusively on the engine version and Multi-AZ, the instance class is not the cause.
- ✗
The storage type is not compatible with the new engine version.
Why it's wrong here
Storage type compatibility is independent of engine version upgrades in RDS; general purpose SSD, provisioned IOPS, and magnetic storage all persist across supported major and minor version changes. If a storage type were truly incompatible with a new engine version, CloudFormation or RDS would report a dedicated storage-class or disk-type validation error, not an upgrade-support error. Moreover, the scenario only mentions an engine version upgrade, and RDS evaluates storage compatibility at resource creation or when modifying the storage configuration, neither of which is occurring here.
- ✗
The DB subnet group does not have enough IP addresses.
Why it's wrong here
A DB subnet group's available IP address count is irrelevant to an in-place engine version upgrade because RDS does not provision a new primary or standby instance during the modification. Upgrading the engine version simply applies the new binaries to the existing DB instances within the same VPC and subnet group, without consuming additional addresses. Insufficient IP capacity would instead produce a 'subnet group does not have enough IP addresses' error when launching a new instance or adding a read replica, not when upgrading an existing Multi-AZ deployment.
Visual reference
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.