SOA-C02 Deployment, Provisioning, and Automation Practice Question
Network Topology
A SysOps administrator updates a CloudFormation stack to change the EC2 instance type from t2.micro to t3.medium. The update fails with the error shown. What is the MOST likely cause?
⚠ Common exam trap
Test-takers frequently confuse 'unavailable in AZ' with 'service limit exceeded' or 'AMI incompatibility', but the specific error message about instance type availability points directly to an AZ constraint.
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 t3.medium instance type is not available in the specified Availability Zone.
The error indicates that the t3.medium instance type is not available in the specified Availability Zone (AZ). AWS instance types are offered on a per-AZ basis, and not all instance types are available in every AZ. When a CloudFormation stack update fails with this error, it typically means the template explicitly or implicitly specifies an AZ that does not support the target instance type.
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 account does not have service limits to launch a t3.medium instance.
Why it's wrong here
Service quota errors occur when your account's per-region limits are exceeded and the message will reference a quota or limit (e.g., "instance limit exceeded"). A CloudFormation stack update that triggers this would fail before resource attribute checks, and the error would specify the number of instances vs. the quota, not an AZ-specific message. Thus this answer is wrong because the error precisely indicates an Availability Zone constraint, not a quota.
- ✗
The AMI used does not support the t3.medium instance type.
Why it's wrong here
AMI compatibility issues arise when the instance type is unsupported by the AMI's architecture (e.g., 32-bit vs 64-bit) or missing drivers, but those errors reference the AMI or the instance type, not a particular Availability Zone. Moreover, an AMI that supports t3.medium in one AZ would support it in all AZs because AMI support is independent of placement. The given error's explicit AZ mention rules this out.
- ✗
The CloudFormation template has a parameter constraint that rejects t3.medium.
Why it's wrong here
Parameter constraints defined in a CloudFormation template (e.g., AllowedValues on a string parameter) are validated during stack creation/update before any physical resources are deployed, and reject invalid values with an "Invalid parameter" or "Value ... does not satisfy the constraint" message. The error would not reference a specific Availability Zone or resource launch. Therefore it cannot be the cause here.
- ✓
The t3.medium instance type is not available in the specified Availability Zone.
Why this is correct
The error is exactly what AWS returns when you attempt to launch an EC2 instance with an instance type that is not available in the selected Availability Zone. Instance types are rolled out to AZs non-uniformly, so a t3.medium may exist in us-east-1a but not us-east-1b, for example. This is a resource-level launch failure rather than a template, account, or AMI problem.
Go deeper
Related to this question
About these practice questions
This SOA-C02 question is part of Courseiva's 1,169-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.