[{"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-core-cloud-services-databases-in-the-cloud-en":4,"prev-cloud-computing-fundamentals-cloud-services-and-architecture-core-cloud-services-databases-in-the-cloud-en":387,"next-cloud-computing-fundamentals-cloud-services-and-architecture-core-cloud-services-databases-in-the-cloud-en":653},null,{"locked":5,"reason":3,"meta":6,"item":16},false,{"title":7,"description":8,"isFree":5,"estimatedMinutes":9,"difficulty":10,"learningObjectives":11},"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.",18,"beginner",[12,13,14,15],"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":17,"title":7,"body":18,"description":8,"difficulty":10,"estimatedMinutes":9,"extension":310,"infographics":311,"isFree":5,"learningObjectives":320,"meta":321,"navigation":322,"path":323,"quiz":324,"seo":384,"stem":385,"__hash__":386},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/04-databases-in-the-cloud.md",{"type":19,"value":20,"toc":297},"minimark",[21,26,30,34,37,142,145,149,152,155,159,162,166,171,276,280,283,287,290,294],[22,23,25],"h2",{"id":24},"the-2-am-problem-a-managed-database-solves","The 2 a.m. problem a managed database solves",[27,28,29],"p",{},"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.",[22,31,33],{"id":32},"what-managed-actually-takes-over","What \"managed\" actually takes over",[27,35,36],{},"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:",[38,39,40,59],"table",{},[41,42,43],"thead",{},[44,45,46,50,53,56],"tr",{},[47,48,49],"th",{},"Task",[47,51,52],{},"On-premises",[47,54,55],{},"On EC2",[47,57,58],{},"On RDS",[60,61,62,75,87,98,109,120,131],"tbody",{},[44,63,64,68,71,73],{},[65,66,67],"td",{},"Application optimization",[65,69,70],{},"You",[65,72,70],{},[65,74,70],{},[44,76,77,80,82,84],{},[65,78,79],{},"Scaling",[65,81,70],{},[65,83,70],{},[65,85,86],{},"AWS",[44,88,89,92,94,96],{},[65,90,91],{},"High availability",[65,93,70],{},[65,95,70],{},[65,97,86],{},[44,99,100,103,105,107],{},[65,101,102],{},"Database backups",[65,104,70],{},[65,106,70],{},[65,108,86],{},[44,110,111,114,116,118],{},[65,112,113],{},"Database software patching",[65,115,70],{},[65,117,70],{},[65,119,86],{},[44,121,122,125,127,129],{},[65,123,124],{},"Operating system patching",[65,126,70],{},[65,128,70],{},[65,130,86],{},[44,132,133,136,138,140],{},[65,134,135],{},"Server maintenance",[65,137,70],{},[65,139,86],{},[65,141,86],{},[27,143,144],{},"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.",[22,146,148],{"id":147},"relational-databases-rows-that-relate-to-other-rows","Relational databases: rows that relate to other rows",[27,150,151],{},"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.",[27,153,154],{},"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.",[22,156,158],{"id":157},"nosql-databases-fast-lookups-without-the-relationships","NoSQL databases: fast lookups without the relationships",[27,160,161],{},"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.",[22,163,165],{"id":164},"the-boundary-match-the-model-to-the-access-pattern","The boundary: match the model to the access pattern",[167,168],"infographic",{"alt":169,"slug":170},"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",[38,172,173,186],{},[41,174,175],{},[44,176,177,180,183],{},[47,178,179],{},"Property",[47,181,182],{},"Relational",[47,184,185],{},"NoSQL",[60,187,188,199,210,221,232,243,254,265],{},[44,189,190,193,196],{},[65,191,192],{},"Data organized as",[65,194,195],{},"Tables with fixed rows and columns",[65,197,198],{},"Independent items, flexible shape",[44,200,201,204,207],{},[65,202,203],{},"Relationships across records",[65,205,206],{},"Enforced through keys and joins",[65,208,209],{},"Not built in, usually avoided by design",[44,211,212,215,218],{},[65,213,214],{},"Query language",[65,216,217],{},"SQL",[65,219,220],{},"Product-specific APIs, key-based lookups",[44,222,223,226,229],{},[65,224,225],{},"Scaling model",[65,227,228],{},"Primarily vertical, with read replicas for reads",[65,230,231],{},"Horizontal by design, built for massive concurrent access",[44,233,234,237,240],{},[65,235,236],{},"Strong fit for",[65,238,239],{},"Transactions that must stay consistent across related records",[65,241,242],{},"High-scale, simple-lookup workloads like sessions, carts, leaderboards",[44,244,245,248,251],{},[65,246,247],{},"AWS product",[65,249,250],{},"RDS",[65,252,253],{},"DynamoDB",[44,255,256,259,262],{},[65,257,258],{},"Azure product",[65,260,261],{},"Azure SQL Database",[65,263,264],{},"Azure Cosmos DB",[44,266,267,270,273],{},[65,268,269],{},"Google Cloud product",[65,271,272],{},"Cloud SQL",[65,274,275],{},"Firestore",[22,277,279],{"id":278},"worked-example-1-platform-2-databases","Worked example: 1 platform, 2 databases",[27,281,282],{},"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.",[22,284,286],{"id":285},"the-misconception-newer-does-not-mean-universally-better","The misconception: newer does not mean universally better",[27,288,289],{},"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.",[22,291,293],{"id":292},"where-this-leaves-you","Where this leaves you",[27,295,296],{},"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":298,"searchDepth":299,"depth":299,"links":300},"",3,[301,303,304,305,306,307,308,309],{"id":24,"depth":302,"text":25},2,{"id":32,"depth":302,"text":33},{"id":147,"depth":302,"text":148},{"id":157,"depth":302,"text":158},{"id":164,"depth":302,"text":165},{"id":278,"depth":302,"text":279},{"id":285,"depth":302,"text":286},{"id":292,"depth":302,"text":293},"md",[312],{"slug":170,"concept":313,"style":314,"aspectRatio":315,"labels":316},"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","16:9",[317,318,319],"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.'",[12,13,14,15],{},true,"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/04-databases-in-the-cloud",{"passingScore":325,"questions":326},70,[327,336,344,352,358,368,376],{"question":328,"type":329,"options":330,"correctAnswer":333,"explanation":335},"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?","single",[331,332,333,334],"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":337,"type":329,"options":338,"correctAnswer":341,"explanation":343},"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?",[339,340,341,342],"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":345,"type":329,"options":346,"correctAnswer":347,"explanation":351},"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?",[347,348,349,350],"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":353,"type":329,"options":354,"correctAnswer":356,"explanation":357},"NoSQL databases are always faster than relational databases, which is why a well-run application should use NoSQL for every part of its data.",[355,356],"True","False","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":359,"type":360,"options":361,"correctAnswers":366,"explanation":367},"Which of the following are true about an Amazon RDS Multi-AZ deployment? (Select all that apply.)","multiple",[362,363,364,365],"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",[362,363,365],"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":369,"type":329,"options":370,"correctAnswer":373,"explanation":375},"Which pairing correctly matches a managed database product to its data model?",[371,372,373,374],"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":377,"type":329,"options":378,"correctAnswer":381,"explanation":383},"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?",[379,380,381,382],"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":7,"description":8},"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":388,"item":397},{"title":389,"description":390,"isFree":5,"estimatedMinutes":391,"difficulty":10,"learningObjectives":392},"Storage Services","Object, block, and file storage: how each one organizes data differently, which workloads each one actually fits, and the exam-favorite mistake of treating them as interchangeable.",17,[393,394,395,396],"Distinguish object, block, and file storage by how each one organizes and grants access to data","Match a storage type to a workload based on its access pattern","Explain why durability and availability are 2 separate guarantees, not one","Identify the object, block, and file storage products offered by AWS, Azure, and Google Cloud",{"id":398,"title":389,"body":399,"description":390,"difficulty":10,"estimatedMinutes":391,"extension":310,"infographics":588,"isFree":5,"learningObjectives":597,"meta":598,"navigation":322,"path":599,"quiz":600,"seo":650,"stem":651,"__hash__":652},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/03-storage-services.md",{"type":19,"value":400,"toc":578},[401,405,408,412,415,418,422,425,428,432,435,439,552,556,560,563,566,570,573,575],[22,402,404],{"id":403},"the-same-word-3-very-different-jobs","The same word, 3 very different jobs",[27,406,407],{},"\"Storage\" sounds like one thing until you actually need it. A photo-sharing app storing 50 million user photos, a database writing thousands of small updates a second, and 5 web servers that all need to read the same shared configuration folder are 3 completely different problems, and no single storage design solves all 3 well. Cloud providers ship 3 distinct storage types for exactly this reason: object, block, and file. Telling them apart by what they are built to do, not just by their names, is the actual skill this lesson teaches.",[22,409,411],{"id":410},"object-storage-buckets-full-of-tagged-files","Object storage: buckets full of tagged files",[27,413,414],{},"Start with the photo-sharing app. Every image is uploaded once, read many times, and never edited in place, you replace a photo, you do not modify 4KB of it. Amazon S3, the model for object storage, organizes data around exactly that pattern: a bucket is a container, and each file inside it is an object, addressed by a unique key rather than a folder path. There is no real folder hierarchy underneath, just a flat namespace where the key \"photos/vacation/beach.jpg\" looks like a path but is really just a string.",[27,416,417],{},"Object storage trades away in-place editing for massive scale, low cost, and strong durability, S3 is designed for 99.999999999% (11 nines) durability, achieved by storing data redundantly across multiple Availability Zones. That combination is why object storage is the default choice for data lakes, backups, static website assets, and media files: workloads defined by write-once, read-often access, not by constant small edits.",[22,419,421],{"id":420},"block-storage-numbered-chunks-for-one-machine","Block storage: numbered chunks for one machine",[27,423,424],{},"Now consider a relational database writing and rewriting rows constantly. That workload needs low latency and the ability to change small pieces of data in place, exactly what object storage does not offer. Block storage, modeled on Amazon EBS, divides a volume into fixed-size chunks, addressed by number, and attaches that volume to a single instance, the same way a hard drive attaches to one computer. The operating system running on that instance can format the volume, mount it, and treat it like local disk, because functionally, that is what it is.",[27,426,427],{},"Block storage is zonal: an EBS volume lives in 1 specific Availability Zone and can only attach to instances in that same AZ, which is exactly why a database sitting on a single EBS volume still needs its own replication or backup strategy to survive an AZ failure. In exchange for that constraint, block storage delivers the low-latency, high-IOPS performance a running database, or a virtual machine's own boot disk, actually needs.",[22,429,431],{"id":430},"file-storage-one-folder-tree-many-machines-at-once","File storage: one folder tree, many machines at once",[27,433,434],{},"The third scenario, 5 web servers sharing the same configuration directory, needs something neither of the other 2 provides directly: simultaneous access from multiple machines to the same hierarchical folder structure. File storage, modeled on Amazon EFS, solves this using a network file system protocol (NFS), so every server mounts the same file system and sees the same folders and files, with changes from one visible to the others immediately. Unlike a single-attach EBS volume, a file system like EFS scales automatically as data is added and can be mounted by many EC2 instances, containers, and even on-premises servers at once.",[22,436,438],{"id":437},"the-boundary-side-by-side","The boundary, side by side",[38,440,441,456],{},[41,442,443],{},[44,444,445,447,450,453],{},[47,446,179],{},[47,448,449],{},"Object",[47,451,452],{},"Block",[47,454,455],{},"File",[60,457,458,471,485,499,513,526,539],{},[44,459,460,462,465,468],{},[65,461,192],{},[65,463,464],{},"Flat namespace of key-addressed objects",[65,466,467],{},"Fixed-size numbered blocks",[65,469,470],{},"Hierarchical folders and files",[44,472,473,476,479,482],{},[65,474,475],{},"Attaches to",[65,477,478],{},"Accessed over the network by any authorized client",[65,480,481],{},"One instance at a time (typically)",[65,483,484],{},"Many instances at once",[44,486,487,490,493,496],{},[65,488,489],{},"Best access pattern",[65,491,492],{},"Write once, read often, no in-place edits",[65,494,495],{},"Frequent small reads and writes, low latency",[65,497,498],{},"Shared reads and writes across machines",[44,500,501,504,507,510],{},[65,502,503],{},"Typical use case",[65,505,506],{},"Backups, media, data lakes, static assets",[65,508,509],{},"Databases, boot volumes, transactional workloads",[65,511,512],{},"Shared content, home directories, config shared across a fleet",[44,514,515,517,520,523],{},[65,516,247],{},[65,518,519],{},"S3",[65,521,522],{},"EBS",[65,524,525],{},"EFS",[44,527,528,530,533,536],{},[65,529,258],{},[65,531,532],{},"Blob Storage",[65,534,535],{},"Managed Disks",[65,537,538],{},"Azure Files",[44,540,541,543,546,549],{},[65,542,269],{},[65,544,545],{},"Cloud Storage",[65,547,548],{},"Persistent Disk",[65,550,551],{},"Filestore",[167,553],{"alt":554,"slug":555},"Three side-by-side diagrams showing the actual shape of object, block, and file storage: a flat bucket of tagged objects, a volume sliced into numbered blocks attached to one server, and a shared folder tree mounted by multiple servers at once.","storage-services-shapes",[22,557,559],{"id":558},"worked-example-1-e-commerce-site-3-storage-decisions","Worked example: 1 e-commerce site, 3 storage decisions",[27,561,562],{},"An e-commerce platform needs to store 3 different kinds of data, and the right answer is different every time. Product photos, millions of them, uploaded once and served to shoppers constantly: object storage, because nothing about a product photo needs in-place editing, and the volume favors object storage's scale and cost. The transactional database tracking orders and inventory: block storage, because every checkout writes and rewrites rows and needs the low latency only a directly attached volume delivers. A shared directory of session cache files that 6 identical web servers behind a load balancer all need to read and write together: file storage, because it is the only one of the 3 built for simultaneous multi-instance access to the same folder tree.",[27,564,565],{},"Swap any 2 of those choices and the system either breaks outright, a database will not run acceptably on object storage, or works but wastes money and performance on a mismatch it did not need to make.",[22,567,569],{"id":568},"the-misconception-cheaper-does-not-mean-interchangeable","The misconception: cheaper does not mean interchangeable",[27,571,572],{},"It is tempting to look at object storage's low per-gigabyte price and assume it is simply the \"budget option\" you can swap in anywhere. It is not. Object storage is cheap precisely because it gives up the in-place, low-latency random access a running database or a boot volume depends on. Moving a database's data files onto object storage does not save money on a working system, it produces a system that does not work, because the storage type and the access pattern have to match. Price is a consequence of the tradeoff, not a substitute for understanding it.",[22,574,293],{"id":292},[27,576,577],{},"3 questions sort almost any storage decision: does the data get edited in place or just written once and read, does it need to be shared by multiple machines at once, and does it need to boot or run an operating system directly. Object storage answers \"written once, read often, no sharing requirement.\" Block storage answers \"attached to one machine, edited constantly, needs speed.\" File storage answers \"shared folder, multiple machines.\" The next lesson moves from raw storage to the layer most applications actually talk to directly: databases.",{"title":298,"searchDepth":299,"depth":299,"links":579},[580,581,582,583,584,585,586,587],{"id":403,"depth":302,"text":404},{"id":410,"depth":302,"text":411},{"id":420,"depth":302,"text":421},{"id":430,"depth":302,"text":431},{"id":437,"depth":302,"text":438},{"id":558,"depth":302,"text":559},{"id":568,"depth":302,"text":569},{"id":292,"depth":302,"text":293},[589],{"slug":555,"concept":590,"style":591,"aspectRatio":315,"labels":592},"A 3-panel comparison diagram, one panel per storage type, each showing the actual shape its data takes rather than a text description. Panel 1, Object: a flat, borderless bucket icon filled with irregularly shaped blobs, each blob tagged with a short key string, no folders. Panel 2, Block: a single rectangular volume sliced into a neat grid of equal-sized numbered blocks stacked like a ledger, attached by a line to one server icon. Panel 3, File: a rooted tree of nested folder icons branching into files, with 3 small server icons all touching the same tree to show shared access. A footer strip states the one-line access-pattern takeaway for each.","diagram",[593,594,595,596],"Object: a flat bucket of tagged, unstructured blobs. No folders.","Block: fixed-size chunks addressed by number, attached to one server.","File: a shared folder tree that multiple servers can read and write at once.","Pick by access pattern, not by which one sounds simplest.",[393,394,395,396],{},"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/03-storage-services",{"passingScore":325,"questions":601},[602,608,612,617,626,634,642],{"question":603,"type":329,"options":604,"correctAnswer":340,"explanation":607},"A photo-sharing app needs to store tens of millions of user-uploaded images, each one written once and read many times afterward, with no need to edit the file in place. Which storage type fits best?",[605,342,340,606],"File storage","None of these, images require a database","Object storage is built for exactly this pattern: huge volumes of unstructured files stored in a flat namespace, written once, read often, and never edited in place. Block storage is built for low-latency, in-place random writes, and file storage's advantage is simultaneous shared access, neither of which this workload needs.",{"question":609,"type":329,"options":610,"correctAnswer":355,"explanation":611},"Amazon EBS volumes are zonal resources, meaning a volume can only attach to instances within the same Availability Zone where it was created.",[355,356],"An EBS volume lives in one specific Availability Zone and can only attach to EC2 instances in that same AZ. This is exactly why a database on EBS still needs its own replication or backup strategy across AZs. Object storage like S3, by contrast, is accessed as a Regional service, not tied to a single AZ.",{"question":613,"type":329,"options":614,"correctAnswer":605,"explanation":616},"5 web servers need to read and write the same shared directory of uploaded configuration files at the same time. Which storage type is purpose-built for this?",[340,605,342,615],"Any of the 3 works equally well","File storage, using a protocol like NFS, is designed for exactly this case: multiple servers mounting and using the same hierarchical folder structure at once. Block storage attaches to a single instance at a time in most configurations, and object storage has no concept of a mountable shared folder tree the way file storage does.",{"question":618,"type":360,"options":619,"correctAnswers":624,"explanation":625},"Which of the following statements correctly distinguish block storage from object storage? (Select all that apply.)",[620,621,622,623],"Block storage divides data into fixed-size chunks, while object storage stores whole files as unstructured objects","Object storage is generally better suited to low-latency, high-IOPS database workloads than block storage","Block storage typically attaches to a single instance, while object storage is accessed over the network by any authorized client","Object storage uses a flat namespace, while file and block systems are typically organized hierarchically or by fixed address",[620,622,623],"Block storage's fixed-size chunks and direct instance attachment give it the low latency that transactional databases need, which makes it the better fit for that workload, not object storage. Object storage trades that low-latency, in-place editing capability for massive scale and a flat, key-based namespace instead of folders or fixed block addresses.",{"question":627,"type":329,"options":628,"correctAnswer":630,"explanation":633},"Amazon S3 advertises 99.999999999% (11 nines) durability. What does 'durability' actually promise, as distinct from 'availability'?",[629,630,631,632],"That the service will never be slow to respond","That stored data will not be lost or corrupted over time, independent of whether the service is reachable at any given moment","That the storage service will always be reachable and responsive","That data will always be encrypted in transit","Durability is about data surviving intact over time, achieved by redundantly storing copies across multiple Availability Zones. Availability is a separate promise, about whether the service can be reached and responds successfully right now. A service can be briefly unavailable during a network issue without losing a single byte of durably stored data.",{"question":635,"type":329,"options":636,"correctAnswer":639,"explanation":641},"A team decides to save money by moving their relational database's data files from a block storage volume onto object storage, since object storage is cheaper per gigabyte. What is the most likely result?",[637,638,639,640],"The database runs exactly the same, just cheaper","The database performs better, since object storage scales further","The database will not work as expected, because object storage does not support the low-latency, in-place random reads and writes a running database engine needs","Nothing changes, because all storage types are interchangeable under the hood","A running database constantly reads and overwrites small pieces of its data files, the exact access pattern block storage is built for and object storage is not. Object storage's price advantage exists precisely because it gives up that in-place, low-latency access, so it is cheaper for the workloads it fits and unusable for the ones it does not.",{"question":643,"type":329,"options":644,"correctAnswer":646,"explanation":649},"Which pairing correctly matches an AWS storage product to its category?",[645,646,647,648],"Amazon EFS: block storage","Amazon S3: object storage","Amazon EBS: object storage","Amazon S3: file storage","Amazon S3 is AWS's object storage service, built around buckets and objects in a flat namespace. Amazon EBS is block storage, and Amazon EFS is file storage, the reverse of the other 2 pairings offered as distractors.",{"title":389,"description":390},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/03-storage-services","Ck8geL1GVUilT-0CUhAy6rB3r3hg_LBd2TLvnC4dOlg",{"locked":5,"reason":3,"meta":654,"item":663},{"title":655,"description":656,"isFree":5,"estimatedMinutes":9,"difficulty":657,"learningObjectives":658},"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.","intermediate",[659,660,661,662],"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":664,"title":655,"body":665,"description":656,"difficulty":657,"estimatedMinutes":9,"extension":310,"infographics":799,"isFree":5,"learningObjectives":808,"meta":809,"navigation":322,"path":810,"quiz":811,"seo":866,"stem":867,"__hash__":868},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/05-cloud-networking-basics.md",{"type":19,"value":666,"toc":790},[667,671,674,678,681,685,688,691,695,698,701,704,764,767,771,774,778,782,785,787],[22,668,670],{"id":669},"getting-a-request-from-the-internet-to-a-private-database-safely","Getting a request from the internet to a private database, safely",[27,672,673],{},"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.",[22,675,677],{"id":676},"the-vpc-your-own-private-network-virtualized","The VPC: your own private network, virtualized",[27,679,680],{},"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.",[22,682,684],{"id":683},"subnets-public-versus-private","Subnets: public versus private",[27,686,687],{},"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.",[27,689,690],{},"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.",[22,692,694],{"id":693},"security-groups-and-network-acls-2-different-locks-on-2-different-doors","Security groups and network ACLs: 2 different locks on 2 different doors",[27,696,697],{},"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.",[27,699,700],{},"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.",[27,702,703],{},"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.",[38,705,706,718],{},[41,707,708],{},[44,709,710,712,715],{},[47,711,179],{},[47,713,714],{},"Security group",[47,716,717],{},"Network ACL",[60,719,720,731,742,753],{},[44,721,722,725,728],{},[65,723,724],{},"Applies to",[65,726,727],{},"An instance",[65,729,730],{},"An entire subnet",[44,732,733,736,739],{},[65,734,735],{},"Rule types",[65,737,738],{},"Allow only",[65,740,741],{},"Allow and deny",[44,743,744,747,750],{},[65,745,746],{},"Rule evaluation",[65,748,749],{},"Checks all rules before deciding",[65,751,752],{},"Stops at the first matching rule, in order",[44,754,755,758,761],{},[65,756,757],{},"Return traffic",[65,759,760],{},"Automatically allowed (stateful)",[65,762,763],{},"Must be explicitly allowed (stateless)",[27,765,766],{},"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.",[22,768,770],{"id":769},"the-load-balancer-spreading-traffic-across-healthy-targets","The load balancer: spreading traffic across healthy targets",[27,772,773],{},"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.",[22,775,777],{"id":776},"the-full-path-assembled","The full path, assembled",[167,779],{"alt":780,"slug":781},"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",[27,783,784],{},"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.",[22,786,293],{"id":292},[27,788,789],{},"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":298,"searchDepth":299,"depth":299,"links":791},[792,793,794,795,796,797,798],{"id":669,"depth":302,"text":670},{"id":676,"depth":302,"text":677},{"id":683,"depth":302,"text":684},{"id":693,"depth":302,"text":694},{"id":769,"depth":302,"text":770},{"id":776,"depth":302,"text":777},{"id":292,"depth":302,"text":293},[800],{"slug":781,"concept":801,"style":591,"aspectRatio":315,"labels":802},"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.",[803,804,805,806,807],"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.",[659,660,661,662],{},"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/05-cloud-networking-basics",{"passingScore":325,"questions":812},[813,821,829,838,842,850,858],{"question":814,"type":329,"options":815,"correctAnswer":817,"explanation":820},"What is a virtual private cloud (VPC), in the most basic terms?",[816,817,818,819],"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":822,"type":329,"options":823,"correctAnswer":825,"explanation":828},"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?",[824,825,826,827],"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":830,"type":360,"options":831,"correctAnswers":836,"explanation":837},"Which of the following statements correctly describe the difference between security groups and network ACLs? (Select all that apply.)",[832,833,834,835],"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",[832,833,835],"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":839,"type":329,"options":840,"correctAnswer":355,"explanation":841},"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.",[355,356],"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":843,"type":329,"options":844,"correctAnswer":846,"explanation":849},"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?",[845,846,847,848],"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":851,"type":329,"options":852,"correctAnswer":856,"explanation":857},"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?",[853,854,855,856],"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":859,"type":329,"options":860,"correctAnswer":862,"explanation":865},"Which pairing correctly matches a virtual networking concept to its equivalent product name?",[861,862,863,864],"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":655,"description":656},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/02-core-cloud-services/05-cloud-networking-basics","0SX2qccPGNhQBbG5JDix81hbDCTg9cH8MYkBC0YuQOI"]