[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"lesson-cloud-computing-fundamentals-cloud-careers-and-certifications-working-in-the-cloud-cloud-job-roles-en":4,"next-cloud-computing-fundamentals-cloud-careers-and-certifications-working-in-the-cloud-cloud-job-roles-en":337,"prev-cloud-computing-fundamentals-cloud-careers-and-certifications-working-in-the-cloud-cloud-job-roles-en":622},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},"Hands-On Practice with Free Tiers","What AWS, Azure, and Google Cloud actually give you for free, the difference between a time-limited trial credit and an Always Free service, and how to practice without risking a surprise bill.",19,"intermediate",[344,345,346,347],"Compare what AWS, Azure, and Google Cloud each offer for free hands-on practice","Distinguish a time-limited trial credit from an Always Free service tier","Set up a budget alert that warns you before a practice account gets billed","Identify a lab platform that runs in a sandboxed environment instead of your own billed account",{"id":349,"title":339,"body":350,"description":340,"difficulty":342,"estimatedMinutes":341,"extension":263,"infographics":559,"isFree":5,"learningObjectives":560,"meta":561,"navigation":9,"path":562,"quiz":563,"seo":619,"stem":620,"__hash__":621},"courses/courses/cloud-computing-fundamentals/en/domains/04-cloud-careers-and-certifications/01-working-in-the-cloud/02-hands-on-practice-with-free-tiers.md",{"type":20,"value":351,"toc":545},[352,356,359,363,366,369,373,376,380,383,387,449,453,456,460,463,466,470,473,476,480,483,487,490,494,540,542],[23,353,355],{"id":354},"what-actually-gets-built-with-a-free-account","What actually gets built with a free account",[28,357,358],{},"The previous lesson mapped the cloud job titles onto what each one does day to day. None of that shows up as proof on a resume by itself. An interviewer does not ask whether you read the IAM lesson; they ask whether you have actually created a scoped IAM role, launched an instance, or set up a storage bucket with the right access controls. That gap between reading and doing is exactly what a free cloud account closes, and every major provider gives you a real way to close it without spending money, as long as you know exactly what \"free\" means on each one.",[23,360,362],{"id":361},"aws-which-free-tier-you-get-depends-on-when-you-signed-up","AWS: which free tier you get depends on when you signed up",[28,364,365],{},"AWS changed its Free Tier structure on July 15, 2025, which matters because a lot of tutorials and blog posts online still describe the old version as if it is universal. An account created after that date gets a Free Plan: $100 in credit immediately, plus the chance to earn up to $100 more by completing certain activities, for a maximum of $200. That account closes automatically after 6 months, or the moment the credit runs out, whichever happens first.",[28,367,368],{},"An account created before July 15, 2025 keeps the legacy structure instead: 12 months of free usage on a defined list of services, with no credit balance to track. Regardless of which structure your account falls under, every AWS account, free or paid, also gets Always Free access to over 30 services within fixed monthly limits, for as long as the account exists. That third piece, Always Free, is the one part of the AWS offer that never expires on a clock.",[23,370,372],{"id":371},"azure-a-30-day-credit-plus-a-separate-always-free-list","Azure: a 30-day credit plus a separate always-free list",[28,374,375],{},"Microsoft's free account bundles 3 distinct things, and it helps to keep them separate in your head. First, a $200 credit usable for the first 30 days, covering anything you want to try, including services outside the free list. Second, a set of popular services that stay free for 12 months. Third, a permanent list of Always Free services with no expiration at all. You will not be charged anything unless you deliberately upgrade to pay-as-you-go pricing, and Microsoft limits this offer to 1 account per new customer.",[23,377,379],{"id":378},"google-cloud-a-90-day-trial-plus-its-own-always-free-tier","Google Cloud: a 90-day trial plus its own always-free tier",[28,381,382],{},"Google Cloud's structure looks similar in shape but different in the numbers: new, eligible customers get a $300 Free Trial credit, valid for 90 days, which requires a card on file but does not charge it during the trial. Separately, Google Cloud maintains its own Always Free tier, which keeps specific products working at no cost indefinitely, at specific limits: 1 e2-micro Compute Engine instance a month, 5 GB of Cloud Storage a month, 1 shared-core Cloud SQL instance with 10 GB of storage, and 1 TB of BigQuery query processing a month, among others.",[23,384,386],{"id":385},"comparing-the-3-programs-side-by-side","Comparing the 3 programs side by side",[59,388,389,405],{},[62,390,391],{},[65,392,393,396,399,402],{},[68,394,395],{},"Provider",[68,397,398],{},"Trial credit",[68,400,401],{},"Trial window",[68,403,404],{},"Always-free component",[78,406,407,421,435],{},[65,408,409,412,415,418],{},[83,410,411],{},"AWS (new accounts)",[83,413,414],{},"Up to $200",[83,416,417],{},"6 months, or until credit runs out",[83,419,420],{},"30+ services, perpetual monthly limits",[65,422,423,426,429,432],{},[83,424,425],{},"Microsoft Azure",[83,427,428],{},"$200",[83,430,431],{},"30 days",[83,433,434],{},"12-months list, plus a separate always-free list",[65,436,437,440,443,446],{},[83,438,439],{},"Google Cloud",[83,441,442],{},"$300",[83,444,445],{},"90 days",[83,447,448],{},"Always Free tier (for example, 1 e2-micro instance, 5 GB storage a month)",[23,450,452],{"id":451},"boundary-a-trial-credit-is-not-the-same-thing-as-an-always-free-service","Boundary: a trial credit is not the same thing as an Always Free service",[28,454,455],{},"It is easy to blur these 2 ideas together because both get marketed under the word \"free.\" A trial credit is a countdown: a fixed dollar amount, a fixed window of days, and it is gone once either runs out, credit spent or window closed, whichever comes first. An Always Free service has no countdown at all: it keeps working every month, indefinitely, as long as your usage stays under its cap and the account itself stays open. Confusing the 2 is exactly how learners get caught off guard: they assume the trial credit's generosity applies forever, when only the much narrower Always Free list actually does.",[23,457,459],{"id":458},"practicing-without-risking-your-own-account","Practicing without risking your own account",[28,461,462],{},"If you would rather not point a brand-new personal account at a real service at all while you are still learning, 2 platforms run the practice environment for you. AWS Skill Builder's Builder Labs give you over 200 guided, interactive exercises inside a sandboxed AWS Management Console, with step-by-step instructions and no risk of an unexpected fee, since the environment itself is temporary and separate from any personal account. Google Cloud Skills Boost (formerly known as Qwiklabs) works similarly: each lab spins up a live, real Google Cloud environment with its own temporary credentials for the duration of the lab, rather than a simulation.",[28,464,465],{},"Microsoft Learn used to offer an equivalent sandbox for Azure training modules, but its own FAQ now states plainly that sandboxes are no longer available: completing exercises requires your own Azure subscription, whether that is the free 30-day trial described above or a pay-as-you-go account. If you have seen an older guide describe a Microsoft Learn sandbox, that detail is out of date.",[23,467,469],{"id":468},"worked-example-putting-a-tripwire-on-a-free-tier-account","Worked example: putting a tripwire on a free-tier account",[28,471,472],{},"Say you sign up for the AWS Free Plan and want a safety net while you experiment. In the Billing and Cost Management console, you create a Budget, set it as a recurring monthly cost budget, and give it a deliberately small limit, say $2, far below anything you expect to spend but high enough to survive normal Always Free usage. You add alert thresholds, for example at 50%, 80%, and 100% of that $2 limit, and point the notifications at your own email address rather than SMS, since SMS delivery through Amazon SNS can carry its own small per-message cost.",[28,474,475],{},"One detail worth knowing before you rely on it: AWS needs about 5 weeks of usage history before it can generate a forecast-based alert, so a brand-new account should lean on actual-spend alerts at first, not forecasted ones, until enough billing data has accumulated.",[23,477,479],{"id":478},"misconception-free-tier-does-not-mean-the-whole-account-is-free","Misconception: \"free tier\" does not mean the whole account is free",[28,481,482],{},"It is tempting to read \"Free Tier\" and assume nothing on the account can ever cost money. It does not work that way on any of the 3 providers. Each Always Free allowance caps a specific service at a specific monthly volume, for example a single Compute Engine e2-micro instance. Launch a second instance beyond that cap, even by accident, and the extra usage bills at the normal pay-as-you-go rate, exactly like a paid account would. The free tier narrows what you owe; it does not remove the possibility of owing anything.",[23,484,486],{"id":485},"what-to-actually-build-with-your-free-time","What to actually build with your free time",[28,488,489],{},"A concrete first project beats aimless clicking. Using whichever provider's free account you set up, launch a single compute instance, attach a storage bucket to it, and, following the least-privilege habit from the identity and access management lesson earlier in this course, create a scoped IAM user or role for the project instead of using root or the account owner's own credentials for every action. That single project, small as it is, gives you a real answer the next time an interview question asks whether you have actually used the service, not just read about it.",[23,491,493],{"id":492},"exam-cues-free-tier-and-cost-tools-on-an-entry-level-cloud-exam","Exam cues: free tier and cost tools on an entry-level cloud exam",[59,495,496,506],{},[62,497,498],{},[65,499,500,503],{},[68,501,502],{},"The scenario says...",[68,504,505],{},"Points to",[78,507,508,516,524,532],{},[65,509,510,513],{},[83,511,512],{},"\"Limit spend while experimenting with a new account\"",[83,514,515],{},"AWS Budgets, or the equivalent cost-alert tool on another provider",[65,517,518,521],{},[83,519,520],{},"\"A one-time credit that expires after a fixed window\"",[83,522,523],{},"A Free Trial credit, not an Always Free service",[65,525,526,529],{},[83,527,528],{},"\"A perpetual monthly allowance, regardless of how long ago the account was created\"",[83,530,531],{},"An Always Free service",[65,533,534,537],{},[83,535,536],{},"\"Warn me by email before I hit a spending limit\"",[83,538,539],{},"A budget alert threshold",[23,541,243],{"id":242},[28,543,544],{},"You now know exactly what each major provider actually gives you for free, the difference between a countdown credit and a perpetual allowance, and how to put a small tripwire on an account before you start experimenting with it. That combination, real hands-on repetitions plus a resume line you can back up in an interview, is the other half of what the previous lesson's job roles are looking for. The next topic in this course turns to certifications: why they matter, how the foundational options compare, and which one to take first.",{"title":248,"searchDepth":249,"depth":249,"links":546},[547,548,549,550,551,552,553,554,555,556,557,558],{"id":354,"depth":252,"text":355},{"id":361,"depth":252,"text":362},{"id":371,"depth":252,"text":372},{"id":378,"depth":252,"text":379},{"id":385,"depth":252,"text":386},{"id":451,"depth":252,"text":452},{"id":458,"depth":252,"text":459},{"id":468,"depth":252,"text":469},{"id":478,"depth":252,"text":479},{"id":485,"depth":252,"text":486},{"id":492,"depth":252,"text":493},{"id":242,"depth":252,"text":243},[],[344,345,346,347],{},"/courses/cloud-computing-fundamentals/en/domains/04-cloud-careers-and-certifications/01-working-in-the-cloud/02-hands-on-practice-with-free-tiers",{"passingScore":282,"questions":564},[565,573,581,589,597,607,611],{"question":566,"type":286,"options":567,"correctAnswer":569,"explanation":572},"An AWS account created after July 15, 2025 signs up for the Free Tier. Which best describes what that account receives?",[568,569,570,571],"12 months of free usage on a fixed list of services, with no credit involved","A Free Plan offering up to $200 in credits ($100 at signup, up to $100 more through activities), lasting up to 6 months or until the credit runs out, whichever comes first","Unlimited free usage of every AWS service, indefinitely","A one-time $300 credit valid for 90 days, matching Google Cloud's trial","AWS changed its structure for new accounts created after July 15, 2025: a Free Plan with up to $200 in credits that closes after 6 months or when the credit runs out, whichever happens first. The old 12-months-free structure without any credit component still applies, but only to accounts opened before that date, which is exactly the kind of outdated assumption a lot of older tutorials still repeat.",{"question":574,"type":286,"options":575,"correctAnswer":579,"explanation":580},"Which distinguishes an Always Free service, like AWS's free-tier-eligible storage allowance, from a time-limited trial credit like Azure's signup credit?",[576,577,578,579],"Always Free services also disappear once any credit balance is exhausted","A time-limited credit renews automatically every month, while Always Free expires after a fixed window","There is no real distinction; both work identically across every provider","Always Free usage stays free indefinitely, up to a monthly cap, as long as the account exists, while a trial credit is a fixed dollar amount that expires after its time window closes","An Always Free service keeps working at no cost every month, forever, as long as you stay within its usage cap and keep the account open. A trial credit is the opposite shape: a fixed dollar amount that counts down as you spend it and disappears once its time window closes, regardless of how much you actually used.",{"question":582,"type":286,"options":583,"correctAnswer":584,"explanation":588},"A developer signs up for the Azure free account. Which combination of benefits does Microsoft's offer include?",[584,585,586,587],"A $200 credit usable for 30 days, plus a set of popular services free for 12 months, plus a separate list of services that are always free","A $300 credit usable for 90 days, with no separate always-free list","Free access to every Azure service for 12 months, with no credit component at all","A one-time $100 credit with no time limit","Azure's free account bundles 3 separate benefits: a $200 credit good for the first 30 days, a shorter list of popular services free for 12 months, and an always-free list with no expiration. Confusing this with Google Cloud's $300, 90-day structure is a common mix-up between the 2 providers' otherwise similar-sounding offers.",{"question":590,"type":286,"options":591,"correctAnswer":594,"explanation":596},"A team wants to test BigQuery and Compute Engine before committing any budget. Under Google Cloud's free program, what should they expect?",[592,593,594,595],"A $200 credit valid for 12 months","No trial credit at all, only the Always Free tier","A $300 Free Trial credit valid for 90 days, on top of a separate Always Free tier that includes products like a single e2-micro Compute Engine instance and 5 GB of Cloud Storage each month","A requirement to already be a paying customer before any free access is granted","Google Cloud gives new, eligible customers a $300 Free Trial credit good for 90 days, separate from its Always Free tier, which keeps working at no cost indefinitely for specific products at specific limits, such as 1 e2-micro instance or 5 GB of storage a month. Requiring a card during signup is a real eligibility detail, but it does not mean the account is already a paying one.",{"question":598,"type":317,"options":599,"correctAnswers":605,"explanation":606},"Select all true statements about protecting a free-tier account from a surprise bill.",[600,601,602,603,604],"Setting an AWS Budget with alert thresholds can notify you by email before you get an unpleasant surprise on a bill","Once free-tier usage limits are exceeded, AWS silently stops the service instead of billing you at standard rates","A budget alert can be set at a small monthly limit, like $2, purely as an early-warning tripwire while practicing","Joining an AWS Organization has no effect on a new account's Free Tier credit eligibility","Choosing email notifications over SMS for budget alerts avoids incurring small messaging charges",[600,602,604],"AWS Budgets genuinely can warn you by email before a small limit like $2 is exceeded, and email avoids the small per-message charges that SMS notifications can carry. Exceeding a free-tier limit does not silently stop the service, it bills the overage at the standard pay-as-you-go rate, and joining an AWS Organization or enabling Control Tower actually ends a new account's Free Tier credit eligibility rather than leaving it untouched.",{"question":608,"type":286,"options":609,"correctAnswer":305,"explanation":610},"Microsoft Learn currently offers free interactive sandbox subscriptions for every Azure training module, the same way it used to.",[304,305],"Microsoft's own Learn FAQ states plainly that sandboxes are no longer available, and that completing exercises now requires your own Azure subscription, such as the free 30-day trial or a pay-as-you-go account. This is exactly the kind of detail that goes stale in older blog posts and screenshots, so it is worth confirming against the current official FAQ rather than assuming it still works the old way.",{"question":612,"type":286,"options":613,"correctAnswer":615,"explanation":618},"A learner spins up an EC2 instance and an S3 bucket during a free-tier practice session and wants to follow the security practice from the earlier Identity and Access Management lesson. What should they do?",[614,615,616,617],"Use the account's root user credentials for every action, since it is only a practice account","Create an IAM user or role scoped to only the permissions the practice project needs, instead of using root credentials","Disable IAM entirely, to simplify the free-tier setup","Wait until the account has real production workloads before creating any IAM users","The least-privilege habit from the identity and access management lesson applies just as much to a free practice account as to a production one, since root credentials have unrestricted power over the entire account and a scoped IAM user or role limits the damage a mistake or a leaked credential can do. A practice account is exactly where this habit is cheapest to build, before the stakes of a production mistake are real.",{"title":339,"description":340},"courses/cloud-computing-fundamentals/en/domains/04-cloud-careers-and-certifications/01-working-in-the-cloud/02-hands-on-practice-with-free-tiers","OeWxZVdmVFvx_ewB3dTfnob1melNngrsBw4vm_JmTDI",{"locked":5,"reason":3,"meta":623,"item":631},{"title":624,"description":625,"isFree":5,"estimatedMinutes":341,"difficulty":342,"learningObjectives":626},"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.",[627,628,629,630],"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":632,"title":624,"body":633,"description":625,"difficulty":342,"estimatedMinutes":341,"extension":263,"infographics":833,"isFree":5,"learningObjectives":834,"meta":835,"navigation":9,"path":836,"quiz":837,"seo":888,"stem":889,"__hash__":890},"courses/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/04-monitoring-and-slas.md",{"type":20,"value":634,"toc":822},[635,639,642,646,649,652,656,659,675,678,681,685,688,734,737,741,744,747,751,754,758,761,765,817,819],[23,636,638],{"id":637},"every-pattern-in-this-topic-assumes-you-find-out","Every pattern in this topic assumes you find out",[28,640,641],{},"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,643,645],{"id":644},"monitoring-metrics-logs-and-alarms","Monitoring: metrics, logs, and alarms",[28,647,648],{},"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,650,651],{},"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,653,655],{"id":654},"sli-slo-sla-measuring-targeting-promising","SLI, SLO, SLA: measuring, targeting, promising",[28,657,658],{},"These 3 terms get used almost interchangeably in casual conversation, and the exam boundary between them is worth learning precisely.",[28,660,661,662,666,667,670,671,674],{},"A ",[663,664,665],"strong",{},"Service Level Indicator (SLI)"," is a quantitative measurement of how a service is actually performing, like the percentage of requests that succeed. A ",[663,668,669],{},"Service Level Objective (SLO)"," is the internal target a team sets for that SLI, like \"we aim for 99.95% successful requests.\" A ",[663,672,673],{},"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,676,677],{},"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,679,680],{},"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,682,684],{"id":683},"the-nines-what-an-uptime-percentage-costs-in-real-downtime","The nines: what an uptime percentage costs in real downtime",[28,686,687],{},"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,689,690,700],{},[62,691,692],{},[65,693,694,697],{},[68,695,696],{},"Uptime",[68,698,699],{},"Allowed downtime per year",[78,701,702,710,718,726],{},[65,703,704,707],{},[83,705,706],{},"99% (2 nines)",[83,708,709],{},"About 3.65 days",[65,711,712,715],{},[83,713,714],{},"99.9% (3 nines)",[83,716,717],{},"About 8.76 hours",[65,719,720,723],{},[83,721,722],{},"99.99% (4 nines)",[83,724,725],{},"About 52 minutes",[65,727,728,731],{},[83,729,730],{},"99.999% (5 nines)",[83,732,733],{},"About 5 minutes",[28,735,736],{},"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,738,740],{"id":739},"worked-example-reading-a-real-sla","Worked example: reading a real SLA",[28,742,743],{},"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,745,746],{},"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,748,750],{"id":749},"what-an-sla-promises-and-what-it-does-not","What an SLA promises, and what it does not",[28,752,753],{},"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,755,757],{"id":756},"boundary-chaining-services-makes-the-overall-number-worse-not-better","Boundary: chaining services makes the overall number worse, not better",[28,759,760],{},"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,762,764],{"id":763},"exam-cues-matching-a-scenario-to-the-right-term","Exam cues: matching a scenario to the right term",[59,766,767,775],{},[62,768,769],{},[65,770,771,773],{},[68,772,502],{},[68,774,505],{},[78,776,777,785,793,801,809],{},[65,778,779,782],{},[83,780,781],{},"\"Financially backed guarantee,\" \"service credit for downtime\"",[83,783,784],{},"SLA",[65,786,787,790],{},[83,788,789],{},"\"Internal target,\" \"error budget\"",[83,791,792],{},"SLO",[65,794,795,798],{},[83,796,797],{},"\"The actual measured percentage of successful requests\"",[83,799,800],{},"SLI",[65,802,803,806],{},[83,804,805],{},"\"How much downtime does X% allow\"",[83,807,808],{},"The nines table",[65,810,811,814],{},[83,812,813],{},"\"Multiple dependent services chained together\"",[83,815,816],{},"Composite availability, lower than any single component",[23,818,243],{"id":242},[28,820,821],{},"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":823},[824,825,826,827,828,829,830,831,832],{"id":637,"depth":252,"text":638},{"id":644,"depth":252,"text":645},{"id":654,"depth":252,"text":655},{"id":683,"depth":252,"text":684},{"id":739,"depth":252,"text":740},{"id":749,"depth":252,"text":750},{"id":756,"depth":252,"text":757},{"id":763,"depth":252,"text":764},{"id":242,"depth":252,"text":243},[],[627,628,629,630],{},"/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/04-monitoring-and-slas",{"passingScore":282,"questions":838},[839,847,855,859,867,876,880],{"question":840,"type":286,"options":841,"correctAnswer":843,"explanation":846},"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?",[842,843,844,845],"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":848,"type":286,"options":849,"correctAnswer":851,"explanation":854},"Which of the following correctly orders SLI, SLO, and SLA by what each one represents?",[850,851,852,853],"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":856,"type":286,"options":857,"correctAnswer":717,"explanation":858},"A service maintains 99.9% uptime over a year. Approximately how much downtime does that allow?",[733,725,717,709],"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":860,"type":286,"options":861,"correctAnswer":863,"explanation":866},"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?",[862,863,864,865],"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":868,"type":317,"options":869,"correctAnswers":874,"explanation":875},"Which of the following are true about what a cloud provider's SLA guarantees? (Select all that apply.)",[870,871,872,873],"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",[870,872,873],"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":877,"type":286,"options":878,"correctAnswer":305,"explanation":879},"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":881,"type":286,"options":882,"correctAnswer":884,"explanation":887},"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?",[883,884,885,886],"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":624,"description":625},"courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/02-reliability-and-operations/04-monitoring-and-slas","aZP7DSh_93EReBS9CJCCrTkPoqSFB0WHN46E-2emKn8"]