Cloud Deployment Models and Operating on AWS

Every workload has to answer two questions before it ships: where does it run? and how will we operate it again tomorrow? The exam calls this Domain 3, Task 3.1, "Define methods of deploying and operating in the AWS Cloud", and it is the most decision-shaped task on CLF-C02: AWS explicitly tests whether you can choose between the Console, programmatic access and infrastructure as code, whether a job is one-time or repeatable, and which deployment model a description matches. The trap is that Task 3.1 looks like a coding task and is not one, "Implementation" is listed as an out-of-scope job task, so you are never asked how to write the script, only which door to walk through.

In this lesson you will:

• name the four deployment models in AWS's own words and separate hybrid from multi-cloud;
• map IaaS, PaaS and SaaS to AWS examples and read the responsibility shift that each one triggers;
• choose between the Console, CLI, SDKs, APIs and IaC, and apply the one-time versus repeatable rule;
• distinguish CloudFormation from CDK (and know why Terraform is background, not syllabus);
• pick the right connectivity door: internet, Direct Connect, Site-to-Site VPN, or a VPC endpoint / PrivateLink;
• place Amplify, AppSync and IoT Core where the exam guide actually tests them;
• tell Elastic Beanstalk, Lightsail and CloudFormation apart by the job each one does;
• study four AWS-published case studies on Lightsail, repeatable operations, environment speed and migration;
• check what changed in 2026 for scope lists, console tooling and where you can provision;
• practise with 12 exam-style questions plus five interactive checks.

---

1. What Task 3.1 actually asks

1.1 The task, split into knowledge and skills

1.2 The scope line: a decision, not a build

The CLF-C02 guide lists "Implementation" among the out-of-scope job tasks. That single word reshapes every 3.1 question: an option that says "write a Python script that creates 40 subnets" or "author a CloudFormation template with inline Lambda" is describing implementation, and implementation is not what this exam measures. The correct option is always the selection: Console versus CLI versus SDK versus IaC, one-time versus repeatable, public versus hybrid.

• 📚 Did you know? AWS publishes a parity rule that kills a whole family of distractors: every IaaS administration, management and access function available in the AWS Management Console is also available in the AWS API and AWS CLI "at launch or within 180 days of launch." So the option that begins "the Console is the only way to…" is almost always wrong: the Console is simply "the most common method", not the exclusive one.

1.3 The three service lists you must keep apart

⚠️ CloudShell is the perfect distractor. AWS CloudShell is "a browser-based, pre-authenticated shell that you can launch directly from the AWS Management Console", with the AWS CLI, EB CLI, ECS CLI and SAM pre-installed (Amazon Linux 2023 image). It sounds ideal for "ways to access AWS", and it is explicitly out of scope for CLF-C02. If a question offers CloudShell next to Console, CLI, SDK and IaC, CloudShell is there to be eliminated, not selected. The same fate awaits Wavelength, IoT Greengrass and Snow Family options.

2026 Updates (as of October 2026)

---

2. Deployment models: public, private, hybrid and multi-cloud

2.1 AWS's four definitions, in AWS's own words

AWS's hybrid framing is worth memorising: "Hybrid cloud with AWS delivers a consistent AWS experience where you need it: from the cloud to on premises and at the edge", and AWS Outposts is "a family of fully managed services delivering AWS infrastructure and services to virtually any on-premises or edge location for a truly consistent hybrid experience."

2.2 Two taxonomies, and the hybrid/multi-cloud line

The exam guide says "cloud, hybrid, on-premises". AWS's what-is pages say public, private, hybrid, multi-cloud. They overlap rather than conflict:

The distinction the exam actually guards is this one:

• Hybrid = your infrastructure + one public cloud. AWS says hybrid management "can be done using services from a single cloud provider."
• Multi-cloud = services from two or more third-party cloud providers. The moment a stem says "AWS and another provider", you are in multi-cloud, not hybrid.

2.3 The AWS hybrid toolkit that is in scope

• 📚 Did you know? Outposts ships as a 42U self-contained rack needing 10 to 30 kVA, and as 1U/2U servers (sizes and power figures as of Oct 2026: verify current before use). What makes it a deployment model fact rather than a hardware fact is that an Outpost is managed "as part of an AWS Region", so the hybrid story stays one operating model: same APIs, same console, same tooling, different postcode.

---

3. Service models: IaaS, PaaS, SaaS, and the responsibility shift

3.1 The three service models

3.2 Example E1: counting the responsibility shift

The RDS documentation publishes the same nine operational rows for three environments. Count who owns each row:

