A decision framework for professional scenarios

Exam alignment: Applies to every scenario question in Domain 1. Professional-level questions usually present several technically possible architectures and ask for the one that best satisfies all stated constraints.

Learning objective

Extract hard requirements from a long scenario, translate them into architecture properties, eliminate invalid answers, and select the best remaining solution through explicit trade-off reasoning.

Difficulty	Intermediate
Study time	150 minutes
Prerequisites	Associate-level AWS architecture and the previous chapter lessons

Why professional scenarios feel difficult

At Associate level, a question often tests whether you recognize a service capability. At Professional level, all four options may use valid AWS services. The difference lies in how well each option satisfies availability, account boundaries, automation, rollback, security, audit, cost, and operational-effort requirements at the same time.

A plausible answer can still be wrong because it violates one sentence in the scenario. The goal is therefore not to find an option that works. It is to find the option that meets every hard requirement with the best overall trade-off.

Separate facts, goals, and constraints

Classify each important statement before comparing services.

Statement type	Example	Effect on the decision
Current-state fact	Releases are deployed manually to ECS	Explains the starting point, not necessarily the target design
Business goal	Release more frequently	Requires faster and more reliable flow
Hard constraint	No downtime is permitted	Eliminates disruptive deployment methods
Failure requirement	Roll back automatically when 5xx errors rise	Requires health evidence connected to deployment control
Security constraint	Production is in a separate account	Requires a cross-account authorization path
Operational preference	Minimize ongoing administration	Favors managed native capabilities when they meet the need
Cost preference	Minimize additional cost	Chooses among otherwise valid solutions; it rarely overrides a hard availability requirement

Background details may help establish context but do not all deserve equal weight. Words such as must, automatically, without downtime, centrally, across accounts, least privilege, and minimum operational effort frequently identify decisive constraints.

Translate requirement language into properties

Do not jump directly from a phrase to a service name. First translate it into a property.

Scenario phrase	Architecture property to seek
No downtime	Old and new capacity overlap, with controlled traffic movement
Automatic rollback	Deployment state is connected to tested alarms or failure conditions
Same artifact in every environment	Immutable versioned artifact and provenance
Across multiple accounts	Roles, trust, resource policy, and encryption authorization
Centrally enforce	Organization-aware or delegated-administrator capability
Recover within minutes	Predefined automated recovery path and ready capacity
Minimal operational effort	Managed integration with fewer custom components
Preserve evidence	Logged actions, reports, approvals, and immutable history
Changes must be reversible	Versioned state, traffic control, and tested rollback or forward recovery

Only after identifying the property should you map it to CodePipeline, CodeDeploy, ECS, Lambda aliases, CloudWatch alarms, Step Functions, or another AWS capability.

The six-pass decision method

Pass 1: identify the workload and control plane

Mark the deployment platform, accounts, Regions, artifact type, and the service that controls deployment. EC2, ECS, EKS, and Lambda have different traffic and rollback mechanics.

Pass 2: write the hard constraints

Rewrite each constraint as a short testable sentence. For example:

• Production capacity must remain available during deployment.
• The process must reverse automatically on an application-health alarm.
• The pipeline must deploy from the tooling account into production.
• The solution must not require a custom orchestration service.

Pass 3: eliminate contradictions

Remove an option immediately when it violates a hard constraint. Do not rescue it by adding features that the answer does not state.

Pass 4: verify the complete path

An answer may solve deployment but omit artifact encryption, role trust, health detection, or rollback. Follow source, artifact, identity, deployment, traffic, health, and recovery from beginning to end.

Pass 5: compare valid options

Compare only the survivors using:

1. security and least privilege
2. resilience and blast radius
3. recovery behavior
4. auditability
5. operational effort
6. cost

The scenario may change this priority. A hard cost ceiling can be decisive, but “cost-effective” usually means choose the least expensive option that still satisfies all hard requirements.

Pass 6: prove the winner and explain the runner-up

