[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"next-cloud-computing-fundamentals-security-and-reliability-reliability-and-operations-monitoring-and-slas-en":4,"prev-cloud-computing-fundamentals-security-and-reliability-reliability-and-operations-monitoring-and-slas-en":337,"lesson-cloud-computing-fundamentals-security-and-reliability-reliability-and-operations-monitoring-and-slas-en":652},null,{"locked":5,"reason":3,"meta":6,"item":17},false,{"title":7,"description":8,"isFree":9,"estimatedMinutes":10,"difficulty":11,"learningObjectives":12},"Cloud Job Roles","The cloud job titles teams actually hire for, what each one owns day to day, and how to tell a Cloud Engineer from a Cloud Architect, a DevOps Engineer, an SRE, and a cloud security specialist.",true,15,"beginner",[13,14,15,16],"Identify the core cloud job roles teams hire for and what each one owns day to day","Distinguish a Cloud Architect from a Cloud Engineer by scope, seniority, and decision-making authority","Explain how DevOps and Site Reliability Engineering reframe operations as a software engineering discipline","Map each cloud job role back to the service models, security, and reliability concepts covered earlier in this course",{"id":18,"title":7,"body":19,"description":8,"difficulty":11,"estimatedMinutes":10,"extension":263,"infographics":264,"isFree":9,"learningObjectives":278,"meta":279,"navigation":9,"path":280,"quiz":281,"seo":334,"stem":335,"__hash__":336},"courses/courses/cloud-computing-fundamentals/en/domains/04-cloud-careers-and-certifications/01-working-in-the-cloud/01-cloud-job-roles.md",{"type":20,"value":21,"toc":247},"minimark",[22,27,31,34,38,41,44,48,51,54,58,125,129,132,135,139,142,145,149,152,156,226,230,233,237,240,244],[23,24,26],"h2",{"id":25},"when-one-skill-set-becomes-5-different-job-titles","When one skill set becomes 5 different job titles",[28,29,30],"p",{},"You finish the security domain of this course comfortable with IAM policies and the shared responsibility model, so you open a job board and search \"cloud.\" The results come back as Cloud Engineer, Cloud Architect, DevOps Engineer, Site Reliability Engineer, and Cloud Security Engineer, and half of them list the same requirements: AWS or Azure, networking, IAM, some scripting. Nothing so far tells you which one to apply to.",[28,32,33],{},"The postings do not diverge on which cloud provider or which services they mention. They diverge on 2 things: what you would actually spend your day doing, and how much authority you would have over the overall design. Learn to read for those 2 signals and the job board stops looking like 5 versions of the same role.",[23,35,37],{"id":36},"cloud-engineer-building-and-operating-what-the-architecture-specifies","Cloud Engineer: building and operating what the architecture specifies",[28,39,40],{},"A Cloud Engineer takes a design that already exists, in whole or in outline, and builds it: provisioning compute and storage, wiring up networking, writing the infrastructure-as-code scripts covered earlier in this course, and keeping the running system healthy afterward. This is usually the most common entry point into cloud work, since the day-to-day is concrete and closely tied to the services you have already studied.",[28,42,43],{},"A typical week looks like standing up a new VPC and subnet layout from a ticket, debugging why an Auto Scaling group is not launching new instances, or updating a Terraform script to add a database read replica. The work is hands-on and the decisions are mostly local: how to implement a piece of the system, not whether the system should look that way in the first place.",[23,45,47],{"id":46},"cloud-architect-designing-the-system-and-owning-the-tradeoffs","Cloud Architect: designing the system and owning the tradeoffs",[28,49,50],{},"A Cloud Architect works one level up. Instead of implementing a piece of the system, the architect decides what the whole system should look like: which services fit a set of business requirements, where redundancy and cost tradeoffs sit, and how the pieces connect. This role usually comes after several years of engineering experience, since the job is to anticipate consequences a less experienced engineer has not yet had the chance to see firsthand.",[28,52,53],{},"A cloud architect is like a building's architect. The architect draws the blueprint, decides where the load-bearing walls go (which is where the redundancy and scaling decisions live), and chooses the materials, which in a cloud system means choosing the services. The Cloud Engineer is the general contractor's crew: they pour the foundation, run the wiring, and build exactly what the blueprint specifies, then keep the finished building running. The analogy holds for the design-versus-build split, but it breaks in 1 place: a cloud architecture keeps changing after it ships, unlike a finished building, so the same engineer often moves back and forth between building and design decisions as the system evolves. The 2 roles are less cleanly separated in practice than they are on a real construction site.",[23,55,57],{"id":56},"boundary-telling-architect-and-engineer-apart-in-a-real-posting","Boundary: telling Architect and Engineer apart in a real posting",[59,60,61,77],"table",{},[62,63,64],"thead",{},[65,66,67,71,74],"tr",{},[68,69,70],"th",{},"Dimension",[68,72,73],{},"Cloud Engineer",[68,75,76],{},"Cloud Architect",[78,79,80,92,103,114],"tbody",{},[65,81,82,86,89],{},[83,84,85],"td",{},"Primary output",[83,87,88],{},"A running, correctly configured system",[83,90,91],{},"A design that meets business and technical requirements",[65,93,94,97,100],{},[83,95,96],{},"Typical seniority",[83,98,99],{},"Entry to mid-level",[83,101,102],{},"Senior, usually 5+ years of engineering experience",[65,104,105,108,111],{},[83,106,107],{},"Decision scope",[83,109,110],{},"How to implement a piece of the system",[83,112,113],{},"Which services and structure the whole system should use",[65,115,116,119,122],{},[83,117,118],{},"Example task",[83,120,121],{},"Fix a failing Auto Scaling health check",[83,123,124],{},"Choose between a monolith on EC2 and a serverless design for a new product",[23,126,128],{"id":127},"devops-engineer-and-platform-engineer-treating-operations-as-a-software-problem","DevOps Engineer and Platform Engineer: treating operations as a software problem",[28,130,131],{},"You already met DevOps as a practice earlier in this course, as the culture and tooling that closes the gap between writing code and running it. DevOps Engineer is that same idea as a job title: someone who builds and maintains the CI/CD pipeline and the infrastructure-as-code automation that lets developers ship without a manual handoff to a separate operations team. Platform Engineer is a closely related, increasingly common title for the same underlying idea: building the internal tools and paved paths that let other engineers deploy safely on their own.",[28,133,134],{},"A concrete task looks like writing a GitHub Actions pipeline that runs tests, builds a container image, and deploys it to a staging environment automatically on every merge, with no one manually copying files to a server.",[23,136,138],{"id":137},"site-reliability-engineer-the-same-idea-aimed-at-uptime","Site Reliability Engineer: the same idea, aimed at uptime",[28,140,141],{},"Google, which coined the term, describes Site Reliability Engineering directly: SRE is what happens when you ask a software engineer to design an operations function. An SRE spends the day building the monitoring, alarms, and automated remediation covered in the reliability domain of this course, the SLIs and SLOs that measure whether a system is healthy, and the automation that fixes an entire class of failure instead of hand-fixing each individual incident.",[28,143,144],{},"It is tempting to hear \"SRE\" and assume it is system administration with a more modern-sounding title. It is not. Traditional system administration responds to problems by hand, one at a time. SRE responds by writing software that prevents or automatically resolves the whole category of problem, which is a genuinely different skill set built on programming, not just operations experience.",[23,146,148],{"id":147},"cloud-security-engineer-operationalizing-the-customers-side-of-shared-responsibility","Cloud Security Engineer: operationalizing the customer's side of shared responsibility",[28,150,151],{},"A cloud security engineer takes the shared responsibility model from earlier in this course and turns it into daily work: writing and auditing IAM policies, scanning for misconfigured storage buckets left open to the public, reviewing encryption settings on data at rest and in transit, and checking that governance and compliance controls are actually enforced, not just documented. This role exists at organizations of every size, since a misconfigured IAM policy or an open storage bucket is exactly as damaging at a 3-person startup as it is at a large enterprise.",[23,153,155],{"id":154},"how-the-roles-line-up","How the roles line up",[59,157,158,171],{},[62,159,160],{},[65,161,162,165,168],{},[68,163,164],{},"Role",[68,166,167],{},"Core focus",[68,169,170],{},"Builds on",[78,172,173,183,193,204,215],{},[65,174,175,177,180],{},[83,176,73],{},[83,178,179],{},"Building and running infrastructure",[83,181,182],{},"Compute, storage, networking basics",[65,184,185,187,190],{},[83,186,76],{},[83,188,189],{},"Designing systems and owning tradeoffs",[83,191,192],{},"Service models, cost, reliability patterns",[65,194,195,198,201],{},[83,196,197],{},"DevOps / Platform Engineer",[83,199,200],{},"Automating the path from code to running system",[83,202,203],{},"Infrastructure as code, CI/CD",[65,205,206,209,212],{},[83,207,208],{},"Site Reliability Engineer",[83,210,211],{},"Applying software engineering to uptime",[83,213,214],{},"Monitoring, SLIs and SLOs, incident response",[65,216,217,220,223],{},[83,218,219],{},"Cloud Security Engineer",[83,221,222],{},"Operationalizing the customer's side of security",[83,224,225],{},"Shared responsibility, IAM, encryption",[23,227,229],{"id":228},"the-demand-behind-these-roles","The demand behind these roles",[28,231,232],{},"The US Bureau of Labor Statistics does not track an occupation called \"Cloud Engineer\" directly, but its closest official category, Computer Network Architects, projects about 11,200 openings a year over the next decade, driven in large part by the continued expansion of cloud computing and the network redesigns that come with it. That single figure understates the real demand, since it excludes cloud-focused developer, administrator, and security roles entirely, but it is a useful, conservative signal that the underlying trend is real and government-tracked, not just industry marketing.",[23,234,236],{"id":235},"getting-in-without-years-of-production-experience","Getting in without years of production experience",[28,238,239],{},"It is tempting to assume every one of these roles requires years of prior on-premises experience before a company will consider you for cloud work. Entry-level cloud postings routinely accept a different kind of proof instead: hands-on lab work, personal projects you can describe in an interview, and a foundational certification. None of that requires a paid job first, which is exactly what the next lesson in this topic sets you up to build.",[23,241,243],{"id":242},"where-this-leaves-you","Where this leaves you",[28,245,246],{},"The 5 roles all draw on the same foundation of compute, storage, networking, and IAM you have built across this course; what separates them is scope (implementing versus designing), method (manual operations versus automated engineering), and focus (building, running, or securing). Knowing that map tells you which job postings actually match what you want to spend your day doing. The next lesson turns from knowing the map to proving you can do the work, using free hands-on practice instead of a paid job.",{"title":248,"searchDepth":249,"depth":249,"links":250},"",3,[251,253,254,255,256,257,258,259,260,261,262],{"id":25,"depth":252,"text":26},2,{"id":36,"depth":252,"text":37},{"id":46,"depth":252,"text":47},{"id":56,"depth":252,"text":57},{"id":127,"depth":252,"text":128},{"id":137,"depth":252,"text":138},{"id":147,"depth":252,"text":148},{"id":154,"depth":252,"text":155},{"id":228,"depth":252,"text":229},{"id":235,"depth":252,"text":236},{"id":242,"depth":252,"text":243},"md",[265],{"slug":266,"concept":267,"style":268,"aspectRatio":269,"labels":270},"cloud-job-roles-map","A branching diagram with a single foundation bar at the bottom labeled with the shared cloud skill floor, and 5 branches rising from it, one per job role, each ending in a labeled node with a one-line differentiator. The branch point visually shows that every role grows out of the same foundation but diverges immediately into a different day-to-day focus. A footer strip carries the closing takeaway line.","diagram","16:9",[271,272,273,274,275,276,277],"Foundation: compute, storage, networking, and IAM","Cloud Engineer: builds and operates what the architecture specifies","Cloud Architect: designs the system and owns the tradeoffs","DevOps Engineer: automates the pipeline between building and running","Site Reliability Engineer: applies software engineering to uptime","Cloud Security Engineer: operationalizes the customer's side of shared responsibility","Same foundation, 5 different day-to-day focuses",[13,14,15,16],{},"/courses/cloud-computing-fundamentals/en/domains/04-cloud-careers-and-certifications/01-working-in-the-cloud/01-cloud-job-roles",{"passingScore":282,"questions":283},70,[284,293,301,307,315,326],{"question":285,"type":286,"options":287,"correctAnswer":290,"explanation":292},"A job posting titled 'Cloud Architect' asks for 8+ years of experience and describes translating business requirements into a target design across compute, network, and data services, with an engineering team implementing the day-to-day work. Which distinction does this posting best illustrate?","single",[288,289,290,291],"Cloud Architects only handle networking, while Cloud Engineers handle everything else","There is no real difference; Cloud Architect and Cloud Engineer are the same role with different titles","Cloud Architects typically design the overall system and its tradeoffs; Cloud Engineers typically build, deploy, and operate what that design calls for","Cloud Engineers must hold a professional-level certification before any Cloud Architect can hold an associate-level one","The posting's own language, translating requirements into a design versus implementing the day-to-day work, maps directly onto the architect-versus-engineer split: one role owns the blueprint and its tradeoffs, the other owns building and running what the blueprint specifies. The other options either invent a false restriction (networking only), erase a real distinction in scope and seniority, or describe a certification order that does not exist.",{"question":294,"type":286,"options":295,"correctAnswer":296,"explanation":300},"A team hires a 'DevOps Engineer' to build CI/CD pipelines, automate infrastructure provisioning, and remove the manual handoff between developers and operations. Which idea does this role primarily embody?",[296,297,298,299],"Treating deployment and operations work as something to automate and integrate into the development process, instead of a separate manual handoff","Manually approving every deployment by hand to catch errors before release","Replacing software developers entirely with automated pipelines","A rebranded title for a database administrator","DevOps, as a job, is built around automating the path from committed code to running system, which is exactly what CI/CD pipelines and infrastructure automation do. It does not mean manual gatekeeping, replacing developers, or database administration, which are unrelated to the automation and integration focus the title describes.",{"question":302,"type":286,"options":303,"correctAnswer":305,"explanation":306},"Site Reliability Engineering, as Google defines it, is fundamentally a rebrand of traditional system administration with a new job title, and the day-to-day work is the same.",[304,305],"True","False","Google's own description of SRE is what happens when you ask a software engineer to design an operations function: SREs write code and automation to fix entire classes of problems, rather than manually resolving each incident the way traditional system administration does. The title change reflects a real shift in method, not just a relabeling of the same daily work.",{"question":308,"type":286,"options":309,"correctAnswer":313,"explanation":314},"A cloud security engineer spends much of the day writing IAM policies, scanning for misconfigured storage buckets, and reviewing encryption settings. Which earlier course concept does this role most directly put into practice day to day?",[310,311,312,313],"Capital expenditure versus operating expenditure","The 5 characteristics of cloud computing","Hybrid and multi-cloud networking topologies","The customer's side of the shared responsibility model","Writing IAM policies, checking storage configurations, and reviewing encryption settings are exactly the tasks that fall to the customer under the shared responsibility model, since the provider secures the underlying infrastructure but never the customer's own access controls, data, or configuration choices. The other 3 concepts describe real ideas from this course, but none of them is what a security engineer's daily checklist is built around.",{"question":316,"type":317,"options":318,"correctAnswers":324,"explanation":325},"Select all true statements about these cloud job roles.","multiple",[319,320,321,322,323],"A Cloud Engineer role typically involves more hands-on building and operating of infrastructure than a Cloud Architect role does","SRE work applies software engineering practices, like writing code and automation, to what used to be manual operations work","A DevOps Engineer's job is limited to writing application code, with no involvement in deployment or infrastructure","Cloud security specialists exist only at large enterprises and are not part of small startup teams","Moving from Cloud Engineer to Cloud Architect typically comes with more experience and a shift toward higher-level design decisions",[319,320,323],"The Cloud Engineer/Architect split, the software-engineering framing of SRE, and the typical Engineer-to-Architect career progression are all accurate descriptions covered in this lesson. DevOps Engineers are defined by their involvement in deployment and infrastructure automation, not writing application code in isolation from it, and cloud security work is just as real a need on a 3-person startup team as it is at a large enterprise.",{"question":327,"type":286,"options":328,"correctAnswer":330,"explanation":333},"Which statement most accurately describes how someone typically breaks into an entry-level cloud role, such as junior cloud engineer or cloud support associate?",[329,330,331,332],"Every cloud role requires a computer science degree and 5+ years of on-premises data center experience first","Demonstrated hands-on cloud skills, such as personal projects, lab work, and a foundational certification, commonly substitute for years of prior production experience","Cloud roles are closed to anyone without a professional-level certification","Every cloud career must start in a Cloud Architect position before moving into any other title","Employers hiring for entry-level cloud roles routinely accept demonstrated hands-on skill, built through labs, personal projects, and a foundational certification, in place of years of prior production experience. A degree plus years of on-premises experience, a professional-level certification, or starting at the most senior title in the field are not realistic requirements for a first cloud job.",{"title":7,"description":8},"courses/cloud-computing-fundamentals/en/domains/04-cloud-careers-and-certifications/01-working-in-the-cloud/01-cloud-job-roles","6lwL5KEPyUQlvIGsOXUQJ3h0tbA0H0KN0Iu5JS_SGvQ",{"locked":5,"reason":3,"meta":338,"item":348},{"title":339,"description":340,"isFree":5,"estimatedMinutes":341,"difficulty":342,"learningObjectives":343},"Backup and Disaster Recovery","What Recovery Time Objective and Recovery Point Objective actually bound, and the 4 disaster recovery strategies cloud teams choose between when redundancy inside a region was not enough.",20,"intermediate",[344,345,346,347],"Define Recovery Time Objective and Recovery Point Objective and explain what each one bounds","Explain how AWS Backup automates data protection through backup plans, schedules, and retention rules","Compare backup and restore, pilot light, warm standby, and multi-site active/active by cost, complexity, and recovery speed","Apply a scenario's RTO and RPO requirements to choose the appropriate disaster recovery strategy",{"id":349,"title":339,"body":350,"description":340,"difficulty":342,"estimatedMinutes":341,"extension":263,"infographics":582,"isFree":5,"learningObjectives":583,"meta":584,"navigation":9,"path":585,"quiz":586,"seo":649,"stem":650,"__hash__":651},"courses/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/03-backup-and-disaster-recovery.md",{"type":20,"value":351,"toc":570},[352,356,359,363,366,373,379,382,386,389,393,396,472,475,479,482,486,489,493,496,500,503,507,565,567],[23,353,355],{"id":354},"when-redundancy-inside-a-region-was-not-enough","When redundancy inside a region was not enough",[28,357,358],{},"The last 2 lessons covered redundancy inside a single AWS Region: spreading instances and databases across Availability Zones so that 1 data center's failure doesn't take the whole system down. That protects against a hardware failure or a power outage. It does nothing if a bad deployment corrupts a database table, or if an entire geographic region goes dark, the exact gap the regions-and-Availability-Zones lesson flagged earlier in this course. This lesson is about the plan for exactly that: when the failure is bigger than AZ-level redundancy was ever built to absorb.",[23,360,362],{"id":361},"two-questions-before-any-recovery-plan-how-much-data-how-long-down","Two questions before any recovery plan: how much data, how long down",[28,364,365],{},"Every disaster recovery plan starts by answering 2 separate questions, and mixing them up is the most common mistake teams make.",[28,367,368,372],{},[369,370,371],"strong",{},"Recovery Point Objective (RPO)"," bounds acceptable data loss. It answers \"how much data can we afford to lose,\" measured as the maximum acceptable time between now and the last point you could recover from. An RPO of 15 minutes means your backups or replication have to run at least that often, or you risk losing more than the business can tolerate.",[28,374,375,378],{},[369,376,377],{},"Recovery Time Objective (RTO)"," bounds acceptable downtime. It answers \"how long can we be down,\" measured as the maximum acceptable delay between an outage starting and service being restored. An RTO of 1 hour means the entire recovery process, detecting the failure, standing up infrastructure, restoring data, has to finish inside that hour.",[28,380,381],{},"An e-commerce order database with a 15-minute RPO and a 1-hour RTO is promising 2 very different things: at most 15 minutes of lost orders, and at most 1 hour before the store is taking orders again. Meeting both takes deliberate engineering, and meeting them more tightly always costs more.",[23,383,385],{"id":384},"backups-the-foundation-under-every-strategy","Backups: the foundation under every strategy",[28,387,388],{},"No disaster recovery strategy works without reliable backups underneath it. AWS Backup centralizes that work across services, EC2, RDS, DynamoDB, EFS, and more, through backup plans: policies that define schedules and retention. A typical plan might pair a daily rule, backing up every night and keeping each backup for 1 month, with a monthly rule, backing up once a month and keeping that copy for a full year. Resources get assigned to a plan simply by tagging them, and backups can copy automatically to a different AWS Region on the same schedule, which is what turns a routine backup into the raw material a disaster recovery strategy can actually use.",[23,390,392],{"id":391},"the-4-disaster-recovery-strategies-cheapest-to-most-expensive","The 4 disaster recovery strategies, cheapest to most expensive",[28,394,395],{},"With backups as the foundation, the question becomes how much infrastructure you keep running in a secondary location, and readiness costs money whether or not disaster ever strikes.",[59,397,398,414],{},[62,399,400],{},[65,401,402,405,408,411],{},[68,403,404],{},"Strategy",[68,406,407],{},"What runs in the secondary Region before a disaster",[68,409,410],{},"Relative cost",[68,412,413],{},"Relative RTO/RPO",[78,415,416,430,444,458],{},[65,417,418,421,424,427],{},[83,419,420],{},"Backup and restore",[83,422,423],{},"Nothing; only backups exist there",[83,425,426],{},"Lowest",[83,428,429],{},"Slowest, highest data loss risk",[65,431,432,435,438,441],{},[83,433,434],{},"Pilot light",[83,436,437],{},"Core data replicating live; compute stays off until failover",[83,439,440],{},"Low",[83,442,443],{},"Faster, but infrastructure still has to be switched on and scaled",[65,445,446,449,452,455],{},[83,447,448],{},"Warm standby",[83,450,451],{},"A scaled-down but fully running copy of the whole stack",[83,453,454],{},"Moderate",[83,456,457],{},"Faster still; only needs to scale up, not deploy from scratch",[65,459,460,463,466,469],{},[83,461,462],{},"Multi-site active/active",[83,464,465],{},"The full stack, already serving live production traffic",[83,467,468],{},"Highest",[83,470,471],{},"Fastest; failover is rerouting traffic, not building anything",[28,473,474],{},"Backup and restore rebuilds everything, data and infrastructure, from scratch after a disaster is declared, usually through Infrastructure as Code, which is why it takes the longest but costs the least day to day. Pilot light keeps the data layer continuously replicated but leaves the rest of the stack dark, needing to be switched on and scaled before it can serve traffic. Warm standby goes further, keeping a smaller version of the entire application already running, so recovery means scaling an existing deployment up rather than deploying one for the first time. Multi-site active/active removes the switching step entirely: more than 1 Region is already handling production traffic, so a Region-level failure just means rerouting requests away from the Region that can't serve them.",[23,476,478],{"id":477},"worked-example-matching-the-strategy-to-the-requirement","Worked example: matching the strategy to the requirement",[28,480,481],{},"An internal reporting dashboard can tolerate several hours of downtime and losing up to a day of data without hurting the business in any measurable way; backup and restore is not just acceptable here, it's the correct engineering choice, since paying for a warmer strategy would be spending money the requirement never asked for. A payment-authorization service is the opposite case: a minute of downtime or any lost transaction is unacceptable, which justifies the cost and complexity of multi-site active/active. Neither team is wrong. Each has matched the strategy to the RTO and RPO the business actually needs, which is the entire point of having 4 strategies instead of reaching for the most expensive one by default.",[23,483,485],{"id":484},"boundary-backup-and-restore-versus-pilot-light","Boundary: backup and restore versus pilot light",[28,487,488],{},"These 2 are the pair most often confused, because both keep your data safe in a second Region and both look, from the outside, like \"we have backups somewhere else.\" The difference is what happens to compute. Backup and restore has no infrastructure standing by at all; everything gets provisioned from Infrastructure as Code only after a disaster is declared. Pilot light keeps a minimal core, often just the data tier, continuously live and replicating, while the rest of the stack (application servers, for instance) stays completely dark until failover triggers it. That single difference, whether anything besides data is already there waiting, is what separates the cheapest strategy from the next one up.",[23,490,492],{"id":491},"active-active-reappears-at-a-larger-radius","Active-active reappears, at a larger radius",[28,494,495],{},"Multi-site active/active is not a new idea introduced for disaster recovery specifically. It's the active-active redundancy pattern from the previous lesson, where every replica serves traffic simultaneously, stretched from the scale of Availability Zones inside 1 Region to the scale of entire Regions. The mechanism is the same; only the geography and the stakes are bigger.",[23,497,499],{"id":498},"misconception-backups-alone-are-not-a-disaster-recovery-plan","Misconception: backups alone are not a disaster recovery plan",[28,501,502],{},"It's tempting to treat \"we have automated nightly backups in a second Region\" as the same thing as \"we have a disaster recovery plan.\" It isn't. A backup that has never been restored from is a hypothesis about how recovery would go, not evidence that it will. A real plan has a documented, rehearsed restore procedure and a known RTO that leadership has actually signed off on as acceptable. Backups are necessary for every one of the 4 strategies above; they are sufficient for none of them on their own.",[23,504,506],{"id":505},"exam-cues-matching-a-scenario-to-a-strategy","Exam cues: matching a scenario to a strategy",[59,508,509,519],{},[62,510,511],{},[65,512,513,516],{},[68,514,515],{},"The scenario says...",[68,517,518],{},"Points to",[78,520,521,528,535,542,549,557],{},[65,522,523,526],{},[83,524,525],{},"\"Cost-sensitive,\" \"can tolerate hours or days of downtime\"",[83,527,420],{},[65,529,530,533],{},[83,531,532],{},"\"Core data must stay current, but full infrastructure cost is a concern\"",[83,534,434],{},[65,536,537,540],{},[83,538,539],{},"\"Needs faster recovery than pilot light, already-running but scaled-down\"",[83,541,448],{},[65,543,544,547],{},[83,545,546],{},"\"Cannot tolerate any noticeable downtime, cost is secondary\"",[83,548,462],{},[65,550,551,554],{},[83,552,553],{},"\"Maximum acceptable data loss\"",[83,555,556],{},"RPO",[65,558,559,562],{},[83,560,561],{},"\"Maximum acceptable downtime\"",[83,563,564],{},"RTO",[23,566,243],{"id":242},[28,568,569],{},"Choosing a disaster recovery strategy is choosing a point on a dial between steady-state cost and recovery speed, not searching for a single best answer; the right point is wherever the business's actual RTO and RPO land, no more expensive than that. Backups make every strategy possible, but only a tested restore procedure turns them into an actual plan. The next lesson closes out this topic by asking a different question: how do you actually find out a failure happened at all, and what does a cloud provider's SLA really promise when it does?",{"title":248,"searchDepth":249,"depth":249,"links":571},[572,573,574,575,576,577,578,579,580,581],{"id":354,"depth":252,"text":355},{"id":361,"depth":252,"text":362},{"id":384,"depth":252,"text":385},{"id":391,"depth":252,"text":392},{"id":477,"depth":252,"text":478},{"id":484,"depth":252,"text":485},{"id":491,"depth":252,"text":492},{"id":498,"depth":252,"text":499},{"id":505,"depth":252,"text":506},{"id":242,"depth":252,"text":243},[],[344,345,346,347],{},"/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/03-backup-and-disaster-recovery",{"passingScore":282,"questions":587},[588,596,604,612,621,629,633,641],{"question":589,"type":286,"options":590,"correctAnswer":592,"explanation":595},"A company's Recovery Point Objective for its order database is 15 minutes. What does this actually specify?",[591,592,593,594],"The system must be back online within 15 minutes of an outage","The company can afford to lose at most 15 minutes of data since the last recoverable backup or replica","Backups must be tested every 15 minutes","The database must respond to queries within 15 minutes","RPO bounds acceptable data loss, measured backward in time from the moment of failure to the last point you could recover from. A 15-minute RPO means backups or replication have to happen at least every 15 minutes; anything less frequent would risk losing more data than the objective allows. It says nothing about how fast the system comes back online, which is what RTO measures instead.",{"question":597,"type":286,"options":598,"correctAnswer":600,"explanation":603},"Which of the following correctly matches a disaster recovery strategy to its defining characteristic?",[599,600,601,602],"Pilot light: multiple regions actively serve production traffic at the same time","Backup and restore: infrastructure is rebuilt from backups and Infrastructure as Code only after a disaster is declared","Warm standby: no infrastructure exists in the secondary region until failover begins","Multi-site active/active: a minimal, idle copy of core infrastructure sits ready in a secondary region","Backup and restore is the cheapest and slowest strategy precisely because nothing runs in the secondary region until a disaster actually happens; everything, data and infrastructure alike, gets rebuilt on demand. Pilot light keeps core data live with idle infrastructure ready to switch on; warm standby keeps a scaled-down version already running; multi-site active/active keeps multiple regions actively serving traffic simultaneously.",{"question":605,"type":286,"options":606,"correctAnswer":608,"explanation":611},"Rank the 4 disaster recovery strategies from lowest cost and slowest recovery to highest cost and fastest recovery.",[607,608,609,610],"Multi-site active/active, warm standby, pilot light, backup and restore","Backup and restore, pilot light, warm standby, multi-site active/active","Pilot light, backup and restore, multi-site active/active, warm standby","Warm standby, backup and restore, multi-site active/active, pilot light","The 4 strategies form a spectrum: backup and restore is cheapest and slowest because nothing runs until disaster strikes, and each strategy after it keeps progressively more infrastructure already running in the secondary region, trading higher steady-state cost for progressively lower RTO and RPO, until multi-site active/active reaches the fastest recovery by already serving live traffic from more than 1 region.",{"question":613,"type":317,"options":614,"correctAnswers":619,"explanation":620},"Which of the following are true about AWS Backup? (Select all that apply.)",[615,616,617,618],"A backup plan can define multiple rules, such as a daily rule with a 1-month retention and a monthly rule with a 1-year retention","It only supports Amazon EC2 instances, not managed services like RDS or DynamoDB","Resources are commonly assigned to a backup plan by tagging them","It can copy backups to a different AWS Region as part of a scheduled plan",[615,617,618],"AWS Backup centralizes backup policy across many AWS services, including RDS, DynamoDB, EFS, and Storage Gateway alongside EC2, so limiting it to EC2 alone is incorrect. Tag-based assignment, multi-rule plans with independent retention periods, and cross-Region copy are all real features, and cross-Region copy specifically is what makes AWS Backup useful as the data layer underneath a disaster recovery strategy, not just routine data protection.",{"question":622,"type":286,"options":623,"correctAnswer":625,"explanation":628},"A company has automated backups running every night and stores them safely in a second AWS Region. Its leadership considers this a complete disaster recovery plan. What is missing from that conclusion?",[624,625,626,627],"Nothing; backups alone are sufficient for any disaster recovery plan","A tested, documented restore procedure with a known RTO, not just the existence of backups","The backups need to be stored in the same Region to count as a disaster recovery plan","Disaster recovery plans cannot use automated backups at all","Backups are the foundation every disaster recovery strategy sits on, but a backup nobody has ever restored from is a hypothesis, not a plan. A real plan has a tested restore procedure, a documented and rehearsed set of steps, and a known RTO that leadership has actually agreed is acceptable, not just confidence that data exists somewhere safe.",{"question":630,"type":286,"options":631,"correctAnswer":304,"explanation":632},"Multi-site active/active disaster recovery is the same concept as active-active redundancy across Availability Zones from the previous lesson, applied at a larger scale.",[304,305],"The active-active pattern doesn't change between the 2 lessons, only its radius does. Within a Region, active-active means multiple Availability Zones simultaneously serve traffic. Multi-site active/active stretches the same idea across multiple Regions, so that even losing an entire Region leaves other Regions already serving requests, with failover reduced to rerouting traffic rather than starting anything from scratch.",{"question":634,"type":286,"options":635,"correctAnswer":637,"explanation":640},"An internal reporting dashboard can tolerate several hours of downtime and the loss of up to a day's data without meaningfully hurting the business. A payment-authorization service cannot tolerate more than a minute of downtime or any data loss at all. Which strategy pairing best fits each system?",[636,637,638,639],"Both systems should use multi-site active/active, since it is always the safest choice","The dashboard fits backup and restore; the payment service fits multi-site active/active","The dashboard fits multi-site active/active; the payment service fits backup and restore","Both systems should use pilot light, since it is a balanced middle option","Matching the strategy to the actual RTO and RPO the business needs, not defaulting to the most expensive option everywhere, is the point of having 4 strategies instead of 1. The dashboard's generous tolerances make the cheapest strategy the right engineering choice; the payment service's near-zero tolerance justifies the cost and complexity of running live in more than 1 Region at once.",{"question":642,"type":286,"options":643,"correctAnswer":645,"explanation":648},"Why is a low RTO and RPO more expensive to achieve than a higher one?",[644,645,646,647],"Cloud providers charge a fixed penalty fee for choosing a low RTO","Achieving a low RTO and RPO generally requires running more infrastructure continuously, in more than 1 location, rather than building it only after a disaster occurs","Low RTO and RPO values are only a marketing distinction with no real infrastructure difference","It is not more expensive; all 4 strategies cost the same to operate","Every step from backup and restore toward multi-site active/active trades a lower steady-state cost for a slower recovery, or a higher steady-state cost for a faster one. There is no way to get instant, lossless recovery without something already running and ready to take over, and that something bills you whether or not a disaster ever happens.",{"title":339,"description":340},"courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/03-backup-and-disaster-recovery","AsZCE0m54MMgw_6Y7GFMwlnG2NgZ1_KgsnK7mzsHq3Y",{"locked":5,"reason":3,"meta":653,"item":662},{"title":654,"description":655,"isFree":5,"estimatedMinutes":656,"difficulty":342,"learningObjectives":657},"Monitoring and SLAs","How metrics, logs, and alarms tell you a system is failing, what an uptime percentage costs in real downtime, and what a cloud provider's SLA actually promises when it doesn't hold.",19,[658,659,660,661],"Explain how monitoring uses metrics, logs, and alarms to detect a problem as or before it happens","Convert an uptime percentage into its equivalent downtime and explain why each additional nine matters","Distinguish SLI, SLO, and SLA and explain what happens when each one is missed","Interpret a real cloud SLA's compensation structure and explain what it does and does not guarantee",{"id":663,"title":654,"body":664,"description":655,"difficulty":342,"estimatedMinutes":656,"extension":263,"infographics":863,"isFree":5,"learningObjectives":864,"meta":865,"navigation":9,"path":866,"quiz":867,"seo":918,"stem":919,"__hash__":920},"courses/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/04-monitoring-and-slas.md",{"type":20,"value":665,"toc":852},[666,670,673,677,680,683,687,690,705,708,711,715,718,764,767,771,774,777,781,784,788,791,795,847,849],[23,667,669],{"id":668},"every-pattern-in-this-topic-assumes-you-find-out","Every pattern in this topic assumes you find out",[28,671,672],{},"Multi-AZ redundancy, Auto Scaling health checks, a tested disaster recovery plan: every pattern this topic has covered so far quietly assumes something. It assumes you find out a failure is happening, ideally before a user does, and it assumes someone can say afterward, in hard numbers, how reliable the system actually was. This lesson covers both halves: monitoring, which is how you find out, and SLAs, which are the documented promise about how often you shouldn't have had to.",[23,674,676],{"id":675},"monitoring-metrics-logs-and-alarms","Monitoring: metrics, logs, and alarms",[28,678,679],{},"3 building blocks cover almost everything a monitoring setup does. A metric is a number tracked over time, average CPU utilization, requests per second, error rate. A log is a record of a specific event, a line saying exactly what happened and when, useful for investigating after something already went wrong rather than watching a trend. An alarm watches a metric against a threshold and takes an action once that threshold is breached for a defined period.",[28,681,682],{},"Amazon CloudWatch is AWS's implementation of all 3: it collects metrics automatically from most AWS services, stores and lets you query logs, and lets you define alarms on top of either. A concrete example: an alarm watches average CPU utilization in 5-minute periods, and if it stays above 80% for 3 consecutive periods, the alarm triggers, which might page an on-call engineer or, tying back to the previous lesson, feed directly into an Auto Scaling target-tracking policy that launches more capacity. Azure Monitor and Google Cloud Operations play the equivalent role on their own platforms; the vocabulary shifts slightly, but metrics, logs, and alarms are the same 3 pieces everywhere.",[23,684,686],{"id":685},"sli-slo-sla-measuring-targeting-promising","SLI, SLO, SLA: measuring, targeting, promising",[28,688,689],{},"These 3 terms get used almost interchangeably in casual conversation, and the exam boundary between them is worth learning precisely.",[28,691,692,693,696,697,700,701,704],{},"A ",[369,694,695],{},"Service Level Indicator (SLI)"," is a quantitative measurement of how a service is actually performing, like the percentage of requests that succeed. A ",[369,698,699],{},"Service Level Objective (SLO)"," is the internal target a team sets for that SLI, like \"we aim for 99.95% successful requests.\" A ",[369,702,703],{},"Service Level Agreement (SLA)"," is the external, contractual version: a promise made to customers that, if missed, carries financial consequences, typically a service credit.",[28,706,707],{},"Think of an SLI as a car's speedometer reading, an SLO as the speed limit the driver privately commits to staying under, and an SLA as the promise made to a passenger that the trip won't exceed a certain speed, backed by a refund if it does. The comparison holds for the relationship between measuring, targeting, and promising, but it breaks on 1 point: an SLI isn't usually a single instant reading like a speedometer, it's typically aggregated over a window of time, an hour or a month, not a live glance at the dashboard.",[28,709,710],{},"Providers deliberately set the SLO stricter than the SLA. If a public SLA promises 99.9% uptime, the internal SLO driving day-to-day operations might be 99.95%, giving the team a buffer to notice and react before a missed internal target turns into a missed, compensable external promise.",[23,712,714],{"id":713},"the-nines-what-an-uptime-percentage-costs-in-real-downtime","The nines: what an uptime percentage costs in real downtime",[28,716,717],{},"Availability numbers get compared casually, \"we're at 4 nines,\" without always registering what that actually means in hours. Each additional nine divides the allowed downtime by roughly 10, which is why the jump from 99.9% to 99.99% is a far bigger engineering commitment than the numbers alone suggest.",[59,719,720,730],{},[62,721,722],{},[65,723,724,727],{},[68,725,726],{},"Uptime",[68,728,729],{},"Allowed downtime per year",[78,731,732,740,748,756],{},[65,733,734,737],{},[83,735,736],{},"99% (2 nines)",[83,738,739],{},"About 3.65 days",[65,741,742,745],{},[83,743,744],{},"99.9% (3 nines)",[83,746,747],{},"About 8.76 hours",[65,749,750,753],{},[83,751,752],{},"99.99% (4 nines)",[83,754,755],{},"About 52 minutes",[65,757,758,761],{},[83,759,760],{},"99.999% (5 nines)",[83,762,763],{},"About 5 minutes",[28,765,766],{},"Most SaaS products and APIs target 3 nines. 5 nines is reserved for systems where even a few minutes of annual downtime carries real financial or safety consequences, and it costs proportionally more to engineer.",[23,768,770],{"id":769},"worked-example-reading-a-real-sla","Worked example: reading a real SLA",[28,772,773],{},"The Amazon EC2 SLA is a useful, concrete case. It commits to a Region-level Monthly Uptime Percentage of at least 99.99%, and separately to an Instance-Level Uptime Percentage of at least 99.5% for individual instances. If actual Region-level uptime in a given month falls short, the credit tiers are 10% for 99.0% up to (but not including) 99.99%, 30% for 95.0% up to (but not including) 99.0%, and 100% below 95.0%.",[28,775,776],{},"Concretely: if Region-level EC2 uptime lands at 98.5% one month, that falls in the 95.0%-to-under-99.0% band, and the customer is eligible for a 30% credit on that service's bill for the month, applied automatically or on request depending on the provider, not a cash refund and not compensation for whatever revenue the outage cost the customer's own business.",[23,778,780],{"id":779},"what-an-sla-promises-and-what-it-does-not","What an SLA promises, and what it does not",[28,782,783],{},"It's tempting to treat \"backed by an SLA\" as \"this will never go down\" or as insurance against business losses. Neither is true. An SLA is a compensation mechanism for the provider's own failure to meet its own published commitment, paid out as a credit against future bills. It commonly excludes scheduled maintenance windows and factors outside the provider's control, and, just like the shared responsibility model from earlier in this domain, it only ever covers the provider's own service. An outage caused by a bug in the customer's own application code is the customer's reliability problem to monitor and fix; no provider SLA was ever written to cover it.",[23,785,787],{"id":786},"boundary-chaining-services-makes-the-overall-number-worse-not-better","Boundary: chaining services makes the overall number worse, not better",[28,789,790],{},"A workload rarely depends on just 1 service. Chain 3 services with individual availability of 99.99%, 99.95%, and 99.9%, and it's tempting to assume the strongest one helps pull the average up. It doesn't: composite availability multiplies the individual probabilities rather than averaging them, so 99.99% times 99.95% times 99.9% lands around 99.84%, worse than any single component in the chain. Every added dependency is a tax on overall reliability, which is exactly why architects count how many services a critical request path actually touches, not just how reliable each one is in isolation.",[23,792,794],{"id":793},"exam-cues-matching-a-scenario-to-the-right-term","Exam cues: matching a scenario to the right term",[59,796,797,805],{},[62,798,799],{},[65,800,801,803],{},[68,802,515],{},[68,804,518],{},[78,806,807,815,823,831,839],{},[65,808,809,812],{},[83,810,811],{},"\"Financially backed guarantee,\" \"service credit for downtime\"",[83,813,814],{},"SLA",[65,816,817,820],{},[83,818,819],{},"\"Internal target,\" \"error budget\"",[83,821,822],{},"SLO",[65,824,825,828],{},[83,826,827],{},"\"The actual measured percentage of successful requests\"",[83,829,830],{},"SLI",[65,832,833,836],{},[83,834,835],{},"\"How much downtime does X% allow\"",[83,837,838],{},"The nines table",[65,840,841,844],{},[83,842,843],{},"\"Multiple dependent services chained together\"",[83,845,846],{},"Composite availability, lower than any single component",[23,848,243],{"id":242},[28,850,851],{},"An SLA is a compensation contract set at a floor below what a provider privately targets for itself, never a guarantee that nothing will fail, and monitoring is what actually tells you, in real time, whether today is one of the days that floor gets tested. That closes out Security and Reliability: you can now name who owns which security task, how systems stay up through a failure, how they recover from one bigger than redundancy could absorb, and what a promise about uptime actually means when it doesn't hold. The next domain turns from what you know toward where it takes you: cloud careers and the certification path this course has been building toward all along.",{"title":248,"searchDepth":249,"depth":249,"links":853},[854,855,856,857,858,859,860,861,862],{"id":668,"depth":252,"text":669},{"id":675,"depth":252,"text":676},{"id":685,"depth":252,"text":686},{"id":713,"depth":252,"text":714},{"id":769,"depth":252,"text":770},{"id":779,"depth":252,"text":780},{"id":786,"depth":252,"text":787},{"id":793,"depth":252,"text":794},{"id":242,"depth":252,"text":243},[],[658,659,660,661],{},"/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/04-monitoring-and-slas",{"passingScore":282,"questions":868},[869,877,885,889,897,906,910],{"question":870,"type":286,"options":871,"correctAnswer":873,"explanation":876},"A CloudWatch alarm watches average CPU utilization over 5-minute periods and triggers after 3 consecutive periods above 80%. What is the metric in this setup?",[872,873,874,875],"The 3 consecutive periods","The average CPU utilization value tracked over time","The action the alarm takes once triggered","The 80% threshold itself","A metric is the number being tracked over time, here average CPU utilization. The threshold (80%), the evaluation window (3 consecutive 5-minute periods), and the alarm itself are all built on top of that metric, not separate from it; an alarm is a rule that watches a metric and acts once the rule's condition holds.",{"question":878,"type":286,"options":879,"correctAnswer":881,"explanation":884},"Which of the following correctly orders SLI, SLO, and SLA by what each one represents?",[880,881,882,883],"SLI is a contractual promise; SLO is a measurement; SLA is an internal target","SLI is a quantitative measurement; SLO is an internal target based on that measurement; SLA is an external, often financially backed promise","SLA is a measurement; SLI is an internal target; SLO is a contractual promise","All 3 terms describe the same thing at different companies","The 3 terms sit in a clear chain: an SLI measures something real, like the percentage of successful requests; an SLO sets an internal goal for that SLI, like 99.95% success; an SLA turns a version of that goal into a contractual promise to customers, typically set a little looser than the SLO so there's a buffer before a missed SLO becomes a missed, compensable SLA.",{"question":886,"type":286,"options":887,"correctAnswer":747,"explanation":888},"A service maintains 99.9% uptime over a year. Approximately how much downtime does that allow?",[763,755,747,739],"Each additional nine in an uptime percentage divides the allowed downtime by roughly 10: 99% allows about 3.65 days a year, 99.9% allows about 8.76 hours, 99.99% allows about 52 minutes, and 99.999% allows about 5 minutes. That tenfold jump in engineering difficulty for each extra nine is exactly why providers price and design very differently around 99.9% versus 99.99% commitments.",{"question":890,"type":286,"options":891,"correctAnswer":893,"explanation":896},"Amazon EC2's Region-level SLA commits to at least 99.99% monthly uptime and offers a 10% service credit if actual uptime falls between 99.0% and 99.99%. If EC2 in a Region delivers 98.5% uptime one month, what does the SLA guarantee the customer?",[892,893,894,895],"Full reimbursement of any lost business revenue for that month","A 30% service credit on that service's bill for the month, since 98.5% falls in the 95.0% to less than 99.0% tier","A refund of the customer's entire monthly AWS bill across all services","Nothing, since 98.5% is close enough to the 99.99% commitment","98.5% uptime lands in the 95.0% to less than 99.0% band, which carries a 30% credit under this SLA's tiered structure, not the 10% tier just above it. That credit applies to the affected service's bill, not the customer's total spend and never to whatever revenue the customer's own business lost during the downtime, which is exactly the boundary the next question in this quiz tests directly.",{"question":898,"type":317,"options":899,"correctAnswers":904,"explanation":905},"Which of the following are true about what a cloud provider's SLA guarantees? (Select all that apply.)",[900,901,902,903],"It typically compensates with service credits toward future bills, not cash reimbursement for a customer's lost business","It guarantees the service will never experience any downtime","It commonly excludes scheduled maintenance and factors outside the provider's control","Meeting the SLA is usually easier for the provider than meeting its own internal SLO, since the SLA is typically set looser",[900,902,903],"An SLA is a compensation mechanism for the provider's own failure to meet a published commitment, not an insurance policy against a customer's business losses, and it never promises zero downtime, only a bounded, credited amount of it. Providers deliberately set their internal SLO stricter than the public SLA, so a missed SLO gives them a chance to react before it becomes a missed, compensable SLA.",{"question":907,"type":286,"options":908,"correctAnswer":305,"explanation":909},"A workload depends on 3 chained services with individual availability of 99.99%, 99.95%, and 99.9%. The overall system's effective availability is higher than any single component's availability, since the strongest component pulls the average up.",[304,305],"A composite availability is the product of the individual probabilities, not an average, so chaining dependent services always pulls the overall figure below the weakest link, not up toward the strongest one. Multiplying 99.99% by 99.95% by 99.9% lands around 99.84%, worse than any 1 component alone, which is why architects treat every added dependency as a tax on overall reliability.",{"question":911,"type":286,"options":912,"correctAnswer":914,"explanation":917},"A startup treats its cloud provider's published SLA as a guarantee that its own application will never go down. An outage happens due to a bug in the startup's own application code. Can the startup claim an SLA credit for this outage?",[913,914,915,916],"Yes, since the provider's SLA covers any downtime regardless of cause","No, since the provider's SLA covers the availability of the provider's own service, not failures caused by the customer's own code","Yes, but only if the startup contacts support within 24 hours","It depends only on which AWS Region the application runs in","This is the shared responsibility model reappearing in a new form: a provider's SLA is scoped to the infrastructure and services it operates, not to whatever a customer builds and runs on top of them. An outage rooted in the customer's own application code is the customer's own reliability problem to monitor, alarm on, and fix, not something any provider SLA was ever written to cover.",{"title":654,"description":655},"courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/04-monitoring-and-slas","aZP7DSh_93EReBS9CJCCrTkPoqSFB0WHN46E-2emKn8"]