Three readings follow, and all three are examinable:

1. On premises the count is 9 out of 9; you own everything including the building's power.
2. EC2 moves three rows to AWS (server maintenance, hardware lifecycle, power/cooling) but leaves six in your column; that is what "IaaS requires the customer to perform all of the necessary security configuration and management tasks" means in practice.
3. RDS flips the majority to AWS (six of nine), yet "Application optimization" stays Customer in every single column. "AWS manages the database" never means "AWS tunes your queries."

3.3 The invariant: security of vs in the Cloud

The shared responsibility model is the frame underneath all of this: AWS is responsible for security "of" the Cloud, the customer is responsible for security "in" the Cloud. For abstracted services such as Amazon S3 and Amazon DynamoDB, "AWS operates the infrastructure layer, the operating system, and platforms … Customers are responsible for managing their data … and using IAM tools." For AWS Lambda, AWS manages "the underlying infrastructure and foundation services, the operating system, and the application platform", while you own "the security of your code and AWS IAM to the Lambda service and within your function."

3.4 Patching nuance the exam sneakily tests

Not all managed services hand you the same degree of control:

⚠️ "AWS manages it" is not "AWS takes all of it". Two traps live here. First, RDS is not full delegation, application optimization, your queries, your schema and your data stay yours in every column of the matrix. Second, SaaS is not an AWS product: AWS states it does not offer SaaS services, it offers the tools to build third-party SaaS. An option claiming "WorkMail / QuickSight is AWS's SaaS offering" is unsupported by any AWS page in this research, treat it as wrong.

---

4. Ways to access AWS: Console, CLI, SDKs, APIs and IaC

4.1 The five doors (plus the one that is out of scope)

• 📚 Did you know? Amazon S3 launched on 14 March 2006 at $0.15 per GB-month, with a 5 GB maximum object size and roughly 1 PB of capacity across about 400 storage nodes; AWS now says the price is "slightly over 2 cents per gigabyte", an approximately 85% reduction, and that "the code you wrote for S3 in 2006 still works today, unchanged" (AWS News Blog, 2026-03-13; prices as of Oct 2026, verify current before use). The examinable point is the operating one: stable APIs are what make repeatable automation survive, the CLI call or SDK request you scripted years ago still works, which is precisely why AWS pairs "repeatable processes" with programmatic access.

4.2 One-time operations versus repeatable processes

This is the single most testable phrase in Task 3.1. The skill is to "evaluate requirements to determine whether to use one-time operations or repeatable processes", and AWS's IaC guidance supplies the reasoning on the other half:

AWS's own arguments for the repeatable half, quoted:

• IaC makes "new environments repeatable, reliable, and consistent";
• "write your IaC code once and deploy that same code to hundreds of environments in a fraction of the time";
• "Configuration drift occurs when the configuration that provisioned your environment no longer matches the actual environment": manual creation is "error prone", and a template is a text file, so you "simply track differences in your templates to track changes to your infrastructure."

The operating rule: when an environment has drifted, re-apply the template. Hand-editing the live resource re-creates the very drift you are trying to remove.

4.3 Example E2: the arithmetic of manual operations

Suppose 100 environments each need the same change, and a human takes 10 minutes per environment clicking through the Console:

$$T_{\text{manual}} = 100 \times 10 \text{ min} = 1{,}000 \text{ min} \approx 16.7 \text{ hours}$$

16.7 hours of undirected human effort, at 100 chances to click the wrong thing, repeated every month. AWS's IaC promise is the counter-factual: "write your IaC code once and deploy that same code to hundreds of environments in a fraction of the time." The exam does not ask you to prove this; it asks you to recognise the shape: many environments + one standard change ⇒ IaC.

4.4 Example E3: one template, four environments, drift arithmetic

The canonical repeatable pattern from AWS's CloudFormation documentation is the same 12-resource stack deployed to development, staging, production and a second AWS Region:

The examinable conclusions: a template is reused, versioned and diffed; a stack's resources are created and configured for you; and deleting the stack deletes the resources it created; which is also why IaC is the cleanest answer to "clean up this environment".

4.5 The IaC trio: CloudFormation, CDK and the third name in the room

AWS's prescriptive guidance compares five IaC tools, CloudFormation, SAM, CDK, Terraform and Pulumi, and gives the selection rule you need: "If you are managing your infrastructure entirely on AWS, then AWS CloudFormation and the AWS Cloud Development Kit (AWS CDK) are good options", while "Terraform might be a good choice because it is platform agnostic."