State why the winner meets each hard constraint. Then state the exact trade-off that makes the second-best answer weaker. This prevents choosing by familiarity or by the number of AWS service names in the option.

Worked scenario

Question

A company deploys an Amazon ECS service from a tooling account into a production account. Releases must have no downtime. If the new task set causes the Application Load Balancer 5xx rate to exceed a threshold, traffic must automatically return to the previous task set. The company wants the least operationally complex solution.

Which design best meets the requirements?

Options

A. Use an ECS blue/green deployment through CodeDeploy. Configure production and test listeners, a CloudWatch alarm for the ALB 5xx metric, automatic rollback, and a scoped cross-account deployment role.

B. Use an ECS rolling update. After deployment, an operator checks the CloudWatch dashboard and manually restores the previous task definition if errors increase.

C. Invoke a custom Lambda function from CodePipeline. The function creates a second ECS service, changes listener rules, polls CloudWatch, and deletes the old service.

D. Copy the container image to an EC2 instance in the production account and restart the application during the maintenance window.

Requirement extraction

Requirement	Hard or preference?
ECS workload	Platform fact
Tooling to production account	Hard security and deployment constraint
No downtime	Hard availability constraint
Automatic response to ALB 5xx	Hard failure requirement
Return to previous task set	Hard rollback requirement
Least operational complexity	Preference among valid answers

Elimination

• D is invalid because restarting one instance does not provide a no-downtime ECS deployment and ignores the specified platform.
• B is invalid because rollback is manual, while the scenario requires an automatic response.
• C can be made technically valid, but it recreates traffic shifting, state handling, retries, cleanup, and alarm evaluation with custom code.
• A meets every hard requirement using native ECS and CodeDeploy blue/green behavior, CloudWatch alarms, automatic rollback, and a cross-account role.

Best and second-best

A is best. It satisfies all hard constraints and minimizes custom operations.

C is second-best. It could meet the functional requirements, but it adds code ownership, idempotency, retry, race-condition, and cleanup responsibilities without a requirement for custom behavior. “Serverless” does not automatically mean “least operational effort.”

When managed is not automatically best

“Prefer managed services” is a useful default, not a universal rule. A managed option loses when it cannot satisfy a required behavior, platform, scale, latency, compliance boundary, or integration.

Before choosing a managed capability, verify:

• it supports the specified workload and deployment type
• it works across the required accounts and Regions
• its rollback behavior matches the failure requirement
• its quotas and execution behavior fit the scale
• it provides the required evidence and security controls
• the scenario does not explicitly require custom logic that the service cannot express

The best answer is the least complex valid answer, not simply the answer with the fewest components.

Common requirement conflicts

Lowest cost versus no downtime

Blue/green deployment temporarily runs duplicate capacity. If no downtime is hard and cost is only a preference, duplicate capacity is justified. An in-place restart is cheaper but invalid.

Fastest release versus strongest evidence

Do not remove required tests or audit controls. Instead, move fast deterministic checks earlier, parallelize independent checks, reuse one artifact, and automate evidence collection.

Automatic remediation versus blast radius

Automation must validate current state, scope, and exceptions. A manual review may be appropriate for a destructive or poorly reversible action even when detection is automatic.

Central control versus team autonomy

Use central guardrails, reusable components, and delegated roles. Central control does not require one team to execute every change manually.

Failure modes in decision reasoning

• Service-name matching: Selecting an option because it contains the service mentioned in the question.
• Single-requirement optimization: Solving cost while violating availability or security.
• Inventing missing features: Assuming an option includes alarms, encryption, or rollback when it does not say so.
• Authentication-only reasoning: Establishing role assumption but ignoring target permissions, resource policies, and KMS.
• Happy-path reasoning: Designing deployment without failure detection and recovery.
• Absolute rules: Treating “always use managed,” “always use multiple accounts,” or “always use blue/green” as universally correct.
• Longest-answer bias: Assuming more implementation detail means greater correctness.

Decision worksheet

Use this compact worksheet for practice:

Goal:
Workload/platform:
Accounts/Regions:
Artifact and source identity:

