[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"next-cloud-computing-fundamentals-cloud-services-and-architecture-core-cloud-services-cloud-networking-basics-en":4,"prev-cloud-computing-fundamentals-cloud-services-and-architecture-core-cloud-services-cloud-networking-basics-en":233,"lesson-cloud-computing-fundamentals-cloud-services-and-architecture-core-cloud-services-cloud-networking-basics-en":591},null,{"locked":5,"reason":3,"meta":6,"item":18},false,{"title":7,"description":8,"isFree":9,"estimatedMinutes":10,"difficulty":11,"learningObjectives":12},"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.",true,18,"intermediate",[13,14,15,16,17],"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":19,"title":7,"body":20,"description":8,"difficulty":11,"estimatedMinutes":10,"extension":153,"infographics":154,"isFree":9,"learningObjectives":167,"meta":168,"navigation":9,"path":169,"quiz":170,"seo":230,"stem":231,"__hash__":232},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/01-serverless-computing.md",{"type":21,"value":22,"toc":140},"minimark",[23,28,32,36,39,43,46,51,55,58,62,65,68,71,75,78,82,133,137],[24,25,27],"h2",{"id":26},"the-spectrum-lesson-could-not-show-you-this-part","The spectrum lesson could not show you this part",[29,30,31],"p",{},"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.",[24,33,35],{"id":34},"no-servers-is-the-marketing-name-not-the-mechanism","No servers is the marketing name, not the mechanism",[29,37,38],{},"\"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.",[24,40,42],{"id":41},"the-event-driven-lifecycle-idle-invoke-execute-idle-again","The event-driven lifecycle: idle, invoke, execute, idle again",[29,44,45],{},"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.",[47,48],"infographic",{"alt":49,"slug":50},"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",[24,52,54],{"id":53},"cold-starts-and-warm-starts","Cold starts and warm starts",[29,56,57],{},"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.",[24,59,61],{"id":60},"the-math-behind-pay-only-for-what-runs","The math behind \"pay only for what runs\"",[29,63,64],{},"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.",[29,66,67],{},"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.",[29,69,70],{},"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.",[24,72,74],{"id":73},"where-a-serverless-function-stops-fitting","Where a serverless function stops fitting",[29,76,77],{},"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.",[24,79,81],{"id":80},"exam-cues-spotting-the-fit-in-a-scenario","Exam cues: spotting the fit in a scenario",[83,84,85,98],"table",{},[86,87,88],"thead",{},[89,90,91,95],"tr",{},[92,93,94],"th",{},"The scenario says...",[92,96,97],{},"Points to",[99,100,101,110,117,125],"tbody",{},[89,102,103,107],{},[104,105,106],"td",{},"\"Runs only when triggered,\" \"event-driven,\" \"no servers to manage\"",[104,108,109],{},"Serverless function",[89,111,112,115],{},[104,113,114],{},"\"Traffic is unpredictable,\" \"idle most of the day\"",[104,116,109],{},[89,118,119,122],{},[104,120,121],{},"\"Needs a persistent connection,\" \"runs continuously for hours\"",[104,123,124],{},"Container or virtual machine",[89,126,127,130],{},[104,128,129],{},"\"High, steady volume around the clock\"",[104,131,132],{},"Container or virtual machine (cost crossover favors always-on)",[24,134,136],{"id":135},"where-this-leaves-you","Where this leaves you",[29,138,139],{},"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":141,"searchDepth":142,"depth":142,"links":143},"",3,[144,146,147,148,149,150,151,152],{"id":26,"depth":145,"text":27},2,{"id":34,"depth":145,"text":35},{"id":41,"depth":145,"text":42},{"id":53,"depth":145,"text":54},{"id":60,"depth":145,"text":61},{"id":73,"depth":145,"text":74},{"id":80,"depth":145,"text":81},{"id":135,"depth":145,"text":136},"md",[155],{"slug":50,"concept":156,"style":157,"aspectRatio":158,"labels":159},"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.","timeline","16:9",[160,161,162,163,164,165,166],"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.",[13,14,15,16,17],{},"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/01-serverless-computing",{"passingScore":171,"questions":172},70,[173,182,190,198,204,212,222],{"question":174,"type":175,"options":176,"correctAnswer":178,"explanation":181},"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?","single",[177,178,179,180],"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":183,"type":175,"options":184,"correctAnswer":187,"explanation":189},"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?",[185,186,187,188],"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":191,"type":175,"options":192,"correctAnswer":193,"explanation":197},"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?",[193,194,195,196],"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":199,"type":175,"options":200,"correctAnswer":202,"explanation":203},"A serverless function can run for as long as a workload needs, with no upper limit on a single invocation's duration.",[201,202],"True","False","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":205,"type":175,"options":206,"correctAnswer":210,"explanation":211},"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?",[207,208,209,210],"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":213,"type":214,"options":215,"correctAnswers":220,"explanation":221},"Which of the following scenario descriptions point toward a serverless function rather than an always-on virtual machine? (Select all that apply.)","multiple",[216,217,218,219],"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",[216,218],"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":223,"type":175,"options":224,"correctAnswer":225,"explanation":229},"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?",[225,226,227,228],"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":7,"description":8},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/01-serverless-computing","9_f-d1cgguk9P2Vb5FVYfvScvwpt34XfIoc6b6isRCc",{"locked":5,"reason":3,"meta":234,"item":243},{"title":235,"description":236,"isFree":5,"estimatedMinutes":10,"difficulty":237,"learningObjectives":238},"Databases in the Cloud","What a managed database service actually takes off your plate, how relational and NoSQL databases model data differently, and which one fits which part of a real application.","beginner",[239,240,241,242],"Explain what a managed database service takes over compared to running a database yourself","Distinguish relational databases from NoSQL databases by data model and query pattern","Choose a relational or NoSQL database for a given workload based on its access pattern","Identify the major managed relational and NoSQL products offered by AWS, Azure, and Google Cloud",{"id":244,"title":235,"body":245,"description":236,"difficulty":237,"estimatedMinutes":10,"extension":153,"infographics":522,"isFree":5,"learningObjectives":530,"meta":531,"navigation":9,"path":532,"quiz":533,"seo":588,"stem":589,"__hash__":590},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/04-databases-in-the-cloud.md",{"type":21,"value":246,"toc":512},[247,251,254,258,261,360,363,367,370,373,377,380,384,388,493,497,500,504,507,509],[24,248,250],{"id":249},"the-2-am-problem-a-managed-database-solves","The 2 a.m. problem a managed database solves",[29,252,253],{},"A database crashes at 2 a.m. Someone has to notice, diagnose whether it was a bad patch, a disk failure, or a runaway query, and bring it back without losing data. Running a database yourself, even on a cloud virtual machine, means that someone is you. A managed database service exists to make that someone the provider instead, for everything except the parts only you can answer, like which queries your application actually runs.",[24,255,257],{"id":256},"what-managed-actually-takes-over","What \"managed\" actually takes over",[29,259,260],{},"Amazon RDS is the model for a managed relational database, and its own documentation is specific about the split. Compare running a database on-premises, on a plain EC2 virtual machine, and on RDS:",[83,262,263,279],{},[86,264,265],{},[89,266,267,270,273,276],{},[92,268,269],{},"Task",[92,271,272],{},"On-premises",[92,274,275],{},"On EC2",[92,277,278],{},"On RDS",[99,280,281,293,305,316,327,338,349],{},[89,282,283,286,289,291],{},[104,284,285],{},"Application optimization",[104,287,288],{},"You",[104,290,288],{},[104,292,288],{},[89,294,295,298,300,302],{},[104,296,297],{},"Scaling",[104,299,288],{},[104,301,288],{},[104,303,304],{},"AWS",[89,306,307,310,312,314],{},[104,308,309],{},"High availability",[104,311,288],{},[104,313,288],{},[104,315,304],{},[89,317,318,321,323,325],{},[104,319,320],{},"Database backups",[104,322,288],{},[104,324,288],{},[104,326,304],{},[89,328,329,332,334,336],{},[104,330,331],{},"Database software patching",[104,333,288],{},[104,335,288],{},[104,337,304],{},[89,339,340,343,345,347],{},[104,341,342],{},"Operating system patching",[104,344,288],{},[104,346,288],{},[104,348,304],{},[89,350,351,354,356,358],{},[104,352,353],{},"Server maintenance",[104,355,288],{},[104,357,304],{},[104,359,304],{},[29,361,362],{},"Moving from on-premises to EC2 hands over the physical hardware. Moving from EC2 to RDS hands over almost everything about running the database engine itself, patching, backups, scaling, failure detection and recovery. What stays with you in every column is query tuning, because that depends entirely on your specific application, your specific queries, and your specific data, work no managed service can do on your behalf.",[24,364,366],{"id":365},"relational-databases-rows-that-relate-to-other-rows","Relational databases: rows that relate to other rows",[29,368,369],{},"Picture an online store's Orders table. Every row needs a customer_id that points to a real row in a separate Customers table, and a product_id that points to a real row in Inventory. That enforced relationship, an order that cannot exist without a matching customer and product, is the defining feature of a relational database: data organized into tables with rows and columns, queried with SQL, and connected across tables through keys. Amazon RDS supports 6 engines this way: MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, Oracle Database, and IBM Db2, all queryable with the same relational model even though the underlying engines differ.",[29,371,372],{},"That structure is exactly what an order needs. If a payment fails partway through checkout, the database must not leave an order pointing at a customer or inventory row that no longer makes sense, and relational databases are built to enforce that kind of consistency.",[24,374,376],{"id":375},"nosql-databases-fast-lookups-without-the-relationships","NoSQL databases: fast lookups without the relationships",[29,378,379],{},"Now picture a leaderboard for a game with 10 million concurrent players, or a shopping cart that gets read and rewritten on every click. Neither one needs to be joined against another table, and neither one benefits from the overhead of enforcing table relationships. NoSQL databases, modeled on Amazon DynamoDB, drop the table-and-join model in favor of items retrieved directly by a key, with a flexible structure that can differ from one item to the next. DynamoDB advertises single-digit millisecond performance whether an application serves tens of thousands or hundreds of millions of concurrent users, because the entire design trades away cross-item relationships for that kind of scale.",[24,381,383],{"id":382},"the-boundary-match-the-model-to-the-access-pattern","The boundary: match the model to the access pattern",[47,385],{"alt":386,"slug":387},"A comparison diagram contrasting relational database tables connected by join lines with independent NoSQL items of varying shape, each addressed by a partition key.","databases-relational-vs-nosql-shape",[83,389,390,403],{},[86,391,392],{},[89,393,394,397,400],{},[92,395,396],{},"Property",[92,398,399],{},"Relational",[92,401,402],{},"NoSQL",[99,404,405,416,427,438,449,460,471,482],{},[89,406,407,410,413],{},[104,408,409],{},"Data organized as",[104,411,412],{},"Tables with fixed rows and columns",[104,414,415],{},"Independent items, flexible shape",[89,417,418,421,424],{},[104,419,420],{},"Relationships across records",[104,422,423],{},"Enforced through keys and joins",[104,425,426],{},"Not built in, usually avoided by design",[89,428,429,432,435],{},[104,430,431],{},"Query language",[104,433,434],{},"SQL",[104,436,437],{},"Product-specific APIs, key-based lookups",[89,439,440,443,446],{},[104,441,442],{},"Scaling model",[104,444,445],{},"Primarily vertical, with read replicas for reads",[104,447,448],{},"Horizontal by design, built for massive concurrent access",[89,450,451,454,457],{},[104,452,453],{},"Strong fit for",[104,455,456],{},"Transactions that must stay consistent across related records",[104,458,459],{},"High-scale, simple-lookup workloads like sessions, carts, leaderboards",[89,461,462,465,468],{},[104,463,464],{},"AWS product",[104,466,467],{},"RDS",[104,469,470],{},"DynamoDB",[89,472,473,476,479],{},[104,474,475],{},"Azure product",[104,477,478],{},"Azure SQL Database",[104,480,481],{},"Azure Cosmos DB",[89,483,484,487,490],{},[104,485,486],{},"Google Cloud product",[104,488,489],{},"Cloud SQL",[104,491,492],{},"Firestore",[24,494,496],{"id":495},"worked-example-1-platform-2-databases","Worked example: 1 platform, 2 databases",[29,498,499],{},"The same e-commerce platform from the previous lesson needs both models at once, not a single choice between them. Orders, customers, and inventory go in a relational database, because an order that references a nonexistent customer or an inventory row is a bug, and the relational model is what prevents it. Shopping cart contents and session data go in a NoSQL database, because that data changes constantly, gets read on nearly every page load, and never needs to be joined against the Orders table to do its job. Running both side by side, rather than forcing every kind of data through one model, is normal architecture, not a compromise.",[24,501,503],{"id":502},"the-misconception-newer-does-not-mean-universally-better","The misconception: newer does not mean universally better",[29,505,506],{},"It is tempting to treat NoSQL as the modern upgrade and relational as the legacy option. That framing misses what each one actually gives up. NoSQL scales to enormous concurrent load precisely because it does not enforce relationships between items, the exact guarantee an order-and-inventory system depends on. A well-run application does not pick a side once, it puts each kind of data in the model built for its access pattern, which is why real systems commonly run relational and NoSQL databases side by side rather than choosing one for everything.",[24,508,136],{"id":135},[29,510,511],{},"A managed database service takes over patching, backups, and failure recovery so you can focus on the queries and the schema only you understand. Reach for a relational database when records must stay consistent with each other across tables, and reach for NoSQL when the workload is a high-volume, simple lookup that does not need those relationships. The next lesson covers how traffic actually reaches these databases and the compute in front of them: cloud networking.",{"title":141,"searchDepth":142,"depth":142,"links":513},[514,515,516,517,518,519,520,521],{"id":249,"depth":145,"text":250},{"id":256,"depth":145,"text":257},{"id":365,"depth":145,"text":366},{"id":375,"depth":145,"text":376},{"id":382,"depth":145,"text":383},{"id":495,"depth":145,"text":496},{"id":502,"depth":145,"text":503},{"id":135,"depth":145,"text":136},[523],{"slug":387,"concept":524,"style":525,"aspectRatio":158,"labels":526},"A 2-panel comparison. Left panel, Relational: 2 small grid tables, Orders and Customers, each with clearly ruled rows and columns, connected by a visible join line from an Orders row's customer_id column to a matching Customers row, showing structured cross-table relationships. Right panel, NoSQL: a set of independent item cards, each a self-contained document with its own set of fields (one card has 3 fields, another has 5, a third has a nested list), with no join lines between them, addressed instead by a highlighted partition key on each card. A footer strip states the one-line access-pattern takeaway for each.","comparison",[527,528,529],"Relational: fixed rows and columns, related across tables by keys.","NoSQL: independent items, each with its own shape, addressed by key.","Relational asks 'how do these tables relate.' NoSQL asks 'how do I look this up fast.'",[239,240,241,242],{},"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/04-databases-in-the-cloud",{"passingScore":171,"questions":534},[535,543,551,559,563,572,580],{"question":536,"type":175,"options":537,"correctAnswer":540,"explanation":542},"According to Amazon RDS's own management comparison, which of these tasks does RDS take over that running a database on a plain EC2 instance does not?",[538,539,540,541],"Query tuning for a specific application's SQL statements","Choosing the database schema","Database software patching, backups, and automatic failure detection and recovery","Writing the application code that connects to the database","RDS's own comparison shows patching, backups, and failure detection and recovery moving to AWS's side under RDS, while they stay with the customer on plain EC2. Query tuning stays the customer's job in both cases, since it depends entirely on the specific application and its queries, something no managed service can do for you.",{"question":544,"type":175,"options":545,"correctAnswer":548,"explanation":550},"An online store's Orders table stores a customer_id column that must always match a real row in the Customers table. This kind of structured, enforced relationship between tables is a defining feature of which data model?",[546,547,548,549],"NoSQL databases","Object storage","Relational databases","Block storage","Relational databases are built around exactly this: rows in tables, related to other tables through keys, queried with SQL. NoSQL databases are designed to avoid this kind of cross-table relationship in favor of independent, quickly retrievable items, which is precisely the difference that makes each one fit different workloads.",{"question":552,"type":175,"options":553,"correctAnswer":554,"explanation":558},"A gaming company needs to store leaderboard data for tens of millions of concurrent players, with single-digit millisecond reads at any scale, and does not need to join leaderboard entries against other tables. Which type of database fits this requirement best?",[554,555,556,557],"A NoSQL database like DynamoDB","A relational database like PostgreSQL","Neither, this data should not be stored in a database at all","A relational database, because leaderboards are inherently tabular","This is exactly the pattern NoSQL databases like DynamoDB are built for: massive concurrent scale, fast key-based lookups, and no need for cross-table joins. A relational database could technically store this data too, but scaling it to tens of millions of concurrent reads with single-digit millisecond latency is a far harder operational problem than DynamoDB is purpose-built to solve.",{"question":560,"type":175,"options":561,"correctAnswer":202,"explanation":562},"NoSQL databases are always faster than relational databases, which is why a well-run application should use NoSQL for every part of its data.",[201,202],"NoSQL scales more easily to very high, simple-lookup workloads, but it does that by giving up the enforced relationships and flexible ad hoc querying a relational database provides. An e-commerce order that must stay consistent with its linked customer and inventory rows is exactly the kind of data relational databases are built to protect, and NoSQL is not simply 'faster' for that job, it is a worse fit.",{"question":564,"type":214,"options":565,"correctAnswers":570,"explanation":571},"Which of the following are true about an Amazon RDS Multi-AZ deployment? (Select all that apply.)",[566,567,568,569],"AWS automatically provisions and maintains a standby DB instance in a different Availability Zone","It applies the same Availability Zone redundancy concept from earlier in this topic, specifically to a database","It guarantees the database will survive the loss of an entire AWS Region","It helps provide failover support if the primary DB instance's Availability Zone has a problem",[566,567,569],"Multi-AZ is the same AZ-level redundancy from the Regions and Availability Zones lesson, applied specifically to a database: a synchronous standby in a different AZ that AWS can fail over to. Like any multi-AZ setup, it protects against a single AZ's failure, not a failure of the entire Region, which would require a separate cross-Region strategy.",{"question":573,"type":175,"options":574,"correctAnswer":577,"explanation":579},"Which pairing correctly matches a managed database product to its data model?",[575,576,577,578],"Amazon RDS: NoSQL","Amazon DynamoDB: relational","Amazon DynamoDB: NoSQL","Amazon RDS: object storage","DynamoDB is AWS's managed NoSQL database, built around key-based access instead of tables and joins. Amazon RDS is the relational counterpart, running engines like MySQL, PostgreSQL, and SQL Server, not NoSQL and not a storage service at all.",{"question":581,"type":175,"options":582,"correctAnswer":585,"explanation":587},"An e-commerce platform needs to record orders that must always stay consistent with a specific customer and specific inventory rows, and separately needs to store session data that changes constantly and does not need to be joined against anything. What is the most defensible database strategy?",[583,584,585,586],"Use NoSQL for both, since it is newer technology","Use relational for both, since consistency always matters","Use a relational database for orders, where relationships must be enforced, and a NoSQL database for session data, where fast key-based access matters more than relationships","Store everything in object storage instead of a database","This is exactly the kind of decision covered in this lesson: match the data model to the access pattern, not to a single default choice. Orders need enforced relationships and consistency, the relational strength; session data needs fast, simple lookups at scale, the NoSQL strength. Real applications commonly run both side by side rather than forcing one model to do both jobs.",{"title":235,"description":236},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/04-databases-in-the-cloud","zYo6IvtYLYz1E_4TTIPM0I9KD-ku7mZYq1Ly8xKqTuE",{"locked":5,"reason":3,"meta":592,"item":600},{"title":593,"description":594,"isFree":5,"estimatedMinutes":10,"difficulty":11,"learningObjectives":595},"Cloud Networking Basics","How a virtual private cloud, subnets, security groups, network ACLs, and a load balancer work together to get a user's request safely from the internet to a private database, and nowhere it should not go.",[596,597,598,599],"Explain what a virtual private cloud is and why it exists","Distinguish public and private subnets and identify which resources belong in each","Compare security groups and network ACLs by scope, statefulness, and rule type","Describe how a load balancer distributes traffic across compute targets",{"id":601,"title":593,"body":602,"description":594,"difficulty":11,"estimatedMinutes":10,"extension":153,"infographics":736,"isFree":5,"learningObjectives":746,"meta":747,"navigation":9,"path":748,"quiz":749,"seo":804,"stem":805,"__hash__":806},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/05-cloud-networking-basics.md",{"type":21,"value":603,"toc":727},[604,608,611,615,618,622,625,628,632,635,638,641,701,704,708,711,715,719,722,724],[24,605,607],{"id":606},"getting-a-request-from-the-internet-to-a-private-database-safely","Getting a request from the internet to a private database, safely",[29,609,610],{},"2 lessons ago, an e-commerce database sat safely in a relational database, storing orders that had to stay consistent with real customers and real inventory. That database is useless if a shopper's browser cannot reach it, and dangerous if anyone on the internet can reach it directly. Cloud networking is the layer that resolves that tension: it gets a request from a user's browser to the right application server and the right database, while keeping the database itself unreachable from the outside world entirely. This lesson builds that path piece by piece.",[24,612,614],{"id":613},"the-vpc-your-own-private-network-virtualized","The VPC: your own private network, virtualized",[29,616,617],{},"A virtual private cloud (VPC) is a logically isolated virtual network dedicated to your account. You choose an IP address range for it, then add subnets, gateways, and security controls, the same building blocks you would configure in a physical data center network, except there is no cabling and no hardware to rack. Every resource you launch, a virtual machine, a database instance, lives inside a VPC, which is what makes the next piece, subnets, meaningful.",[24,619,621],{"id":620},"subnets-public-versus-private","Subnets: public versus private",[29,623,624],{},"A subnet is a range of IP addresses inside a VPC, and, on AWS, a subnet lives entirely within 1 Availability Zone, the same AZ concept from earlier in this topic, now applied to networking. What makes a subnet public or private is not its name but its route table: a public subnet has a route to an internet gateway, so its resources can be reached from, and can reach, the internet; a private subnet has no such route, so nothing outside the VPC can reach it directly.",[29,626,627],{},"This is exactly the shape of the RDS reference architecture: application servers sit in public subnets across 2 Availability Zones, reachable by users, and the database instances sit in private subnets in those same 2 AZs, reachable only by the application servers inside the VPC, never directly from the internet. A resource in a private subnet is not cut off entirely; it can still reach the internet outbound, to download a software update, for instance, through a separate NAT gateway, but nothing outside can initiate a connection in.",[24,629,631],{"id":630},"security-groups-and-network-acls-2-different-locks-on-2-different-doors","Security groups and network ACLs: 2 different locks on 2 different doors",[29,633,634],{},"Getting the placement right is only half the job. The other half is deciding exactly what traffic each piece is allowed to see, and AWS gives you 2 different tools for that, at 2 different scopes.",[29,636,637],{},"A security group is a virtual firewall attached to an individual instance, like a doorman standing at one specific door who remembers everyone he has let in: once he allows a request out, he automatically lets the matching response back in without checking his list again. That memory is what \"stateful\" means. A security group only supports allow rules, and it checks every rule before deciding, since there is nothing to deny, only permission to grant or withhold.",[29,639,640],{},"A network ACL works at the subnet level instead, more like a building's front desk that checks every single person crossing the threshold, in either direction, against a written list, with no memory of who it let through 5 minutes ago. That is \"stateless\": a network ACL supports both allow and deny rules, and it stops at the first rule that matches, checked in order, rather than reviewing every rule the way a security group does.",[83,642,643,655],{},[86,644,645],{},[89,646,647,649,652],{},[92,648,396],{},[92,650,651],{},"Security group",[92,653,654],{},"Network ACL",[99,656,657,668,679,690],{},[89,658,659,662,665],{},[104,660,661],{},"Applies to",[104,663,664],{},"An instance",[104,666,667],{},"An entire subnet",[89,669,670,673,676],{},[104,671,672],{},"Rule types",[104,674,675],{},"Allow only",[104,677,678],{},"Allow and deny",[89,680,681,684,687],{},[104,682,683],{},"Rule evaluation",[104,685,686],{},"Checks all rules before deciding",[104,688,689],{},"Stops at the first matching rule, in order",[89,691,692,695,698],{},[104,693,694],{},"Return traffic",[104,696,697],{},"Automatically allowed (stateful)",[104,699,700],{},"Must be explicitly allowed (stateless)",[29,702,703],{},"AWS's own guidance is to use security groups as your primary access control and add network ACLs as a secondary, coarser layer on top. The reason is straightforward: a network ACL guards the whole subnet, so it keeps working as a backstop even in the rare case an instance gets launched without the right security group attached. 2 layers that can fail in different ways protect you better than 1 layer that has to be perfect every time.",[24,705,707],{"id":706},"the-load-balancer-spreading-traffic-across-healthy-targets","The load balancer: spreading traffic across healthy targets",[29,709,710],{},"Recall the compute lesson's horizontal scaling: adding more instances of the same size instead of resizing one. Splitting the load across 4 identical app servers only works if something decides which of the 4 handles each incoming request, and that something is a load balancer. A load balancer sits in front of a group of targets, health-checks each one, and routes traffic only to the targets currently passing those checks, automatically routing around an instance that has stopped responding.",[24,712,714],{"id":713},"the-full-path-assembled","The full path, assembled",[47,716],{"alt":717,"slug":718},"A network diagram showing a user request entering a VPC through an internet gateway, reaching a load balancer and app server in a public subnet, and the app server reaching a database in a private subnet that has no direct route to the internet.","cloud-networking-request-path",[29,720,721],{},"Put every piece from this lesson together and the path a request actually takes looks like this: a user's request enters the VPC through an internet gateway, reaches a load balancer, which routes it to one of several healthy app servers sitting in a public subnet, protected by that instance's security group. The app server then reaches into a private subnet to read or write the database, a connection allowed only because both sides sit inside the same VPC, never because the database is reachable from the internet. A network ACL watches each subnet boundary the whole way through, as the coarse-grained backstop behind every security group.",[24,723,136],{"id":135},[29,725,726],{},"Networking is not a single setting, it is a stack of decisions: which subnet a resource lives in decides whether the internet can reach it at all, security groups decide exactly which traffic reaches a specific instance, network ACLs back that up at the subnet level, and a load balancer decides which of several healthy instances actually answers a given request. Every service this topic covered, compute, storage, databases, sits somewhere inside this network, and none of it is reachable, or protected, without it. The next topic in this domain, Modern Cloud Architectures, builds on every one of these building blocks to cover the patterns teams actually deploy today: serverless computing, containers and microservices, and infrastructure as code.",{"title":141,"searchDepth":142,"depth":142,"links":728},[729,730,731,732,733,734,735],{"id":606,"depth":145,"text":607},{"id":613,"depth":145,"text":614},{"id":620,"depth":145,"text":621},{"id":630,"depth":145,"text":631},{"id":706,"depth":145,"text":707},{"id":713,"depth":145,"text":714},{"id":135,"depth":145,"text":136},[737],{"slug":718,"concept":738,"style":739,"aspectRatio":158,"labels":740},"A network topology diagram of one VPC box spanning 2 Availability Zone columns. Each AZ column contains a public subnet band on top holding a load balancer icon and an app server icon, and a private subnet band below it holding a database icon. A numbered arrow path starts outside the VPC box at a user icon, enters through an internet gateway into the load balancer, branches to either app server, then continues down into the matching AZ's private-subnet database, with the second AZ's database connected by a thin replication line. A footer strip states the layered-defense takeaway.","diagram",[741,742,743,744,745],"1. User request enters through the internet gateway.","2. Load balancer routes to a healthy app server in a public subnet.","3. App server reads and writes the database in a private subnet.","4. The private subnet has no route to the internet. Only the app server can reach it.","Security groups guard each resource. Network ACLs guard each subnet.",[596,597,598,599],{},"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/05-cloud-networking-basics",{"passingScore":171,"questions":750},[751,759,767,776,780,788,796],{"question":752,"type":175,"options":753,"correctAnswer":755,"explanation":758},"What is a virtual private cloud (VPC), in the most basic terms?",[754,755,756,757],"A physical, dedicated data center reserved for one customer","A logically isolated virtual network within the cloud, where you choose the IP address range and add subnets, gateways, and security controls","A synonym for an Availability Zone","A managed database service","A VPC is a private, virtualized network dedicated to your account, logically isolated from other customers' networks, where you control the IP address range, subnets, and gateways much like you would in a traditional data center network, except nothing physical to rack or wire.",{"question":760,"type":175,"options":761,"correctAnswer":763,"explanation":766},"In the RDS reference architecture this lesson describes, application servers sit in public subnets and database instances sit in private subnets. Why are the database instances placed in a private subnet specifically?",[762,763,764,765],"Private subnets are cheaper to operate than public subnets","Private subnets have no route that lets internet traffic reach them directly, so the database cannot be reached from outside the VPC even if someone tries","Databases physically cannot run in a public subnet","It is only a naming convention with no functional effect","A private subnet lacks a route to an internet gateway, so nothing outside the VPC can initiate a connection to resources inside it, which is exactly the protection a database needs. The application servers still reach the database because they are inside the same VPC; only inbound traffic from the public internet is blocked.",{"question":768,"type":214,"options":769,"correctAnswers":774,"explanation":775},"Which of the following statements correctly describe the difference between security groups and network ACLs? (Select all that apply.)",[770,771,772,773],"A security group operates at the instance level, while a network ACL operates at the subnet level","A security group only supports allow rules, while a network ACL supports both allow and deny rules","A security group is stateless and a network ACL is stateful","A network ACL evaluates its rules in order until it finds a match, while a security group evaluates all its rules before deciding",[770,771,773],"Security groups attach to instances and only allow traffic, evaluating every rule before deciding, while network ACLs attach to a subnet, support both allow and deny rules, and stop at the first matching rule in order. The statefulness is reversed from the distractor: security groups are stateful, automatically allowing return traffic, while network ACLs are stateless and require explicit rules in both directions.",{"question":777,"type":175,"options":778,"correctAnswer":201,"explanation":779},"A security group is stateful, which means that if it allows an outbound request from an instance, the response to that request is automatically allowed back in, without needing a matching inbound rule.",[201,202],"This is the defining behavior of a stateful firewall: the security group tracks the connection, so response traffic to an already-allowed request is let back in automatically. A network ACL does not do this, it is stateless, so a subnet using a network ACL must explicitly allow both the outbound request and the inbound response.",{"question":781,"type":175,"options":782,"correctAnswer":784,"explanation":787},"AWS's own guidance recommends using security groups as the primary access control and adding network ACLs on top as a secondary layer. Why bother with a second layer if security groups already control access?",[783,784,785,786],"Network ACLs are required by law in every AWS Region","Network ACLs apply to an entire subnet, so they provide a backstop even if an instance is ever launched without the correct security group attached","Security groups do not actually work, so a second layer is mandatory","There is no real benefit, the guidance is only a formality","Because a network ACL guards the whole subnet rather than a single instance, it keeps working as a coarse-grained guard rail even in the case a security group is misconfigured or missing on a specific instance. That is defense-in-depth: 2 layers that fail differently, so a mistake in one does not automatically expose the resource.",{"question":789,"type":175,"options":790,"correctAnswer":794,"explanation":795},"After a team applies horizontal scaling and now runs 4 identical app server instances instead of 1, what component is responsible for spreading incoming user traffic across all 4 healthy instances?",[791,792,793,794],"A network ACL","A security group","The database","A load balancer","A load balancer distributes incoming traffic across multiple targets and routes only to the ones that pass its health checks, which is exactly what 4 identical app servers behind it need. Security groups and network ACLs control which traffic is allowed to reach a resource; neither one decides how to split traffic across several healthy instances.",{"question":797,"type":175,"options":798,"correctAnswer":800,"explanation":803},"Which pairing correctly matches a virtual networking concept to its equivalent product name?",[799,800,801,802],"Google Cloud's VPC equivalent: Azure Virtual Network","AWS's VPC equivalent: Azure Virtual Network","Azure's virtual network product: Google Cloud VPC","AWS's VPC equivalent: Google Cloud Compute Engine","Azure's virtual networking product is called Virtual Network (VNet), and it plays the same role as an AWS VPC: an isolated, customer-controlled network you subdivide into subnets. Google Cloud uses the term VPC directly, and Compute Engine is a compute product, unrelated to networking.",{"title":593,"description":594},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/05-cloud-networking-basics","0SX2qccPGNhQBbG5JDix81hbDCTg9cH8MYkBC0YuQOI"]