• 📚 Did you know? CloudFormation templates are plain text files, which is why AWS says you can "simply track differences in your templates to track changes to your infrastructure." That property is the same one that makes configuration drift detectable: diff the template against the live stack, find the hand-edits, re-apply. Infrastructure you cannot diff is infrastructure you cannot audit.

---

5. Connectivity: the four doors into and out of a VPC

5.1 The overview (in-scope services only)

5.2 Example E4: two tunnels, four numbers

AWS Site-to-Site VPN includes two tunnels per connection, and each tunnel has a bandwidth ceiling:

Two observations the exam rewards. First, the two tunnels exist for high availability, not primarily for speed, AWS says "Each VPN connection includes two VPN tunnels which you can simultaneously use for high availability." Second, bandwidth is a per-tunnel ceiling, so a stem that says "a Site-to-Site VPN connection delivers 1.25 Gbps total" is wrong by a factor of two. All figures as of Oct 2026, verify current before use.

5.3 Example E5: what a resiliency SLA costs you in minutes

Direct Connect publishes two resiliency designs. Convert the percentages into downtime budgets over a 365-day year ($8{,}760$ hours):

$$8{,}760 \times (1 - 0.999) = 8.76 \text{ hours per year}$$ $$8{,}760 \times (1 - 0.9999) = 0.876 \text{ hours} \approx 52.6 \text{ minutes per year}$$

The exam does not ask for this arithmetic; it asks you to match the requirement to the design: "steady private throughput with the tightest published availability" ⇒ Direct Connect with Maximum Resiliency; "we need a private link up this afternoon" ⇒ Site-to-Site VPN. SLA figures as of Oct 2026.

5.4 Example E6: choosing the Direct Connect port

A branch office needs 400 Mbps; the core data centre needs 100 Gbps:

Rule of thumb from the connection-options page: hosted connections scale from 50 Mbps to 25 Gbps (delivered through AWS Direct Connect partners), while dedicated connections are 1, 10, 100 or 400 Gbps. A stem quoting 50 Mbps is a hosted-port signal; a stem quoting 100 Gbps is a dedicated-port signal. Figures as of Oct 2026: verify current before use.

5.5 PrivateLink and gateway endpoints, precisely

• 📚 Did you know? VPC endpoints come in two families and the exam tests the exception: gateway endpoints (Amazon S3, Amazon DynamoDB) do not use AWS PrivateLink, while interface endpoints are the PrivateLink-powered kind. So the statement "all VPC endpoints are powered by PrivateLink" is false: one counter-example, straight from AWS's VPC documentation, is enough to sink it.

---

6. Frontend, mobile and IoT: what task 3.8 adds

Task 3.1 is about provisioning and operating; the exam guide tests frontend/mobile and IoT under Task 3.8: "Identify services from other in-scope AWS service categories." Both skills are naming skills: "Identifying the services that can create and deploy frontend and mobile services" and "Identifying the services that manage IoT devices."

6.1 AWS Amplify: the frontend and mobile answer

The word "atomic" is the tell: because a new deployment replaces the old one as a unit, a failed release does not leave a half-updated site, which is why AWS says maintenance windows disappear. Amplify is therefore also an operating story: repeatable, Git-triggered releases rather than manual uploads.

6.2 AppSync: a naming caveat

Amazon AppSync appears on neither the in-scope nor the out-of-scope list in the current CLF-C02 exam guide. Treat it as background vocabulary only: it is not examinable material, so do not memorise it as "the GraphQL answer for this exam" and do not expect it to be credited. The credited frontend/mobile service in the guide is AWS Amplify.

6.3 AWS IoT Core: the IoT answer

⚠️ Two IoT traps. First, IoT Device Defender and IoT Greengrass are out of scope, a question describing device-side Lambda execution or security-behaviour monitoring is baiting you toward services that are not on the list; the in-scope answer is AWS IoT Core. Second, IoT Device Management and IoT Analytics appear on neither list, so they are neither answers nor documented exclusions, if you see them, treat the question as testing whether you know what is listed.

---

7. Elastic Beanstalk, Lightsail and CloudFormation: three distinct roles

7.1 AWS Elastic Beanstalk: PaaS-style deployment of your code

The three-part trap in one line: $0 service charge ≠ $0 bill, because the EC2 instances, load balancer and storage it creates are billed to your account; Beanstalk is not serverless, because it provisions EC2 or EKS; and Beanstalk is not IaC, because you are handing it code, not a reusable infrastructure template.

7.2 Amazon Lightsail: the predictable-price entry point

7.3 Example E7: the Lightsail bundle, priced two ways

