SOA-C02 DependsOn Practice Question
A SysOps administrator is automating the deployment of a three-tier web application using AWS CloudFormation. The administrator wants to ensure that the database tier is created before the application tier. How should the administrator define this dependency in the CloudFormation template?
⚠ Common exam trap
A common trap is to confuse the purpose of Conditions and Outputs with dependency management. Conditions only control if a resource is created, not when. Outputs are for exporting values, not for ordering.
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
✓
Use the DependsOn attribute on the application tier resources to reference the database tier resources.
CloudFormation supports the DependsOn attribute to specify resource dependencies. The application tier resources must wait for the database tier resources to be created. Option A is wrong because the Conditions section determines whether resources are created based on conditions, not the creation order. Option B is wrong because the Outputs section exports values for use in other stacks, but does not control the order of creation within the same stack. Option D is wrong because the Parameters section defines input values passed to the template, not dependencies.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use the Conditions section to check if the database exists before creating the application tier.
Why it's wrong here
The Conditions section in CloudFormation evaluates boolean expressions—typically based on parameter values—to decide whether to create a particular resource, not when to create it. Checking for the existence of a database at stack creation time is impossible with a condition; conditions are resolved at template processing time and cannot perform runtime lookups. Even if a condition could query the environment, it would only include or exclude the application tier from the stack, never order it after the database tier. Therefore, Conditions are the wrong mechanism for enforcing cross-tier creation order.
- ✗
Use the Outputs section to export the database endpoint and import it in the application tier.
Why it's wrong here
Outputs in CloudFormation are designed to return computed values from one stack so they can be consumed elsewhere, often via Exports and Fn::ImportValue in another stack. However, merely exporting the database endpoint and importing it into the application tier does not, by itself, guarantee that the application resources are created after the database resources within a single template. While cross-stack imports create a value-level dependency that can influence stack ordering between separate stacks, this option describes a value-passing pattern, not a resource-level creation-order rule. Moreover, Outputs are declared on the database stack and consumed by the application stack, but within a monolithic template they have no influence on the order of resource creation, so this is not the correct solution.
- ✓
Use the DependsOn attribute on the application tier resources to reference the database tier resources.
Why this is correct
The DependsOn attribute is the explicit way to tell AWS CloudFormation that one resource must be created before another, overriding the template's otherwise optional logical ordering. When you apply DependsOn to the application-tier resources and reference the database-tier logical IDs, CloudFormation guarantees the database stack resources are created first, and will also roll back the application tier if the database creation fails. This is necessary when the dependencies are not implicit, such as when the application code only knows the database endpoint from a parameter or discovery service rather than a Ref/GetAtt call. Therefore, DependsOn is the correct and direct mechanism for enforcing the creation sequence.
- ✗
Use the Parameters section to pass the database instance identifier to the application stack.
Why it's wrong here
Parameters are user-supplied inputs that CloudFormation reads at stack creation or update time, used to inject values like instance sizes, AMI IDs, or environment names. Passing the database instance identifier simply makes that string available to application-tier configuration, but it has no effect on the order in which resources are provisioned. CloudFormation does not infer dependencies from parameter values; ordering is determined only by explicit DependsOn or intrinsic relationships like Ref and GetAtt. Thus, Parameters are an input mechanism, not a dependency-defining construct, and they cannot ensure the database is built before the application tier.
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.