[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"lesson-cloud-computing-fundamentals-cloud-services-and-architecture-modern-cloud-architectures-containers-and-microservices-en":4,"next-cloud-computing-fundamentals-cloud-services-and-architecture-modern-cloud-architectures-containers-and-microservices-en":526,"prev-cloud-computing-fundamentals-cloud-services-and-architecture-modern-cloud-architectures-containers-and-microservices-en":907},null,{"locked":5,"reason":3,"meta":6,"item":17},false,{"title":7,"description":8,"isFree":5,"estimatedMinutes":9,"difficulty":10,"learningObjectives":11},"Containers and Microservices","What a container actually packages, why splitting a monolith into microservices changes how a team ships and scales, and what an orchestrator like Kubernetes adds once you have more containers than you can manage by hand.",19,"intermediate",[12,13,14,15,16],"Explain what a container is and why it starts faster than a virtual machine","Describe how a container image keeps the runtime environment identical from a laptop to production","Distinguish a monolithic application from a microservices architecture by how each one is deployed and scaled","Identify what container orchestration adds on top of running individual containers by hand","Recognize the operational tradeoffs microservices introduce in exchange for independent scaling and deployment",{"id":18,"title":7,"body":19,"description":8,"difficulty":10,"estimatedMinutes":9,"extension":446,"infographics":447,"isFree":5,"learningObjectives":459,"meta":460,"navigation":461,"path":462,"quiz":463,"seo":523,"stem":524,"__hash__":525},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/02-containers-and-microservices.md",{"type":20,"value":21,"toc":437},"minimark",[22,27,31,35,38,86,129,144,148,151,156,159,163,166,170,176,364,370,374,426,430,433],[23,24,26],"h2",{"id":25},"the-last-lesson-answered-who-runs-the-code-this-one-asks-how-it-is-built","The last lesson answered who runs the code. This one asks how it is built",[28,29,30],"p",{},"The last lesson left compute answered: a serverless function, a virtual machine, or something in between runs your code, and the provider handles more or less of the surrounding work depending on which you pick. None of that says anything about how the application itself is put together. An application that started as one large codebase, one deployment, one team, runs into a specific kind of trouble as it grows: a small fix to the checkout flow means testing and redeploying the entire application, catalog, accounts, and all, and a traffic spike in one part of the app forces you to scale the whole thing. Containers and microservices are 2 separate ideas that, together, solve exactly that problem.",[23,32,34],{"id":33},"what-a-container-actually-packages","What a container actually packages",[28,36,37],{},"A container is an isolated process bundled with everything it needs to run: your code, its runtime, and its dependencies, all in one self-contained unit. Package a Node.js application into a container image and that image runs identically whether it started on a developer's laptop, a test server, or a production cluster, because the image carries its own runtime instead of depending on whatever happens to be installed on the host.",[39,40,45],"pre",{"className":41,"code":42,"language":43,"meta":44,"style":44},"language-dockerfile shiki shiki-themes material-theme-lighter github-light github-dark","FROM node:20-slim\nWORKDIR /app\nCOPY package*.json ./\nRUN npm install --production\nCOPY . .\nCMD [\"node\", \"server.js\"]\n","dockerfile","",[46,47,48,56,62,68,74,80],"code",{"__ignoreMap":44},[49,50,53],"span",{"class":51,"line":52},"line",1,[49,54,55],{},"FROM node:20-slim\n",[49,57,59],{"class":51,"line":58},2,[49,60,61],{},"WORKDIR /app\n",[49,63,65],{"class":51,"line":64},3,[49,66,67],{},"COPY package*.json ./\n",[49,69,71],{"class":51,"line":70},4,[49,72,73],{},"RUN npm install --production\n",[49,75,77],{"class":51,"line":76},5,[49,78,79],{},"COPY . .\n",[49,81,83],{"class":51,"line":82},6,[49,84,85],{},"CMD [\"node\", \"server.js\"]\n",[39,87,91],{"className":88,"code":89,"language":90,"meta":44,"style":44},"language-bash shiki shiki-themes material-theme-lighter github-light github-dark","docker build -t checkout-service:1.0 .\ndocker run -p 3000:3000 checkout-service:1.0\n","bash",[46,92,93,113],{"__ignoreMap":44},[49,94,95,99,103,107,110],{"class":51,"line":52},[49,96,98],{"class":97},"sbgvK","docker",[49,100,102],{"class":101},"s_sjI"," build",[49,104,106],{"class":105},"stzsN"," -t",[49,108,109],{"class":101}," checkout-service:1.0",[49,111,112],{"class":101}," .\n",[49,114,115,117,120,123,126],{"class":51,"line":58},[49,116,98],{"class":97},[49,118,119],{"class":101}," run",[49,121,122],{"class":105}," -p",[49,124,125],{"class":101}," 3000:3000",[49,127,128],{"class":101}," checkout-service:1.0\n",[28,130,131,132,135,136,139,140,143],{},"That ",[46,133,134],{},"Dockerfile"," describes the image; ",[46,137,138],{},"docker build"," packages it; ",[46,141,142],{},"docker run"," starts a container from it. The compute lesson already placed containers on the control-versus-convenience spectrum, starting in seconds instead of a virtual machine's minutes, because a container shares the host operating system's kernel instead of booting a full guest OS of its own.",[23,145,147],{"id":146},"from-monolith-to-microservices","From monolith to microservices",[28,149,150],{},"A monolith is one codebase, one deployment, and usually one shared database, no matter how many distinct features it contains. A microservices architecture splits that same application into a suite of small, independently deployable services, each built around one business capability (catalog, cart, checkout, user accounts) and communicating over lightweight APIs rather than in-process function calls. Each service typically owns its own database instead of sharing one, which is what makes it deployable and scalable on its own.",[152,153],"infographic",{"alt":154,"slug":155},"A side-by-side comparison of a monolith, one codebase and one database, against a microservices architecture split into independent services each with its own database.","containers-and-microservices-monolith-vs-microservices",[28,157,158],{},"Go back to the flash-sale scenario. In a monolith, a tripling of checkout traffic forces you to scale the entire deployment, catalog and accounts included, since there is only one deployable unit to scale. Split into microservices, the checkout service scales on its own, and catalog and accounts stay exactly as they were, because each one is now a separate, independently deployable piece.",[23,160,162],{"id":161},"the-trade-you-make-independence-for-coordination","The trade you make: independence for coordination",[28,164,165],{},"None of this is free. Splitting a monolith into microservices trades a single codebase's simplicity for a set of new problems that only show up once services are separate. A call from checkout to the user service now crosses a network instead of calling a function in the same process, which means it can time out or fail in ways an in-process call never could. Decentralized data, each service with its own database, means giving up one shared transaction across the whole request in favor of eventual consistency between services. And a single customer request that touches 5 services is harder to debug than one that touches one, since there is no longer a single stack trace to read. More services is not automatically better; it is a deliberate trade of simplicity for independence, one that only pays off once a team has the operational tooling to manage it, which is exactly what the next lesson covers.",[23,167,169],{"id":168},"orchestration-managing-more-containers-than-a-human-can-track","Orchestration: managing more containers than a human can track",[28,171,172,173,175],{},"Run one container by hand and ",[46,174,142],{}," is enough. Run 3 replicas of a checkout service for redundancy, plus a catalog service, plus a cart service, each with its own replicas, and manually watching all of them stops working quickly. A container orchestrator like Kubernetes takes a declarative description of what you want and continuously works to make reality match it.",[39,177,181],{"className":178,"code":179,"language":180,"meta":44,"style":44},"language-yaml shiki shiki-themes material-theme-lighter github-light github-dark","apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: checkout-service\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: checkout-service\n  template:\n    metadata:\n      labels:\n        app: checkout-service\n    spec:\n      containers:\n        - name: checkout\n          image: checkout-service:2.1\n          ports:\n            - containerPort: 8080\n","yaml",[46,182,183,196,206,214,224,231,242,250,258,268,276,284,292,302,310,318,332,343,351],{"__ignoreMap":44},[49,184,185,189,193],{"class":51,"line":52},[49,186,188],{"class":187},"sQzsp","apiVersion",[49,190,192],{"class":191},"sP7_E",":",[49,194,195],{"class":101}," apps/v1\n",[49,197,198,201,203],{"class":51,"line":58},[49,199,200],{"class":187},"kind",[49,202,192],{"class":191},[49,204,205],{"class":101}," Deployment\n",[49,207,208,211],{"class":51,"line":64},[49,209,210],{"class":187},"metadata",[49,212,213],{"class":191},":\n",[49,215,216,219,221],{"class":51,"line":70},[49,217,218],{"class":187},"  name",[49,220,192],{"class":191},[49,222,223],{"class":101}," checkout-service\n",[49,225,226,229],{"class":51,"line":76},[49,227,228],{"class":187},"spec",[49,230,213],{"class":191},[49,232,233,236,238],{"class":51,"line":82},[49,234,235],{"class":187},"  replicas",[49,237,192],{"class":191},[49,239,241],{"class":240},"srdBf"," 3\n",[49,243,245,248],{"class":51,"line":244},7,[49,246,247],{"class":187},"  selector",[49,249,213],{"class":191},[49,251,253,256],{"class":51,"line":252},8,[49,254,255],{"class":187},"    matchLabels",[49,257,213],{"class":191},[49,259,261,264,266],{"class":51,"line":260},9,[49,262,263],{"class":187},"      app",[49,265,192],{"class":191},[49,267,223],{"class":101},[49,269,271,274],{"class":51,"line":270},10,[49,272,273],{"class":187},"  template",[49,275,213],{"class":191},[49,277,279,282],{"class":51,"line":278},11,[49,280,281],{"class":187},"    metadata",[49,283,213],{"class":191},[49,285,287,290],{"class":51,"line":286},12,[49,288,289],{"class":187},"      labels",[49,291,213],{"class":191},[49,293,295,298,300],{"class":51,"line":294},13,[49,296,297],{"class":187},"        app",[49,299,192],{"class":191},[49,301,223],{"class":101},[49,303,305,308],{"class":51,"line":304},14,[49,306,307],{"class":187},"    spec",[49,309,213],{"class":191},[49,311,313,316],{"class":51,"line":312},15,[49,314,315],{"class":187},"      containers",[49,317,213],{"class":191},[49,319,321,324,327,329],{"class":51,"line":320},16,[49,322,323],{"class":191},"        -",[49,325,326],{"class":187}," name",[49,328,192],{"class":191},[49,330,331],{"class":101}," checkout\n",[49,333,335,338,340],{"class":51,"line":334},17,[49,336,337],{"class":187},"          image",[49,339,192],{"class":191},[49,341,342],{"class":101}," checkout-service:2.1\n",[49,344,346,349],{"class":51,"line":345},18,[49,347,348],{"class":187},"          ports",[49,350,213],{"class":191},[49,352,353,356,359,361],{"class":51,"line":9},[49,354,355],{"class":191},"            -",[49,357,358],{"class":187}," containerPort",[49,360,192],{"class":191},[49,362,363],{"class":240}," 8080\n",[28,365,131,366,369],{},[46,367,368],{},"replicas: 3"," line is a declaration, not a one-time command. If one of the 3 crashes, Kubernetes notices the mismatch between the declared state and reality and starts a replacement automatically, a capability called self-healing. Kubernetes also handles service discovery and load balancing across those replicas, and rolls updates out gradually instead of all at once, so a team stops babysitting containers by hand and starts describing the state they want instead.",[23,371,373],{"id":372},"exam-cues-spotting-the-fit-in-a-scenario","Exam cues: spotting the fit in a scenario",[375,376,377,390],"table",{},[378,379,380],"thead",{},[381,382,383,387],"tr",{},[384,385,386],"th",{},"The scenario says...",[384,388,389],{},"Points to",[391,392,393,402,410,418],"tbody",{},[381,394,395,399],{},[396,397,398],"td",{},"\"Package once, run identically everywhere\"",[396,400,401],{},"Container",[381,403,404,407],{},[396,405,406],{},"\"Independent teams ship independently, each owns its own data\"",[396,408,409],{},"Microservices",[381,411,412,415],{},[396,413,414],{},"\"Automatically restart failed instances, roll updates out gradually\"",[396,416,417],{},"Container orchestration (Kubernetes)",[381,419,420,423],{},[396,421,422],{},"\"One codebase, one deployment, one database\"",[396,424,425],{},"Monolith",[23,427,429],{"id":428},"where-this-leaves-you","Where this leaves you",[28,431,432],{},"Splitting an application into microservices and packaging each piece as a container are 2 separate decisions that happen to reinforce each other: the independent deployability microservices promise only holds up if each piece can actually ship and scale on its own, and a container is exactly what makes that practical. None of it, the builds, the rollouts, the ever-growing number of moving pieces, stays manageable by hand for long. The next lesson covers the practices and tooling, DevOps and infrastructure as code, that keep it manageable.",[434,435,436],"style",{},"html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html pre.shiki code .sbgvK, html code.shiki .sbgvK{--shiki-light:#E2931D;--shiki-default:#6F42C1;--shiki-dark:#B392F0}html pre.shiki code .s_sjI, html code.shiki .s_sjI{--shiki-light:#91B859;--shiki-default:#032F62;--shiki-dark:#9ECBFF}html pre.shiki code .stzsN, html code.shiki .stzsN{--shiki-light:#91B859;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .sQzsp, html code.shiki .sQzsp{--shiki-light:#E53935;--shiki-default:#22863A;--shiki-dark:#85E89D}html pre.shiki code .sP7_E, html code.shiki .sP7_E{--shiki-light:#39ADB5;--shiki-default:#24292E;--shiki-dark:#E1E4E8}html pre.shiki code .srdBf, html code.shiki .srdBf{--shiki-light:#F76D47;--shiki-default:#005CC5;--shiki-dark:#79B8FF}",{"title":44,"searchDepth":64,"depth":64,"links":438},[439,440,441,442,443,444,445],{"id":25,"depth":58,"text":26},{"id":33,"depth":58,"text":34},{"id":146,"depth":58,"text":147},{"id":161,"depth":58,"text":162},{"id":168,"depth":58,"text":169},{"id":372,"depth":58,"text":373},{"id":428,"depth":58,"text":429},"md",[448],{"slug":155,"concept":449,"style":450,"aspectRatio":451,"labels":452},"A 2-panel side-by-side comparison. The left panel, labeled Monolith, shows a single large block containing UI, business logic, and data access, connected to one shared database icon. The right panel, labeled Microservices, shows 4 small independent boxes (Catalog, Cart, Checkout, User), each connected to its own small database icon, with thin arrows between boxes showing API calls. The monolith panel emphasizes one solid mass; the microservices panel emphasizes separation and multiple small parts. A footer strip carries the takeaway that splitting the code is the point, containers just make each piece easy to ship.","comparison","16:9",[453,454,455,456,457,458],"Monolith: one codebase, one deployment, one shared database.","A fix to checkout means redeploying the entire application.","Microservices: independent services, independent deployments.","Catalog, Cart, Checkout, and User each own their own database.","A fix to checkout redeploys only the checkout service.","Splitting the code is the point. Containers just make each piece easy to ship.",[12,13,14,15,16],{},true,"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/02-containers-and-microservices",{"passingScore":464,"questions":465},70,[466,475,483,489,497,507,515],{"question":467,"type":468,"options":469,"correctAnswer":470,"explanation":474},"According to Docker's own documentation, what is a container, most fundamentally?","single",[470,471,472,473],"An isolated process bundled with everything it needs to run, sharing the host's kernel","A lightweight virtual machine with its own kernel","A cloud region reserved for one customer","A serverless function with a longer timeout","A container packages an application with its code, libraries, and dependencies into one self-contained, isolated process. Unlike a virtual machine, it shares the host operating system's kernel instead of running a full guest OS of its own.",{"question":476,"type":468,"options":477,"correctAnswer":481,"explanation":482},"Why does a container typically start in seconds while a comparable virtual machine takes minutes?",[478,479,480,481],"Containers use faster physical hard drives","Containers do not run any code, only configuration","Containers are always smaller in file size than any virtual machine image","A container shares the host operating system's kernel instead of booting its own, while a virtual machine boots a complete guest OS","Booting a full guest operating system, the way a virtual machine does, takes minutes. A container skips that step entirely by reusing the host's already-running kernel, so starting one is closer to starting a regular process than booting a computer.",{"question":484,"type":468,"options":485,"correctAnswer":487,"explanation":488},"A microservices architecture is defined mainly by how many servers an application runs on, not by how its code is organized into services.",[486,487],"True","False","Microservices are defined by organization, not server count: a single application built as a suite of small, independently deployable services, each built around a business capability and communicating over lightweight APIs. The same architecture could run on many servers or, at small scale, surprisingly few.",{"question":490,"type":468,"options":491,"correctAnswer":493,"explanation":496},"An online store built as microservices sees checkout traffic triple during a flash sale, while catalog browsing and account traffic stay flat. What can the team do that a monolith could not do as cleanly?",[492,493,494,495],"Nothing, containers do not change how scaling works","Scale only the checkout service, leaving catalog and user services untouched","Switch the whole application to serverless functions automatically","Redeploy the entire application to add more capacity everywhere","Because each microservice deploys and scales independently, the team can add capacity to checkout alone. A monolith bundles catalog, cart, checkout, and accounts into one deployable unit, so scaling it means scaling all of it, whether the extra capacity is needed there or not.",{"question":498,"type":499,"options":500,"correctAnswers":505,"explanation":506},"Which of the following are real costs a team takes on when it splits a monolith into microservices? (Select all that apply.)","multiple",[501,502,503,504],"Calls between services now cross a network and can fail in ways an in-process function call cannot","Each service can choose its own database, which trades strict consistency for eventual consistency across services","The application automatically becomes cheaper to run","Debugging a request that touches 5 services requires tracing across all of them, not just reading one stack trace",[501,502,504],"Microservices trade a monolith's simplicity for independence, and that trade has real costs: network calls can fail where a function call cannot, decentralized data means accepting eventual consistency instead of one shared transaction, and a single request's path across several services is harder to trace than one stack trace. None of that makes the application automatically cheaper; it can just as easily cost more to run and operate.",{"question":508,"type":468,"options":509,"correctAnswer":512,"explanation":514},"A team runs 3 replicas of a checkout service container, and one crashes under load. Which capability of a container orchestrator like Kubernetes addresses this automatically?",[510,511,512,513],"Encryption at rest","Automatic code review","Self-healing: it detects the failed replica and starts a replacement to match the declared desired state","Currency conversion for international customers","An orchestrator like Kubernetes continuously compares the actual state of the system to the desired state you declared, 3 healthy replicas, and starts a replacement the moment one falls short. That self-healing is exactly what running containers by hand with no orchestrator would leave to a human to notice and fix.",{"question":516,"type":468,"options":517,"correctAnswer":518,"explanation":522},"A Kubernetes Deployment file declares \"replicas: 3\" and Kubernetes continuously works to keep exactly 3 healthy copies running. What broader practice, covered in the next lesson, generalizes this same idea to a team's entire infrastructure?",[518,519,520,521],"Infrastructure as code: describing the desired state of infrastructure in a file instead of configuring it by hand","Vertical scaling","The shared responsibility model","Choosing a service model","Declaring \"replicas: 3\" and letting Kubernetes reconcile reality to match is the same underlying idea infrastructure as code applies to servers, networks, and every other piece of infrastructure: describe the state you want, let a tool make it happen and keep it that way.",{"title":7,"description":8},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/02-containers-and-microservices","K33r70KDceWTgfhJn0KUHnXkUJutK27cms9eEqIJoqU",{"locked":5,"reason":3,"meta":527,"item":536},{"title":528,"description":529,"isFree":5,"estimatedMinutes":9,"difficulty":10,"learningObjectives":530},"DevOps and Infrastructure as Code","How development and operations merged into one continuous practice, what each stage of a CI/CD pipeline catches, and how describing infrastructure as code, instead of clicking through a console, keeps environments consistent and reproducible.",[531,532,533,534,535],"Explain what DevOps changes about how development and operations teams work together","Describe the stages of a CI/CD pipeline and what each stage catches before a change reaches production","Explain how infrastructure as code replaces manual console changes with versioned, declarative configuration","Identify configuration drift and why it happens when infrastructure is changed outside its code definition","Compare a declarative infrastructure-as-code tool's plan-then-apply workflow to making the same change by hand",{"id":537,"title":528,"body":538,"description":529,"difficulty":10,"estimatedMinutes":9,"extension":446,"infographics":837,"isFree":5,"learningObjectives":848,"meta":849,"navigation":461,"path":850,"quiz":851,"seo":904,"stem":905,"__hash__":906},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/03-devops-and-infrastructure-as-code.md",{"type":20,"value":539,"toc":828},[540,544,547,551,554,558,630,634,637,735,739,742,764,767,771,774,776,820,822,825],[23,541,543],{"id":542},"the-last-lesson-left-you-with-more-moving-pieces-than-one-deployment-can-handle","The last lesson left you with more moving pieces than one deployment can handle",[28,545,546],{},"The last lesson left you with a team running a growing number of independently deployable services, each shipping on its own schedule. Shipping one application by hand, tested manually and copied onto a server by whoever was on duty, was already slow and error-prone. Shipping 10 services that way is not just slower, it stops being something a person can reliably do at all. DevOps, and the practices built around it, exist to answer exactly that problem.",[23,548,550],{"id":549},"what-devops-actually-changes","What DevOps actually changes",[28,552,553],{},"Before DevOps, development and operations were usually 2 separate teams: developers wrote code and handed it off, operations deployed and ran it, and each side blamed the other when a release broke something. DevOps, in AWS's own framing, is a combination of cultural philosophies, practices, and tools that increases an organization's ability to deliver applications and services at high velocity. In practice, that means the same team writes, tests, deploys, and operates its own services, which gives that team a direct incentive to make deployment itself fast and safe, instead of throwing a build over a wall and hoping.",[23,555,557],{"id":556},"continuous-integration-continuous-delivery-what-actually-happens-at-each-stage","Continuous integration, continuous delivery: what actually happens at each stage",[375,559,560,573],{},[378,561,562],{},[381,563,564,567,570],{},[384,565,566],{},"Stage",[384,568,569],{},"What happens",[384,571,572],{},"What it catches",[391,574,575,586,597,608,619],{},[381,576,577,580,583],{},[396,578,579],{},"Source",[396,581,582],{},"A developer commits code to a shared repository",[396,584,585],{},"Nothing yet, this just starts the pipeline",[381,587,588,591,594],{},[396,589,590],{},"Build",[396,592,593],{},"The code compiles and packages into a deployable artifact",[396,595,596],{},"Syntax errors, missing dependencies",[381,598,599,602,605],{},[396,600,601],{},"Test",[396,603,604],{},"An automated test suite runs against the build",[396,606,607],{},"Regressions in existing behavior",[381,609,610,613,616],{},[396,611,612],{},"Staging",[396,614,615],{},"The build deploys to a pre-production environment",[396,617,618],{},"Integration and configuration problems",[381,620,621,624,627],{},[396,622,623],{},"Production",[396,625,626],{},"The build deploys to live users",[396,628,629],{},"Nothing further, this is the release",[152,631],{"alt":632,"slug":633},"A timeline of a CI/CD pipeline moving from source through build, test, staging, and production, looping back to source for the next commit.","devops-and-infrastructure-as-code-cicd-pipeline",[28,635,636],{},"Follow one commit through it. A developer pushes a fix to the checkout service from the last lesson. Continuous integration builds a new container image and runs the test suite against it; if a test fails, the pipeline stops right there, and the change never reaches staging, let alone production. If every test passes, continuous delivery takes over, deploying the same build to staging automatically, and, once checks there pass, promoting that exact build to production. No stage is skipped, and no human copies a file by hand.",[39,638,640],{"className":178,"code":639,"language":180,"meta":44,"style":44},"name: ci\non: [push]\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v4\n      - run: docker build -t checkout-service:${{ github.sha }} .\n      - run: docker run checkout-service:${{ github.sha }} npm test\n",[46,641,642,652,669,676,683,693,700,713,724],{"__ignoreMap":44},[49,643,644,647,649],{"class":51,"line":52},[49,645,646],{"class":187},"name",[49,648,192],{"class":191},[49,650,651],{"class":101}," ci\n",[49,653,654,658,660,663,666],{"class":51,"line":58},[49,655,657],{"class":656},"syTEX","on",[49,659,192],{"class":191},[49,661,662],{"class":191}," [",[49,664,665],{"class":101},"push",[49,667,668],{"class":191},"]\n",[49,670,671,674],{"class":51,"line":64},[49,672,673],{"class":187},"jobs",[49,675,213],{"class":191},[49,677,678,681],{"class":51,"line":70},[49,679,680],{"class":187},"  build-and-test",[49,682,213],{"class":191},[49,684,685,688,690],{"class":51,"line":76},[49,686,687],{"class":187},"    runs-on",[49,689,192],{"class":191},[49,691,692],{"class":101}," ubuntu-latest\n",[49,694,695,698],{"class":51,"line":82},[49,696,697],{"class":187},"    steps",[49,699,213],{"class":191},[49,701,702,705,708,710],{"class":51,"line":244},[49,703,704],{"class":191},"      -",[49,706,707],{"class":187}," uses",[49,709,192],{"class":191},[49,711,712],{"class":101}," actions/checkout@v4\n",[49,714,715,717,719,721],{"class":51,"line":252},[49,716,704],{"class":191},[49,718,119],{"class":187},[49,720,192],{"class":191},[49,722,723],{"class":101}," docker build -t checkout-service:${{ github.sha }} .\n",[49,725,726,728,730,732],{"class":51,"line":260},[49,727,704],{"class":191},[49,729,119],{"class":187},[49,731,192],{"class":191},[49,733,734],{"class":101}," docker run checkout-service:${{ github.sha }} npm test\n",[23,736,738],{"id":737},"infrastructure-as-code-the-same-idea-aimed-at-infrastructure","Infrastructure as code: the same idea, aimed at infrastructure",[28,740,741],{},"CI/CD automates shipping application code. Infrastructure as code applies the same discipline to the servers, networks, and services that code runs on: provisioning and managing infrastructure using code instead of manual processes and console clicks. A storage bucket created by clicking through a console leaves no record of who created it, why, or how to recreate it. The same bucket declared in a file does.",[39,743,747],{"className":744,"code":745,"language":746,"meta":44,"style":44},"language-hcl shiki shiki-themes material-theme-lighter github-light github-dark","resource \"aws_s3_bucket\" \"uploads\" {\n  bucket = \"my-app-uploads\"\n}\n","hcl",[46,748,749,754,759],{"__ignoreMap":44},[49,750,751],{"class":51,"line":52},[49,752,753],{},"resource \"aws_s3_bucket\" \"uploads\" {\n",[49,755,756],{"class":51,"line":58},[49,757,758],{},"  bucket = \"my-app-uploads\"\n",[49,760,761],{"class":51,"line":64},[49,762,763],{},"}\n",[28,765,766],{},"Tools like Terraform work in 3 steps: write the configuration, plan (preview exactly what will be created, changed, or destroyed to match it), and apply (execute those changes in the right dependency order). That configuration is declarative: it describes the end state you want, not the individual commands to get there, and the tool works out the rest.",[23,768,770],{"id":769},"the-misconception-a-quick-manual-fix-in-the-console-is-fine","The misconception: \"a quick manual fix in the console is fine\"",[28,772,773],{},"It is tempting to think a fast fix in the console, bumping an overloaded instance's memory at 2 a.m. during an incident, is harmless as long as it solves the immediate problem. It is not: the infrastructure-as-code file still describes the old, smaller instance, so the code and the real infrastructure have quietly drifted apart. The next time someone applies that code, it can revert the emergency fix without anyone intending it to, or the team simply stops trusting the code to reflect what is actually running. Configuration drift is the name for that gap, and the fix is discipline, not cleverness: update the code to match the emergency change immediately, or revert the manual change and make the same fix through the code instead.",[23,775,373],{"id":372},[375,777,778,786],{},[378,779,780],{},[381,781,782,784],{},[384,783,386],{},[384,785,389],{},[391,787,788,796,804,812],{},[381,789,790,793],{},[396,791,792],{},"\"Automated build, test, and deploy on every commit\"",[396,794,795],{},"CI/CD pipeline",[381,797,798,801],{},[396,799,800],{},"\"Infrastructure defined in version-controlled files\"",[396,802,803],{},"Infrastructure as code",[381,805,806,809],{},[396,807,808],{},"\"A manual change made outside the deployment pipeline\"",[396,810,811],{},"Configuration drift risk",[381,813,814,817],{},[396,815,816],{},"\"Preview changes before they are applied\"",[396,818,819],{},"Declarative infrastructure-as-code plan step",[23,821,429],{"id":428},[28,823,824],{},"DevOps, CI/CD, and infrastructure as code are what make everything the last 2 lessons covered sustainable at real scale: a serverless function or a container image is only as reliable as the pipeline that builds, tests, and ships it, and the infrastructure it runs on is only as consistent as the code that describes it. The next domain in this course turns to what keeps systems secure and available once they are running, the shared responsibility model, identity, encryption, and disaster recovery, practices that infrastructure as code makes far easier to enforce the same way across every environment a team has.",[434,826,827],{},"html pre.shiki code .sQzsp, html code.shiki .sQzsp{--shiki-light:#E53935;--shiki-default:#22863A;--shiki-dark:#85E89D}html pre.shiki code .sP7_E, html code.shiki .sP7_E{--shiki-light:#39ADB5;--shiki-default:#24292E;--shiki-dark:#E1E4E8}html pre.shiki code .s_sjI, html code.shiki .s_sjI{--shiki-light:#91B859;--shiki-default:#032F62;--shiki-dark:#9ECBFF}html pre.shiki code .syTEX, html code.shiki .syTEX{--shiki-light:#FF5370;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":44,"searchDepth":64,"depth":64,"links":829},[830,831,832,833,834,835,836],{"id":542,"depth":58,"text":543},{"id":549,"depth":58,"text":550},{"id":556,"depth":58,"text":557},{"id":737,"depth":58,"text":738},{"id":769,"depth":58,"text":770},{"id":372,"depth":58,"text":373},{"id":428,"depth":58,"text":429},[838],{"slug":633,"concept":839,"style":840,"aspectRatio":451,"labels":841},"A left-to-right timeline of a CI/CD pipeline with 5 stages: Source, Build, Test, Staging, Production. An arrow loops from Production back to Source, labeled 'next commit', to show the pipeline repeats continuously. A footer strip carries the takeaway that each stage automatically gates the next, so a failure at any stage stops the pipeline before it reaches production.","timeline",[842,843,844,845,846,847],"Source: a developer commits code to a shared repository.","Build: the code compiles and packages into a deployable artifact.","Test: automated tests run against the build.","Staging: the build deploys to a pre-production environment.","Production: the build deploys to live users.","A failure at any stage stops the pipeline before it reaches production.",[531,532,533,534,535],{},"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/03-devops-and-infrastructure-as-code",{"passingScore":464,"questions":852},[853,861,868,872,880,889,897],{"question":854,"type":468,"options":855,"correctAnswer":856,"explanation":860},"According to AWS's definition, DevOps is best described as...",[856,857,858,859],"A combination of cultural philosophies, practices, and tools that helps deliver applications faster and more reliably","A single tool that automates deployments","A job title for someone who only writes deployment scripts","A cloud service that replaces the need for a development team","DevOps is not one tool or one job title, it is development and operations teams sharing responsibility for the entire application lifecycle, supported by the practices and tools that make frequent, reliable releases possible.",{"question":862,"type":468,"options":863,"correctAnswer":865,"explanation":867},"A commit triggers an automated process that compiles the code and runs the test suite, stopping immediately if anything fails. What part of the pipeline is this?",[864,865,803,866],"Configuration drift","Continuous integration","Continuous delivery","Continuous integration is the practice of merging code changes frequently and running automated builds and tests against them, catching bugs at the build and test stages before the change goes anywhere near production. Continuous delivery picks up from there, automating the path to staging and production.",{"question":869,"type":468,"options":870,"correctAnswer":487,"explanation":871},"As long as an emergency fix made directly in the cloud console solves the immediate problem, it is fine to leave the infrastructure-as-code files unchanged.",[486,487],"A console change that never makes it into the code creates configuration drift: the code no longer describes reality. The next time someone applies that code, it can silently revert the emergency fix, or leave the team unable to trust the code as an accurate source of truth at all. The fix needs to be reflected in the code, or reverted and reapplied through it.",{"question":873,"type":468,"options":874,"correctAnswer":877,"explanation":879},"A team edits a Terraform configuration file to add a new storage bucket, then runs the tool's preview step before making any change to the real infrastructure. What does this step show them?",[875,876,877,878],"A log of who has previously modified the infrastructure","The exact monthly bill for the new resource","An execution plan describing exactly what will be created, changed, or destroyed to match the new configuration","A list of security vulnerabilities in the code","Terraform's plan step compares the configuration file to the current state of the infrastructure and shows exactly what it will add, change, or destroy before anything actually happens. That preview is what lets a team catch an unintended change before it reaches real infrastructure, not after.",{"question":881,"type":499,"options":882,"correctAnswers":887,"explanation":888},"Which of the following are things a CI/CD pipeline stage can catch before a change reaches production? (Select all that apply.)",[883,884,885,886],"A syntax error that fails the build stage","A regression caught by the automated test stage","A configuration problem only visible once the change deploys to staging","A team's decision about which cloud region to launch in",[883,884,885],"Each pipeline stage exists to catch a different class of problem: the build stage catches code that will not even compile or package, the test stage catches regressions in behavior, and staging catches problems that only appear once the change runs in a production-like environment. Choosing a region is a design decision made before any of this, not something a pipeline stage detects.",{"question":890,"type":468,"options":891,"correctAnswer":895,"explanation":896},"Why is a Terraform configuration file described as declarative rather than imperative?",[892,893,894,895],"It lists step-by-step commands to run in order","It cannot be stored in version control","It only works with a single cloud provider","It describes the desired end state of the infrastructure, and the tool works out the steps needed to reach it","A declarative file says what the infrastructure should look like, one storage bucket with this name, for example, and leaves the how to the tool, which figures out the order of operations and the dependency graph. An imperative script would instead spell out each command to run, in order, to get there.",{"question":898,"type":468,"options":899,"correctAnswer":900,"explanation":903},"Infrastructure as code makes it easier to apply which practice consistently across every environment a team runs, a topic the next domain in this course covers in full?",[900,521,901,902],"Security controls such as identity and encryption settings","Writing a Dockerfile","Naming lesson slugs","Because infrastructure as code describes every environment in version-controlled files, the same security settings, identity policies, encryption, network rules, apply the same way everywhere instead of depending on someone remembering to click the same options by hand each time. The next domain covers exactly these controls in depth.",{"title":528,"description":529},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/03-devops-and-infrastructure-as-code","aAbphIY88s1lTvgS-_RltVaOn18fgQF0ZePwZRhHr1Y",{"locked":5,"reason":3,"meta":908,"item":917},{"title":909,"description":910,"isFree":461,"estimatedMinutes":345,"difficulty":10,"learningObjectives":911},"Serverless Computing","What 'serverless' actually means, how a function scales from zero to thousands of requests and back, the real cost math behind it, and where its limits sit.",[912,913,914,915,916],"Explain what serverless computing means and correct the misconception that no servers are involved","Describe the event-driven lifecycle of a serverless function, including cold starts and warm starts","Calculate whether a workload costs less as a serverless function or as an always-on server, using its request volume and duration","Identify the execution-time and state limits that rule serverless functions out for a given workload","Compare serverless functions against containers and virtual machines on the control-versus-convenience spectrum",{"id":918,"title":909,"body":919,"description":910,"difficulty":10,"estimatedMinutes":345,"extension":446,"infographics":1033,"isFree":461,"learningObjectives":1044,"meta":1045,"navigation":461,"path":1046,"quiz":1047,"seo":1102,"stem":1103,"__hash__":1104},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/01-serverless-computing.md",{"type":20,"value":920,"toc":1023},[921,925,928,932,935,939,942,946,950,953,957,960,963,966,970,973,975,1018,1020],[23,922,924],{"id":923},"the-spectrum-lesson-could-not-show-you-this-part","The spectrum lesson could not show you this part",[28,926,927],{},"The compute lesson placed serverless functions at the far right of the control-versus-convenience spectrum: the provider manages everything except your code, and a function starts in milliseconds. That diagram earns its place by showing where serverless sits relative to virtual machines and containers, but it cannot show what \"the provider manages everything\" actually means in practice, or where the edges of that convenience sit. Both matter once you are the one deciding whether a workload belongs on a serverless function at all.",[23,929,931],{"id":930},"no-servers-is-the-marketing-name-not-the-mechanism","No servers is the marketing name, not the mechanism",[28,933,934],{},"\"Serverless\" is the industry's name for the model, not a literal description. AWS runs your function inside an isolated micro virtual machine on its own fleet of physical servers, using a virtualization technology called Firecracker on its Nitro System; Azure and Google Cloud do the equivalent on their own hardware. What \"serverless\" removes is not the server, it is your job of choosing, sizing, patching, and scaling that server. Compare that to IaaS, where you pick the instance type yourself, or even PaaS, where you at least choose a runtime and a scaling policy. A serverless function hands you neither dial: you supply a function, attach a trigger, and the provider decides how many copies of it to run, where, and for how long each one lives.",[23,936,938],{"id":937},"the-event-driven-lifecycle-idle-invoke-execute-idle-again","The event-driven lifecycle: idle, invoke, execute, idle again",[28,940,941],{},"A serverless function does not sit running and waiting for work the way a virtual machine does. Picture a function that generates a thumbnail every time a customer uploads a photo to a storage bucket. Most of the day, zero copies of that function are running anywhere, and it costs nothing. The moment a photo lands in the bucket, the event triggers an invocation: the platform finds or creates an execution environment, runs your handler code against the event, and returns a result. Once the flow of uploads stops for a while, the platform reclaims that environment, and the function is back to zero.",[152,943],{"alt":944,"slug":945},"A timeline showing a serverless function's lifecycle from idle through a cold or warm start, execution, and back to idle, noting that billing follows only the execution segment.","serverless-computing-request-lifecycle",[23,947,949],{"id":948},"cold-starts-and-warm-starts","Cold starts and warm starts",[28,951,952],{},"That \"finds or creates\" distinction has a name. If an execution environment from a recent invocation is still around, the platform reuses it, a warm start, which runs your handler almost immediately. If not, after an idle period or a burst of new traffic, the platform first has to initialize a fresh environment, load your runtime, and import your dependencies before your handler runs at all, a cold start. That initialization work is not free in time or money: current AWS Lambda billing counts the initialization phase of a cold start as billed duration, the same as the handler itself. A function invoked constantly rarely pays the cold-start tax, since environments stay warm; a function invoked in occasional bursts pays it on the first request of every burst.",[23,954,956],{"id":955},"the-math-behind-pay-only-for-what-runs","The math behind \"pay only for what runs\"",[28,958,959],{},"AWS Lambda's on-demand pricing charges $0.20 per million requests plus $0.0000166667 per GB-second of execution time, with a free tier of 1 million requests and 400,000 GB-seconds every month, forever.",[28,961,962],{},"Take a function configured with 512 MB of memory (0.5 GB) that runs for 400 milliseconds (0.4 seconds), invoked 100,000 times a month, image thumbnailing for a small photo-sharing app, say. That workload uses 100,000 x 0.5 x 0.4 = 20,000 GB-seconds and 100,000 requests, both comfortably inside the free tier. The bill: $0.",[28,964,965],{},"Now scale the same function to 5 million invocations a month, a busier app, or the same app grown up. That is 5,000,000 x 0.5 x 0.4 = 1,000,000 GB-seconds, of which 600,000 are billable after the free tier, plus 4,000,000 billable requests. Duration costs about 600,000 x $0.0000166667, roughly $10.00, and requests add another 4 x $0.20 = $0.80, for a bill around $10.80 a month. Compare that to the t3.micro from the compute lesson, about $7.59 a month running around the clock whether it does any work or not. At low, spiky volume, serverless wins outright, it is free. At high, steady volume, an always-on instance can undercut it, and that is before asking whether one t3.micro could even keep up with 5 million requests without falling over.",[23,967,969],{"id":968},"where-a-serverless-function-stops-fitting","Where a serverless function stops fitting",[28,971,972],{},"Two boundaries matter as much as the cost math. First, execution time: AWS Lambda functions cap a single invocation at 15 minutes; a video-encoding job that runs for 2 hours simply does not fit inside a plain function, no matter how the pricing works out. Second, state: an execution environment can be reused between invocations, but nothing guarantees it, so a function cannot rely on data staying in memory or a connection staying open between one invocation and the next. A workload that needs a long-lived database connection pool, a multi-hour batch job, or guaranteed in-memory state belongs on a container or a virtual machine instead.",[23,974,373],{"id":372},[375,976,977,985],{},[378,978,979],{},[381,980,981,983],{},[384,982,386],{},[384,984,389],{},[391,986,987,995,1002,1010],{},[381,988,989,992],{},[396,990,991],{},"\"Runs only when triggered,\" \"event-driven,\" \"no servers to manage\"",[396,993,994],{},"Serverless function",[381,996,997,1000],{},[396,998,999],{},"\"Traffic is unpredictable,\" \"idle most of the day\"",[396,1001,994],{},[381,1003,1004,1007],{},[396,1005,1006],{},"\"Needs a persistent connection,\" \"runs continuously for hours\"",[396,1008,1009],{},"Container or virtual machine",[381,1011,1012,1015],{},[396,1013,1014],{},"\"High, steady volume around the clock\"",[396,1016,1017],{},"Container or virtual machine (cost crossover favors always-on)",[23,1019,429],{"id":428},[28,1021,1022],{},"Serverless does not remove servers, it removes your job of managing them, and it bills you only for the milliseconds your code actually runs. That trade pays off at low or spiky volume and can lose to an always-on instance at high, steady volume, which is exactly why \"serverless is always cheaper\" is a trap, not a rule. The next lesson leaves the question of who manages the server behind and asks a different one: how should the application itself be split into pieces, and how do those pieces run the same way everywhere. That is what containers and microservices answer.",{"title":44,"searchDepth":64,"depth":64,"links":1024},[1025,1026,1027,1028,1029,1030,1031,1032],{"id":923,"depth":58,"text":924},{"id":930,"depth":58,"text":931},{"id":937,"depth":58,"text":938},{"id":948,"depth":58,"text":949},{"id":955,"depth":58,"text":956},{"id":968,"depth":58,"text":969},{"id":372,"depth":58,"text":373},{"id":428,"depth":58,"text":429},[1034],{"slug":945,"concept":1035,"style":840,"aspectRatio":451,"labels":1036},"A left-to-right timeline showing a serverless function's lifecycle across 5 stages: Idle (zero instances running), Event arrives (a trigger invokes the function), a branch into Cold start versus Warm start that reconverges, Execution (the handler runs and returns a response), and Idle again once a timeout reclaims the environment. The cold start path shows an extra 'initialize environment' step drawn visibly longer than the warm start path. A footer strip carries the takeaway that billing follows only the execution segment of this timeline.",[1037,1038,1039,1040,1041,1042,1043],"Idle: zero instances running, zero cost.","Event arrives: a trigger invokes the function.","Cold start: a new environment initializes first. Slower.","Warm start: a cached environment is reused. Faster.","Execution: the handler runs and returns a response.","Idle again: after a timeout, the environment is reclaimed.","You pay only for the execution segment, never for idle time.",[912,913,914,915,916],{},"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/01-serverless-computing",{"passingScore":464,"questions":1048},[1049,1057,1065,1073,1077,1085,1094],{"question":1050,"type":468,"options":1051,"correctAnswer":1053,"explanation":1056},"A colleague says AWS Lambda is called \"serverless\" because Amazon's data centers do not use physical servers for it. What is wrong with this claim?",[1052,1053,1054,1055],"Nothing, Lambda functions genuinely run without any physical servers involved","Physical servers still run the function, but the provider manages provisioning, patching, and capacity so you never touch them","Lambda functions run entirely on the requesting device instead of in a data center","Serverless only applies to storage services, not compute","\"Serverless\" describes what disappears from your job, not what disappears from the data center. AWS still runs your function on real hardware, isolated in its own micro virtual machine, but you never choose, size, patch, or scale that machine yourself.",{"question":1058,"type":468,"options":1059,"correctAnswer":1062,"explanation":1064},"A team's serverless function handles 100,000 requests a month, each running for 400 ms at 512 MB of memory. Given AWS Lambda's free tier of 1 million requests and 400,000 GB-seconds a month, what does this workload cost?",[1060,1061,1062,1063],"About $10.80, since compute charges always exceed the free tier","About $0.20, just the request charge","$0, the workload falls entirely within the free tier","It cannot be calculated without knowing the AWS region","100,000 invocations at 0.5 GB for 0.4 seconds each use 20,000 GB-seconds, well under the 400,000 GB-second free tier, and 100,000 requests is well under the 1 million free requests. Both the compute and request charges land inside the free tier, so the bill is $0.",{"question":1066,"type":468,"options":1067,"correctAnswer":1068,"explanation":1072},"The same function type instead runs 5 million times a month at the same 400 ms / 512 MB profile. Which statement about the cost compared to a $7.59-a-month t3.micro instance is accurate?",[1068,1069,1070,1071],"The serverless bill, about $10.80, is now higher than the always-on VM, even though the VM might not even handle that volume alone","Serverless remains free no matter how much the volume grows","The VM would cost more than serverless no matter the traffic pattern","AWS caps Lambda's bill so it can never exceed VM pricing","At 5 million invocations, billable usage rises to 600,000 GB-seconds (about $10.00) plus 4 million billable requests (about $0.80), roughly $10.80 total, more than the always-on t3.micro's $7.59. High, steady volume is exactly where an always-on instance can undercut serverless pricing.",{"question":1074,"type":468,"options":1075,"correctAnswer":487,"explanation":1076},"A serverless function can run for as long as a workload needs, with no upper limit on a single invocation's duration.",[486,487],"AWS Lambda functions cap a single invocation at 15 minutes. A workload that genuinely needs hours of continuous processing, a video-encoding job, for example, does not fit inside a plain serverless function no matter how favorable the per-request math looks.",{"question":1078,"type":468,"options":1079,"correctAnswer":1083,"explanation":1084},"A serverless function that has not been invoked in over an hour receives a new request. What happens compared to a request that arrives seconds after the previous one?",[1080,1081,1082,1083],"The new request is rejected because the function scaled to zero","Nothing changes, every invocation behaves identically regardless of idle time","The new request reuses a cached warm execution environment, exactly like the recent request would","The new request triggers a cold start, since the platform must first initialize a fresh execution environment before running the handler, adding latency a warm request would not have","After an hour of no traffic, the platform has reclaimed any warm environments, so the next invocation pays the cost of initializing a new one first. A request seconds after another one almost always finds a warm environment still around and skips that initialization entirely.",{"question":1086,"type":499,"options":1087,"correctAnswers":1092,"explanation":1093},"Which of the following scenario descriptions point toward a serverless function rather than an always-on virtual machine? (Select all that apply.)",[1088,1089,1090,1091],"Code needs to run only when a file lands in a storage bucket, a few times a day","The application needs a persistent database connection held open for hours at a time","Traffic is unpredictable and spends most of the day at zero","The workload must run continuously at high, steady volume around the clock",[1088,1090],"Event-driven work and traffic that spends most of its time at zero are exactly what serverless functions are billed and built for: no cost while idle, automatic scaling when a burst arrives. A persistent connection held open for hours and steady round-the-clock volume both point toward a container or virtual machine instead.",{"question":1095,"type":468,"options":1096,"correctAnswer":1097,"explanation":1101},"This lesson placed serverless functions on the control-versus-convenience spectrum. What question does the next topic in this domain, containers and microservices, ask instead?",[1097,1098,1099,1100],"How should the application itself be split into pieces, and how do those pieces run consistently across environments","Who manages the underlying physical servers","How much a workload costs per month","Which programming language the team should use","Serverless functions answer who manages the server. Containers and microservices leave that question behind and ask how the application's own code should be organized and packaged so it runs the same way everywhere.",{"title":909,"description":910},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/01-serverless-computing","9_f-d1cgguk9P2Vb5FVYfvScvwpt34XfIoc6b6isRCc"]