Hard constraints:
1.
2.
3.

Failure signal:
Required recovery behavior:
Security boundaries:

Option A - invalid/valid because:
Option B - invalid/valid because:
Option C - invalid/valid because:
Option D - invalid/valid because:

Best answer:
Second-best answer:
Decisive trade-off:

Hands-on lab: solve decision cards

Goal: Practice requirement extraction and elimination before service comparison.

Decision cards

For each card, create four options or use options from a practice exam.

1. A Lambda release needs 10% traffic for ten minutes and automatic rollback on errors.
2. An EC2 fleet needs no downtime, immutable hosts, and quick return to the previous version.
3. A cross-account pipeline can assume its target role but cannot decrypt the artifact.
4. Multiple commits overwrite one shared integration environment.
5. A regulated release needs accountable approval but must not rebuild after approval.
6. A pipeline must deploy the same container image across two Regions.

Tasks

1. Separate facts, hard constraints, failure requirements, and preferences.
2. Translate every hard constraint into an architecture property.
3. Eliminate options that contradict one property.
4. Trace artifact, identity, deployment, health, and recovery for the remaining options.
5. Rank the valid options by the scenario’s stated priorities.
6. Explain the winner and runner-up in two sentences each.
7. Record any AWS capability that needs documentation review.

Validation checklist

• The winner satisfies every hard constraint.
• No unstated feature was added to an answer.
• The reasoning follows the workload-specific deployment mechanics.
• Cross-account and encryption layers are evaluated separately.
• Recovery behavior is connected to a real signal.
• The second-best answer loses for one precise trade-off.

Cost control: This is a reasoning lab and requires no AWS resources.

Cleanup

No cloud cleanup is required. Remove copied proprietary practice questions from shared notes; keep only your own summaries and reasoning.

Exam traps

• Assuming the longest answer is best.
• Ignoring words such as automatically, centrally, without downtime, or across accounts.
• Choosing a custom Lambda workflow when a native capability meets all requirements.
• Choosing a native capability without verifying its workload support and rollback behavior.
• Treating “cost-effective” as “cheapest regardless of constraints.”
• Solving the normal path and ignoring failure recovery.

Key takeaways

• Extract requirements before comparing services.
• Hard constraints eliminate options; preferences rank valid survivors.
• Translate language into architecture properties before mapping to AWS capabilities.
• Verify the complete source-to-recovery path.
• Explain why the second-best answer loses.
• Prefer the least complex solution that is fully valid.

Review questions

1. What should happen before comparing AWS services?
2. What is the difference between a hard constraint and a preference?
3. Why should you not repair an answer by inventing an unstated component?
4. What does “least operational effort” usually favor?
5. When can a custom solution be better than a managed integration?
6. Why is the cheapest answer not always the most cost-effective?
7. What does explaining the runner-up prove?
8. Which paths should be traced for every deployment answer?

Model answers

1. Identify the goal, workload, accounts, hard constraints, failure signal, and recovery requirement, then translate them into architecture properties.
2. Violating a hard constraint makes an answer invalid. A preference ranks answers that already satisfy every hard constraint.
3. The exam evaluates the option as written. Adding an alarm, role, or rollback that is absent can turn an invalid answer into an imaginary one.
4. A managed native capability with fewer custom components, provided that it satisfies every functional, security, and recovery requirement.
5. When required behavior, integration, scale, policy, or recovery semantics cannot be expressed by the managed capability and the benefit justifies the added ownership.
6. Cost-effectiveness includes meeting the goal. A cheaper design that violates availability or recovery creates an unacceptable business cost and is invalid.
7. It demonstrates that you understand the decisive trade-off rather than merely recognizing the winning service name.
8. Source trigger and revision, artifact flow, identity and authorization, deployment mechanics, health evidence, and failure recovery.

Further reading

• DOP-C02 Domain 1: SDLC Automation
• AWS CodePipeline concepts
• AWS Well-Architected Operational Excellence Pillar