Bundle arithmetic:

Hourly versus monthly cap. Lightsail bills hourly but caps the charge at the monthly price. A full month is $750$ hours:

$$0.0067 \times 750 = 5.025 \text{ USD} \longrightarrow \text{capped at } 5.00 \text{ USD}$$

A partial month of $200$ hours: $0.0067 \times 200 \approx$ $1.34$. So the monthly price is a ceiling, not a floor; you pay for what you run up to the cap. All figures as of Oct 2026; sizes, tiers and prices change, so verify current before use.

7.4 Example E8: Elastic Beanstalk is $0 to run as a service

Elastic Beanstalk charges $0 for itself. The bill comes from what it creates. For illustration (teaching figures, not AWS list prices: verify current before use):

The examinable sentence: Elastic Beanstalk removes the operational work, not the resource cost.

7.5 The three-in-one decision

• 📚 Did you know? Elastic Beanstalk's application version is stored as "an Amazon Simple Storage Service (Amazon S3) object that contains the deployable code", so "where does Beanstalk keep my code?" has a one-word answer: S3. That also explains the blue/green-style versioning: you promote a different S3 object as the current version, and the environment's configuration stays describable as data rather than as clicks.

---

Real-World Case Studies

AWS publishes what these choices look like in production. Every figure below is customer- or AWS-claimed and unaudited, with the source named so you can check it: the examinable point is the pattern (which deployment model, which access method, which operating habit), not the marketing number.

Case A, Gourmeat: Lightsail as the small predictable entry point

Exam lesson: this is the Lightsail answer in human form, the value claimed is operational (hours of manual reporting removed, one predictable monthly bill), not a raw compute benchmark. The exam question built from this pattern asks "small team, few instances, wants a predictable monthly price", and Lightsail is the option to reach for, with Elastic Beanstalk as the near-miss (also low-ops, but priced per underlying resource rather than bundled).

Case B, athenahealth: repeatable operations across 120 accounts

Exam lesson: this is Task 3.1's "repeatable processes" line with numbers attached. CloudFormation rules-as-code is the mechanism, AWS RAM is the distribution method, and Direct Connect is the connectivity door. Eight people could not hand-configure hundreds of VPCs across 120 accounts in a few days: the arithmetic only closes when the change is written once and applied many times, which is precisely the IaC argument from Section 4.

Case C, Capital One: development environments from months to minutes

Exam lesson: "3 months to minutes" is the one-time-versus-repeatable rule with a clock attached. A three-month lead time is what a one-time, manually assembled environment costs when every request is bespoke; "minutes" is what the same environment costs when the build is a repeatable process you re-run on demand. The deployment-model reading is equally clean: an estate with zero on-premises remainder is the public cloud illustration at enterprise scale: hybrid would require the data centres to stay, and multi-cloud would require a second public provider. And the arithmetic underneath is the one from Section 4: 90 days of lead time removed per environment compounds across an 11,000-person engineering organisation.

• 📚 Did you know? Capital One's case study says the bank "exited eight on-premises data centers" and "built 80 percent of the nearly 2,000 applications it now runs in the cloud from the ground up" (AWS case study, accessed Oct 2026). The deployment-model tell is the phrase "all in": nothing is left running on premises, so the deployment model is public cloud, not hybrid: a regulated industry choosing public cloud does not turn the answer into "private" or "hybrid" on exam day.

Case D, Bangkok Flight Services: a repeatable migration with multi-AZ operations

Exam lesson: two patterns meet here. The migration itself is a repeatable process, one rehost method, applied estate-wide, finished in seven months with no rollback, which is the opposite of a series of heroic one-time events. The operations after it are also repeatable: CloudWatch and CloudTrail supply the observing, and the Availability Zone is the fault-isolation unit the recovery design operates within (an AZ protects against a data-centre-level failure inside a Region; a second Region is what protects against a Region-level failure). Scope caveat worth memorising: AWS Application Migration Service appears in this case study, but a case study never makes a service examinable, only the current exam guide's in-scope list does. Check the list, not the story.

What both cases share

What Cases C and D add

⚠️ How to read case-study numbers on exam day: every percentage here is customer-claimed and unaudited, and "up to" is a ceiling, never an average. Attribute the source and date: "athenahealth case study, accessed Oct 2026", not "AWS proves". A case never licenses an out-of-scope answer: you are asked to select the pattern (Lightsail for a small predictable bundle; IaC for many accounts), never to reproduce the marketing figure. The Gourmeat figures are from an October 2020 case study and are reported as AWS published them.

---

Practice Questions