[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"prev-cloud-computing-fundamentals-security-and-reliability-cloud-security-shared-responsibility-model-en":4,"next-cloud-computing-fundamentals-security-and-reliability-cloud-security-shared-responsibility-model-en":436,"lesson-cloud-computing-fundamentals-security-and-reliability-cloud-security-shared-responsibility-model-en":656},null,{"locked":5,"reason":3,"meta":6,"item":17},false,{"title":7,"description":8,"isFree":5,"estimatedMinutes":9,"difficulty":10,"learningObjectives":11},"DevOps and Infrastructure as Code","How development and operations merged into one continuous practice, what each stage of a CI/CD pipeline catches, and how describing infrastructure as code, instead of clicking through a console, keeps environments consistent and reproducible.",19,"intermediate",[12,13,14,15,16],"Explain what DevOps changes about how development and operations teams work together","Describe the stages of a CI/CD pipeline and what each stage catches before a change reaches production","Explain how infrastructure as code replaces manual console changes with versioned, declarative configuration","Identify configuration drift and why it happens when infrastructure is changed outside its code definition","Compare a declarative infrastructure-as-code tool's plan-then-apply workflow to making the same change by hand",{"id":18,"title":7,"body":19,"description":8,"difficulty":10,"estimatedMinutes":9,"extension":357,"infographics":358,"isFree":5,"learningObjectives":370,"meta":371,"navigation":372,"path":373,"quiz":374,"seo":433,"stem":434,"__hash__":435},"courses/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/03-devops-and-infrastructure-as-code.md",{"type":20,"value":21,"toc":348},"minimark",[22,27,31,35,38,42,120,125,128,248,252,255,277,280,284,287,291,337,341,344],[23,24,26],"h2",{"id":25},"the-last-lesson-left-you-with-more-moving-pieces-than-one-deployment-can-handle","The last lesson left you with more moving pieces than one deployment can handle",[28,29,30],"p",{},"The last lesson left you with a team running a growing number of independently deployable services, each shipping on its own schedule. Shipping one application by hand, tested manually and copied onto a server by whoever was on duty, was already slow and error-prone. Shipping 10 services that way is not just slower, it stops being something a person can reliably do at all. DevOps, and the practices built around it, exist to answer exactly that problem.",[23,32,34],{"id":33},"what-devops-actually-changes","What DevOps actually changes",[28,36,37],{},"Before DevOps, development and operations were usually 2 separate teams: developers wrote code and handed it off, operations deployed and ran it, and each side blamed the other when a release broke something. DevOps, in AWS's own framing, is a combination of cultural philosophies, practices, and tools that increases an organization's ability to deliver applications and services at high velocity. In practice, that means the same team writes, tests, deploys, and operates its own services, which gives that team a direct incentive to make deployment itself fast and safe, instead of throwing a build over a wall and hoping.",[23,39,41],{"id":40},"continuous-integration-continuous-delivery-what-actually-happens-at-each-stage","Continuous integration, continuous delivery: what actually happens at each stage",[43,44,45,61],"table",{},[46,47,48],"thead",{},[49,50,51,55,58],"tr",{},[52,53,54],"th",{},"Stage",[52,56,57],{},"What happens",[52,59,60],{},"What it catches",[62,63,64,76,87,98,109],"tbody",{},[49,65,66,70,73],{},[67,68,69],"td",{},"Source",[67,71,72],{},"A developer commits code to a shared repository",[67,74,75],{},"Nothing yet, this just starts the pipeline",[49,77,78,81,84],{},[67,79,80],{},"Build",[67,82,83],{},"The code compiles and packages into a deployable artifact",[67,85,86],{},"Syntax errors, missing dependencies",[49,88,89,92,95],{},[67,90,91],{},"Test",[67,93,94],{},"An automated test suite runs against the build",[67,96,97],{},"Regressions in existing behavior",[49,99,100,103,106],{},[67,101,102],{},"Staging",[67,104,105],{},"The build deploys to a pre-production environment",[67,107,108],{},"Integration and configuration problems",[49,110,111,114,117],{},[67,112,113],{},"Production",[67,115,116],{},"The build deploys to live users",[67,118,119],{},"Nothing further, this is the release",[121,122],"infographic",{"alt":123,"slug":124},"A timeline of a CI/CD pipeline moving from source through build, test, staging, and production, looping back to source for the next commit.","devops-and-infrastructure-as-code-cicd-pipeline",[28,126,127],{},"Follow one commit through it. A developer pushes a fix to the checkout service from the last lesson. Continuous integration builds a new container image and runs the test suite against it; if a test fails, the pipeline stops right there, and the change never reaches staging, let alone production. If every test passes, continuous delivery takes over, deploying the same build to staging automatically, and, once checks there pass, promoting that exact build to production. No stage is skipped, and no human copies a file by hand.",[129,130,135],"pre",{"className":131,"code":132,"language":133,"meta":134,"style":134},"language-yaml shiki shiki-themes material-theme-lighter github-light github-dark","name: ci\non: [push]\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v4\n      - run: docker build -t checkout-service:${{ github.sha }} .\n      - run: docker run checkout-service:${{ github.sha }} npm test\n","yaml","",[136,137,138,155,173,182,190,201,209,223,236],"code",{"__ignoreMap":134},[139,140,143,147,151],"span",{"class":141,"line":142},"line",1,[139,144,146],{"class":145},"sQzsp","name",[139,148,150],{"class":149},"sP7_E",":",[139,152,154],{"class":153},"s_sjI"," ci\n",[139,156,158,162,164,167,170],{"class":141,"line":157},2,[139,159,161],{"class":160},"syTEX","on",[139,163,150],{"class":149},[139,165,166],{"class":149}," [",[139,168,169],{"class":153},"push",[139,171,172],{"class":149},"]\n",[139,174,176,179],{"class":141,"line":175},3,[139,177,178],{"class":145},"jobs",[139,180,181],{"class":149},":\n",[139,183,185,188],{"class":141,"line":184},4,[139,186,187],{"class":145},"  build-and-test",[139,189,181],{"class":149},[139,191,193,196,198],{"class":141,"line":192},5,[139,194,195],{"class":145},"    runs-on",[139,197,150],{"class":149},[139,199,200],{"class":153}," ubuntu-latest\n",[139,202,204,207],{"class":141,"line":203},6,[139,205,206],{"class":145},"    steps",[139,208,181],{"class":149},[139,210,212,215,218,220],{"class":141,"line":211},7,[139,213,214],{"class":149},"      -",[139,216,217],{"class":145}," uses",[139,219,150],{"class":149},[139,221,222],{"class":153}," actions/checkout@v4\n",[139,224,226,228,231,233],{"class":141,"line":225},8,[139,227,214],{"class":149},[139,229,230],{"class":145}," run",[139,232,150],{"class":149},[139,234,235],{"class":153}," docker build -t checkout-service:${{ github.sha }} .\n",[139,237,239,241,243,245],{"class":141,"line":238},9,[139,240,214],{"class":149},[139,242,230],{"class":145},[139,244,150],{"class":149},[139,246,247],{"class":153}," docker run checkout-service:${{ github.sha }} npm test\n",[23,249,251],{"id":250},"infrastructure-as-code-the-same-idea-aimed-at-infrastructure","Infrastructure as code: the same idea, aimed at infrastructure",[28,253,254],{},"CI/CD automates shipping application code. Infrastructure as code applies the same discipline to the servers, networks, and services that code runs on: provisioning and managing infrastructure using code instead of manual processes and console clicks. A storage bucket created by clicking through a console leaves no record of who created it, why, or how to recreate it. The same bucket declared in a file does.",[129,256,260],{"className":257,"code":258,"language":259,"meta":134,"style":134},"language-hcl shiki shiki-themes material-theme-lighter github-light github-dark","resource \"aws_s3_bucket\" \"uploads\" {\n  bucket = \"my-app-uploads\"\n}\n","hcl",[136,261,262,267,272],{"__ignoreMap":134},[139,263,264],{"class":141,"line":142},[139,265,266],{},"resource \"aws_s3_bucket\" \"uploads\" {\n",[139,268,269],{"class":141,"line":157},[139,270,271],{},"  bucket = \"my-app-uploads\"\n",[139,273,274],{"class":141,"line":175},[139,275,276],{},"}\n",[28,278,279],{},"Tools like Terraform work in 3 steps: write the configuration, plan (preview exactly what will be created, changed, or destroyed to match it), and apply (execute those changes in the right dependency order). That configuration is declarative: it describes the end state you want, not the individual commands to get there, and the tool works out the rest.",[23,281,283],{"id":282},"the-misconception-a-quick-manual-fix-in-the-console-is-fine","The misconception: \"a quick manual fix in the console is fine\"",[28,285,286],{},"It is tempting to think a fast fix in the console, bumping an overloaded instance's memory at 2 a.m. during an incident, is harmless as long as it solves the immediate problem. It is not: the infrastructure-as-code file still describes the old, smaller instance, so the code and the real infrastructure have quietly drifted apart. The next time someone applies that code, it can revert the emergency fix without anyone intending it to, or the team simply stops trusting the code to reflect what is actually running. Configuration drift is the name for that gap, and the fix is discipline, not cleverness: update the code to match the emergency change immediately, or revert the manual change and make the same fix through the code instead.",[23,288,290],{"id":289},"exam-cues-spotting-the-fit-in-a-scenario","Exam cues: spotting the fit in a scenario",[43,292,293,303],{},[46,294,295],{},[49,296,297,300],{},[52,298,299],{},"The scenario says...",[52,301,302],{},"Points to",[62,304,305,313,321,329],{},[49,306,307,310],{},[67,308,309],{},"\"Automated build, test, and deploy on every commit\"",[67,311,312],{},"CI/CD pipeline",[49,314,315,318],{},[67,316,317],{},"\"Infrastructure defined in version-controlled files\"",[67,319,320],{},"Infrastructure as code",[49,322,323,326],{},[67,324,325],{},"\"A manual change made outside the deployment pipeline\"",[67,327,328],{},"Configuration drift risk",[49,330,331,334],{},[67,332,333],{},"\"Preview changes before they are applied\"",[67,335,336],{},"Declarative infrastructure-as-code plan step",[23,338,340],{"id":339},"where-this-leaves-you","Where this leaves you",[28,342,343],{},"DevOps, CI/CD, and infrastructure as code are what make everything the last 2 lessons covered sustainable at real scale: a serverless function or a container image is only as reliable as the pipeline that builds, tests, and ships it, and the infrastructure it runs on is only as consistent as the code that describes it. The next domain in this course turns to what keeps systems secure and available once they are running, the shared responsibility model, identity, encryption, and disaster recovery, practices that infrastructure as code makes far easier to enforce the same way across every environment a team has.",[345,346,347],"style",{},"html pre.shiki code .sQzsp, html code.shiki .sQzsp{--shiki-light:#E53935;--shiki-default:#22863A;--shiki-dark:#85E89D}html pre.shiki code .sP7_E, html code.shiki .sP7_E{--shiki-light:#39ADB5;--shiki-default:#24292E;--shiki-dark:#E1E4E8}html pre.shiki code .s_sjI, html code.shiki .s_sjI{--shiki-light:#91B859;--shiki-default:#032F62;--shiki-dark:#9ECBFF}html pre.shiki code .syTEX, html code.shiki .syTEX{--shiki-light:#FF5370;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":134,"searchDepth":175,"depth":175,"links":349},[350,351,352,353,354,355,356],{"id":25,"depth":157,"text":26},{"id":33,"depth":157,"text":34},{"id":40,"depth":157,"text":41},{"id":250,"depth":157,"text":251},{"id":282,"depth":157,"text":283},{"id":289,"depth":157,"text":290},{"id":339,"depth":157,"text":340},"md",[359],{"slug":124,"concept":360,"style":361,"aspectRatio":362,"labels":363},"A left-to-right timeline of a CI/CD pipeline with 5 stages: Source, Build, Test, Staging, Production. An arrow loops from Production back to Source, labeled 'next commit', to show the pipeline repeats continuously. A footer strip carries the takeaway that each stage automatically gates the next, so a failure at any stage stops the pipeline before it reaches production.","timeline","16:9",[364,365,366,367,368,369],"Source: a developer commits code to a shared repository.","Build: the code compiles and packages into a deployable artifact.","Test: automated tests run against the build.","Staging: the build deploys to a pre-production environment.","Production: the build deploys to live users.","A failure at any stage stops the pipeline before it reaches production.",[12,13,14,15,16],{},true,"/courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/03-devops-and-infrastructure-as-code",{"passingScore":375,"questions":376},70,[377,386,393,399,407,417,425],{"question":378,"type":379,"options":380,"correctAnswer":381,"explanation":385},"According to AWS's definition, DevOps is best described as...","single",[381,382,383,384],"A combination of cultural philosophies, practices, and tools that helps deliver applications faster and more reliably","A single tool that automates deployments","A job title for someone who only writes deployment scripts","A cloud service that replaces the need for a development team","DevOps is not one tool or one job title, it is development and operations teams sharing responsibility for the entire application lifecycle, supported by the practices and tools that make frequent, reliable releases possible.",{"question":387,"type":379,"options":388,"correctAnswer":390,"explanation":392},"A commit triggers an automated process that compiles the code and runs the test suite, stopping immediately if anything fails. What part of the pipeline is this?",[389,390,320,391],"Configuration drift","Continuous integration","Continuous delivery","Continuous integration is the practice of merging code changes frequently and running automated builds and tests against them, catching bugs at the build and test stages before the change goes anywhere near production. Continuous delivery picks up from there, automating the path to staging and production.",{"question":394,"type":379,"options":395,"correctAnswer":397,"explanation":398},"As long as an emergency fix made directly in the cloud console solves the immediate problem, it is fine to leave the infrastructure-as-code files unchanged.",[396,397],"True","False","A console change that never makes it into the code creates configuration drift: the code no longer describes reality. The next time someone applies that code, it can silently revert the emergency fix, or leave the team unable to trust the code as an accurate source of truth at all. The fix needs to be reflected in the code, or reverted and reapplied through it.",{"question":400,"type":379,"options":401,"correctAnswer":404,"explanation":406},"A team edits a Terraform configuration file to add a new storage bucket, then runs the tool's preview step before making any change to the real infrastructure. What does this step show them?",[402,403,404,405],"A log of who has previously modified the infrastructure","The exact monthly bill for the new resource","An execution plan describing exactly what will be created, changed, or destroyed to match the new configuration","A list of security vulnerabilities in the code","Terraform's plan step compares the configuration file to the current state of the infrastructure and shows exactly what it will add, change, or destroy before anything actually happens. That preview is what lets a team catch an unintended change before it reaches real infrastructure, not after.",{"question":408,"type":409,"options":410,"correctAnswers":415,"explanation":416},"Which of the following are things a CI/CD pipeline stage can catch before a change reaches production? (Select all that apply.)","multiple",[411,412,413,414],"A syntax error that fails the build stage","A regression caught by the automated test stage","A configuration problem only visible once the change deploys to staging","A team's decision about which cloud region to launch in",[411,412,413],"Each pipeline stage exists to catch a different class of problem: the build stage catches code that will not even compile or package, the test stage catches regressions in behavior, and staging catches problems that only appear once the change runs in a production-like environment. Choosing a region is a design decision made before any of this, not something a pipeline stage detects.",{"question":418,"type":379,"options":419,"correctAnswer":423,"explanation":424},"Why is a Terraform configuration file described as declarative rather than imperative?",[420,421,422,423],"It lists step-by-step commands to run in order","It cannot be stored in version control","It only works with a single cloud provider","It describes the desired end state of the infrastructure, and the tool works out the steps needed to reach it","A declarative file says what the infrastructure should look like, one storage bucket with this name, for example, and leaves the how to the tool, which figures out the order of operations and the dependency graph. An imperative script would instead spell out each command to run, in order, to get there.",{"question":426,"type":379,"options":427,"correctAnswer":428,"explanation":432},"Infrastructure as code makes it easier to apply which practice consistently across every environment a team runs, a topic the next domain in this course covers in full?",[428,429,430,431],"Security controls such as identity and encryption settings","Choosing a service model","Writing a Dockerfile","Naming lesson slugs","Because infrastructure as code describes every environment in version-controlled files, the same security settings, identity policies, encryption, network rules, apply the same way everywhere instead of depending on someone remembering to click the same options by hand each time. The next domain covers exactly these controls in depth.",{"title":7,"description":8},"courses/cloud-computing-fundamentals/en/domains/02-cloud-services-and-architecture/03-modern-cloud-architectures/03-devops-and-infrastructure-as-code","aAbphIY88s1lTvgS-_RltVaOn18fgQF0ZePwZRhHr1Y",{"locked":5,"reason":3,"meta":437,"item":447},{"title":438,"description":439,"isFree":5,"estimatedMinutes":440,"difficulty":10,"learningObjectives":441},"Identity and Access Management","How the cloud confirms who you are, decides what you're allowed to do, and the practices, roles, least privilege, and MFA, that keep a single stolen credential from becoming a full account breach.",20,[442,443,444,445,446],"Distinguish authentication from authorization and explain why a cloud platform checks both on every request","Compare IAM users, groups, and roles, and identify when each is the right tool","Apply the principle of least privilege to a policy scenario","Explain why temporary credentials from a role are preferred over long-term access keys","Identify multi-factor authentication as a defense against credential theft, not password strength",{"id":448,"title":438,"body":449,"description":439,"difficulty":10,"estimatedMinutes":440,"extension":357,"infographics":584,"isFree":5,"learningObjectives":597,"meta":598,"navigation":372,"path":599,"quiz":600,"seo":653,"stem":654,"__hash__":655},"courses/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/01-cloud-security/02-identity-and-access-management.md",{"type":20,"value":450,"toc":574},[451,455,458,461,465,468,471,475,478,481,485,489,496,499,503,506,510,513,517,569,571],[23,452,454],{"id":453},"one-password-the-whole-account","One password, the whole account",[28,456,457],{},"Say a company gives every new developer the AWS account's root user password so nobody has to wait on IT to grant access. It is fast, and for months nothing goes wrong. Then a laptop with that password saved in a browser is stolen from a coffee shop. Whoever has it can now launch instances, read every stored file, delete every backup, and change billing details, because the root user has no limits at all.",[28,459,460],{},"Identity and access management exists to make that scenario much smaller. Instead of one shared, all-powerful credential, IAM lets a team hand each person and each application its own identity, scoped to exactly what that identity needs to do. A stolen laptop then exposes one narrow slice of the account, not the whole thing.",[23,462,464],{"id":463},"root-user-iam-users-and-roles","Root user, IAM users, and roles",[28,466,467],{},"Every AWS account starts with a single root user, created automatically, with unrestricted access to everything. AWS's own guidance is blunt about it: don't use the root user for everyday tasks, lock its credentials away, and set up other identities for actual work.",[28,469,470],{},"Two of those other identities matter most. An IAM user is a persistent identity, typically for a specific person or an application that needs standing access, with credentials that last until someone rotates or revokes them. A role is different: it's an identity with no credentials of its own, assumed temporarily by a user, an application, or an AWS service, which receives short-lived, auto-expiring credentials for the duration of that session. Modern practice leans hard toward roles precisely because there is nothing long-lived to leak.",[23,472,474],{"id":473},"two-separate-checks-authentication-then-authorization","Two separate checks: authentication, then authorization",[28,476,477],{},"Picture a developer signing in with a password and an MFA code, then requesting to launch a new virtual machine. AWS runs two distinct checks, in order, not one combined check.",[28,479,480],{},"First, authentication: does this password and MFA code match a real identity trusted by this account? If yes, the identity is confirmed. Second, and separately, authorization: does the confirmed identity's attached policy actually permit launching an instance? A user can pass authentication perfectly, with a correct password and a valid MFA code, and still be denied at authorization if their policy doesn't grant that action. The two checks protect against different failures: a stolen password defeats authentication, while a policy that grants too much defeats authorization even when authentication is working exactly as intended.",[121,482],{"alt":483,"slug":484},"A two-panel flow diagram showing a request passing through authentication, confirming identity, then authorization, checking policy and branching into an allow or deny outcome.","identity-and-access-management-authn-vs-authz-flow",[23,486,488],{"id":487},"least-privilege-start-narrow-not-broad","Least privilege: start narrow, not broad",[28,490,491,492,495],{},"Say a developer's role needs to read files from one reporting bucket and nothing else. A least-privilege policy grants exactly that: the ",[136,493,494],{},"s3:GetObject"," action, scoped to that one bucket, no more. Compare that to a broad policy granting full S3 access \"to be safe\": if that role's credentials are ever misused, the narrow policy limits the damage to one bucket's read access, while the broad one hands over every bucket in the account.",[28,497,498],{},"Least privilege is a direction to move in, not a one-time setting. AWS's own guidance recommends starting with a broader managed policy while a team explores what a new workload actually needs, then narrowing it down as usage patterns become clear, using tools that analyze real access activity to generate a tighter policy automatically. Teams that never revisit that first broad policy are the ones an audit flags.",[23,500,502],{"id":501},"the-boundary-groups-versus-roles","The boundary: groups versus roles",[28,504,505],{},"These two get confused because both let more than one entity share a set of permissions, but they solve different problems. A group is a collection of IAM users, useful for granting the same policies to, say, everyone on a data team, without attaching that policy to each user individually. A role is not a collection of anything; it's a single identity that different principals can temporarily assume, one at a time, receiving credentials that expire. Ask which question the scenario poses: \"grant the same standing permissions to several people\" points to a group; \"let this application or this person temporarily act as a specific identity\" points to a role.",[23,507,509],{"id":508},"misconception-a-strong-password-is-enough","Misconception: a strong password is enough",[28,511,512],{},"It's tempting to think a long, unique password is sufficient protection for an account. It is not: passwords get phished, reused across breached sites, or captured by malware regardless of how strong they are. MFA closes that gap by requiring a second factor, something the account holder has or generates, that a stolen password alone cannot satisfy. AWS specifically recommends phishing-resistant MFA, like security keys or passkeys, over one-time codes sent by text, since even the code itself can sometimes be intercepted or the workflow tricked.",[23,514,516],{"id":515},"exam-cues-matching-the-scenario-to-the-tool","Exam cues: matching the scenario to the tool",[43,518,519,527],{},[46,520,521],{},[49,522,523,525],{},[52,524,299],{},[52,526,302],{},[62,528,529,537,545,553,561],{},[49,530,531,534],{},[67,532,533],{},"\"Assumed temporarily,\" \"no long-lived credentials,\" \"used by an application or service\"",[67,535,536],{},"IAM role",[49,538,539,542],{},[67,540,541],{},"\"Grant the same permissions to a whole team of people\"",[67,543,544],{},"IAM group",[49,546,547,550],{},[67,548,549],{},"\"Minimum permissions needed for a task\"",[67,551,552],{},"Least privilege",[49,554,555,558],{},[67,556,557],{},"\"Second factor,\" \"even if the password is compromised\"",[67,559,560],{},"Multi-factor authentication",[49,562,563,566],{},[67,564,565],{},"\"Vendor tool can't assume a role,\" \"legacy system,\" \"programmatic access from outside AWS\"",[67,567,568],{},"Long-term access key, as the fallback case",[23,570,340],{"id":339},[28,572,573],{},"Identity is the row on the shared-responsibility table that never moves to the provider, and IAM is the toolset that lets you actually own it: confirm who's asking with authentication, decide what they can do with authorization, and keep both narrow with least privilege and roles instead of standing, all-powerful credentials. Knowing who's allowed to touch your data solves half the problem. The next lesson covers what protects that data even if someone gets past every one of these checks: encryption.",{"title":134,"searchDepth":175,"depth":175,"links":575},[576,577,578,579,580,581,582,583],{"id":453,"depth":157,"text":454},{"id":463,"depth":157,"text":464},{"id":473,"depth":157,"text":474},{"id":487,"depth":157,"text":488},{"id":501,"depth":157,"text":502},{"id":508,"depth":157,"text":509},{"id":515,"depth":157,"text":516},{"id":339,"depth":157,"text":340},[585],{"slug":484,"concept":586,"style":587,"aspectRatio":362,"labels":588},"A left-to-right, two-panel flow diagram showing one access request passing through two distinct checks. Panel 1, labeled Authentication, shows a user icon submitting credentials plus an MFA code, arrowing to a checkmark labeled 'Identity confirmed.' Panel 2, labeled Authorization, shows that confirmed identity being checked against an attached policy, then branching into two outcomes: an Allow arrow reaching a resource icon, and a Deny arrow reaching a blocked icon. A footer strip carries the takeaway that authorization is re-checked on every single request, not only at sign-in.","diagram",[589,590,591,592,593,594,595,596],"Step 1: Authentication, proving who you are","Credentials plus MFA code submitted","Identity confirmed","Step 2: Authorization, checking what you can do","Policy evaluated against the requested action","Allow: request reaches the resource","Deny: request is blocked","Authorization is checked on every request, not just at sign-in.",[442,443,444,445,446],{},"/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/01-cloud-security/02-identity-and-access-management",{"passingScore":375,"questions":601},[602,610,618,624,628,636,645],{"question":603,"type":379,"options":604,"correctAnswer":606,"explanation":609},"A company gives every new developer the AWS account's root user password so nobody waits on IT for access. A laptop with that password saved in a browser is later stolen. What does IAM exist to prevent in a situation like this?",[605,606,607,608],"It prevents laptops from being stolen","It lets the company create separate, limited identities instead of sharing one all-powerful credential","It automatically encrypts every file on a stolen laptop","It replaces the need for passwords entirely","The root user has unrestricted access to the entire account, which is exactly why it should never be used for everyday work. IAM lets a team hand each person or workload only the access it actually needs, so a single stolen credential exposes one narrow slice of the account instead of all of it.",{"question":611,"type":379,"options":612,"correctAnswer":615,"explanation":617},"A user signs in with a password and an MFA code, then requests to launch a virtual machine. AWS checks the submitted credentials first, then separately checks whether the user's attached policy allows launching instances. What are these two checks called, in order?",[613,614,615,616],"Authorization, then authentication","Encryption, then authentication","Authentication, then authorization","Validation, then encryption","Authentication answers \"who are you,\" confirmed once credentials and MFA check out. Authorization answers \"what are you allowed to do,\" checked separately against policy for every action requested. Confusing the two is common because both happen in quick succession, but they protect against different problems: a stolen password defeats authentication, an overly broad policy defeats authorization.",{"question":619,"type":379,"options":620,"correctAnswer":552,"explanation":623},"A policy grants a developer's role permission to run s3:GetObject on a single reporting bucket, and nothing else. This is an example of which principle?",[621,560,552,622],"Federated identity","Root user protection","Least privilege means granting only the specific actions on the specific resources a task genuinely requires, rather than starting broad and hoping nothing goes wrong. A policy scoped to one action on one bucket limits the damage if that role's credentials are ever misused, since there is nothing else for them to touch.",{"question":625,"type":379,"options":626,"correctAnswer":397,"explanation":627},"IAM groups and IAM roles are the same thing: both let you attach policies to more than one identity at once.",[396,397],"A group is a collection of IAM users that share attached policies, useful for managing permissions for a team of people. A role is an identity of its own, assumed temporarily by a user, application, or AWS service, and it issues short-lived credentials rather than adding permissions to an existing user.",{"question":629,"type":379,"options":630,"correctAnswer":633,"explanation":635},"A workload running on an EC2 instance needs to read from an S3 bucket. Which approach matches current best practice?",[631,632,633,634],"Create a long-term IAM user access key and hardcode it into the application","Share the account root user's credentials with the application","Attach an IAM role to the EC2 instance so it receives temporary credentials automatically","Disable authentication for that specific S3 bucket to simplify access","AWS delivers a role's temporary credentials directly to compute resources like EC2 and Lambda, so there is no long-lived secret to leak, rotate, or accidentally commit to a code repository. Long-term access keys still exist for specific cases, like third-party tools that can't assume a role, but they are the fallback, not the default.",{"question":637,"type":409,"options":638,"correctAnswers":643,"explanation":644},"Which of the following are genuine benefits of requiring multi-factor authentication? (Select all that apply.)",[639,640,641,642],"A stolen or phished password alone is no longer enough to sign in","It removes the need to ever rotate credentials","It adds a second factor the attacker would also need to possess or generate","It guarantees a policy is scoped to least privilege",[639,641],"MFA defends specifically against credential theft: even a correct password fails to sign in without the second factor. It says nothing about how broad that account's permissions are once signed in, which is what least privilege addresses separately, and it does not remove the need for credential rotation on any long-term keys still in use.",{"question":646,"type":379,"options":647,"correctAnswer":650,"explanation":652},"A scenario describes an application that needs programmatic AWS access but cannot assume an IAM role because it runs entirely outside AWS on a vendor's legacy platform with no role-assumption support. What does this scenario point toward?",[648,649,650,651],"Using the account root user for the application","Disabling authorization checks for that application","A long-term IAM user access key, used because temporary role credentials aren't an option here","Removing MFA so the application can sign in automatically","Temporary role credentials are the default recommendation precisely because they expire and never need manual rotation, but some legacy or third-party tools genuinely cannot assume a role. AWS's own guidance treats a long-term access key as the accepted fallback for exactly that case, not as a shortcut to avoid setting up roles properly.",{"title":438,"description":439},"courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/01-cloud-security/02-identity-and-access-management","jzKkq16Gwn2qwGSnTb64TR_V4_daoSBX6p8uOv8uEn8",{"locked":5,"reason":3,"meta":657,"item":667},{"title":658,"description":659,"isFree":372,"estimatedMinutes":660,"difficulty":661,"learningObjectives":662},"The Shared Responsibility Model","Where your cloud provider's security duties end and yours begin, and why that boundary moves depending on whether you're using IaaS, PaaS, or SaaS.",16,"beginner",[663,664,665,666],"Explain the shared responsibility model and state which security tasks the provider always owns versus which the customer always owns","Identify how the responsibility split shifts across IaaS, PaaS, and SaaS for a given resource","Apply the model to a worked example comparing an EC2-based application to a serverless one","Correct the misconception that a provider's compliance certification covers a customer's own application",{"id":668,"title":658,"body":669,"description":659,"difficulty":661,"estimatedMinutes":660,"extension":357,"infographics":887,"isFree":372,"learningObjectives":888,"meta":889,"navigation":372,"path":890,"quiz":891,"seo":946,"stem":947,"__hash__":948},"courses/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/01-cloud-security/01-shared-responsibility-model.md",{"type":20,"value":670,"toc":877},[671,675,678,681,685,688,691,695,698,787,790,794,797,800,804,807,811,814,818,869,872,874],[23,672,674],{"id":673},"whose-failure-is-the-empty-bucket","Whose failure is the empty bucket",[28,676,677],{},"A team spins up a storage bucket to hold files their app's users upload. To move fast during testing, they turn on public access, meaning to lock it back down before launch. They forget. Six months later, a security researcher finds the entire bucket sitting one search away, every uploaded file readable by anyone with the link. Who failed: the cloud provider, or the team?",[28,679,680],{},"The team did. Not because they mistyped a command, but because they treated a decision that was always theirs to make as if the provider had made it for them. That gap between what a provider secures and what a customer configures is exactly what the shared responsibility model exists to close.",[23,682,684],{"id":683},"security-of-the-cloud-security-in-the-cloud","Security of the cloud, security in the cloud",[28,686,687],{},"AWS names its half of the split \"security of the cloud\": the physical data centers, the racks inside them, the hypervisor that carves one physical server into many virtual machines, and the global network connecting AWS regions. You never see any of it, and you never patch any of it. Azure and Google Cloud describe the same division for their own platforms, in different words but the same shape.",[28,689,690],{},"Your half is \"security in the cloud\": everything you build, configure, and store using the services the provider hands you. That always includes your data and your access policies. Depending on which service you picked, it can also include your guest operating system and your application code.",[23,692,694],{"id":693},"the-boundary-moves-with-the-service-model","The boundary moves with the service model",[28,696,697],{},"That split is not fixed in one place. It slides along the stack depending on how much of the stack you asked the provider to manage.",[43,699,700,716],{},[46,701,702],{},[49,703,704,707,710,713],{},[52,705,706],{},"Responsibility",[52,708,709],{},"IaaS (a virtual machine)",[52,711,712],{},"PaaS (a managed database or app platform)",[52,714,715],{},"SaaS (a ready-made application)",[62,717,718,730,742,753,765,776],{},[49,719,720,723,726,728],{},[67,721,722],{},"Data and access configuration",[67,724,725],{},"Customer",[67,727,725],{},[67,729,725],{},[49,731,732,735,737,739],{},[67,733,734],{},"Application code and settings",[67,736,725],{},[67,738,725],{},[67,740,741],{},"Provider",[49,743,744,747,749,751],{},[67,745,746],{},"Guest operating system",[67,748,725],{},[67,750,741],{},[67,752,741],{},[49,754,755,758,760,763],{},[67,756,757],{},"Network controls (firewalls, routing)",[67,759,725],{},[67,761,762],{},"Shared",[67,764,741],{},[49,766,767,770,772,774],{},[67,768,769],{},"Hypervisor and physical host",[67,771,741],{},[67,773,741],{},[67,775,741],{},[49,777,778,781,783,785],{},[67,779,780],{},"Physical network and data center",[67,782,741],{},[67,784,741],{},[67,786,741],{},[28,788,789],{},"Read the table top to bottom rather than column by column: the top two rows almost never move to the provider, and the bottom two rows almost never move to the customer. The middle rows are where the interesting decisions live, and where most exam questions and most real misconfigurations happen.",[23,791,793],{"id":792},"worked-example-the-same-feature-two-service-models","Worked example: the same feature, two service models",[28,795,796],{},"Say a team runs a Node.js API on an Ubuntu virtual machine. AWS handles the physical server, the hypervisor, and the network between availability zones. The team handles patching Ubuntu when a kernel vulnerability ships, configuring the security group so only port 443 is reachable, and rotating the SSH key used to log in. That is IaaS: heavy on the customer's side of the table.",[28,798,799],{},"Now the same team rebuilds the upload feature as an S3 bucket plus a Lambda function that resizes images on arrival. AWS now manages the operating system and runtime patching for Lambda's execution environment entirely; there is no server for the team to patch at all. What is still theirs: the S3 bucket's access policy, the IAM role the function assumes and what that role is allowed to touch, and whether the stored files are encrypted. Moving from IaaS to a serverless PaaS-style service removed an entire row from the customer's side of the table. It did not remove the top row.",[23,801,803],{"id":802},"what-never-crosses-the-line","What never crosses the line",[28,805,806],{},"Regardless of IaaS, PaaS, or SaaS, two things stay the customer's job in every case: the data itself, including its classification and encryption choices, and identity and access management, meaning who can sign in and what they can do once they're in. A provider can encrypt a disk by default, but only the customer decides which files are sensitive enough to restrict further, and only the customer decides who on the team gets access to them. The next two lessons in this topic cover exactly those two rows in depth: identity first, then encryption.",[23,808,810],{"id":809},"misconception-a-certificate-you-didnt-earn","Misconception: a certificate you didn't earn",[28,812,813],{},"It's tempting to assume that because your cloud provider is SOC 2 or ISO 27001 certified, your own application inherits that certification. It does not. The provider's certificate covers the infrastructure it operates: the data centers, the hypervisor, the internals of its managed services. Whether your application's access controls, encryption settings, and data-handling practices meet a given framework is a separate audit, and only you can produce evidence for it. The last lesson in this topic returns to this exact gap and walks through how teams close it.",[23,815,817],{"id":816},"exam-cues-reading-a-shared-responsibility-question","Exam cues: reading a shared-responsibility question",[43,819,820,828],{},[46,821,822],{},[49,823,824,826],{},[52,825,299],{},[52,827,302],{},[62,829,830,838,846,854,862],{},[49,831,832,835],{},[67,833,834],{},"\"Physical security of the data center,\" \"the hypervisor\"",[67,836,837],{},"Always the provider",[49,839,840,843],{},[67,841,842],{},"\"Patching the guest operating system\" on a virtual machine",[67,844,845],{},"Customer (IaaS)",[49,847,848,851],{},[67,849,850],{},"\"Patching the operating system\" a managed database runs on",[67,852,853],{},"Provider (PaaS)",[49,855,856,859],{},[67,857,858],{},"\"Configuring a bucket policy,\" \"IAM permissions,\" \"encryption settings\"",[67,860,861],{},"Customer, in every service model",[49,863,864,867],{},[67,865,866],{},"\"Physical network between data centers\"",[67,868,837],{},[28,870,871],{},"The trap to watch for: a question that mentions a managed or serverless service and expects you to assume the provider now owns everything. It owns more than it did under IaaS, but data and identity never move.",[23,873,340],{"id":339},[28,875,876],{},"As you move from IaaS toward SaaS, the provider's slice of the table grows and the customer's shrinks, but the top two rows, data and identity, never cross that line in either direction. Learning to read a scenario and place it correctly on this table is the single most tested skill in cloud security fundamentals. The next lesson opens the identity half of that job in full: how the cloud actually verifies who you are and decides what you're allowed to do once it knows.",{"title":134,"searchDepth":175,"depth":175,"links":878},[879,880,881,882,883,884,885,886],{"id":673,"depth":157,"text":674},{"id":683,"depth":157,"text":684},{"id":693,"depth":157,"text":694},{"id":792,"depth":157,"text":793},{"id":802,"depth":157,"text":803},{"id":809,"depth":157,"text":810},{"id":816,"depth":157,"text":817},{"id":339,"depth":157,"text":340},[],[663,664,665,666],{},"/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/01-cloud-security/01-shared-responsibility-model",{"passingScore":375,"questions":892},[893,901,909,913,921,930,938],{"question":894,"type":379,"options":895,"correctAnswer":897,"explanation":900},"A team spins up a storage bucket for user uploads, turns on public access to test it quickly, and forgets to turn it back off. Six months later, a researcher finds the whole bucket exposed in a search engine. Whose failure is this?",[896,897,898,899],"The cloud provider's, since it hosts the data","The team's, since bucket access configuration is the customer's job under every service model","Nobody's, exposures like this cannot be prevented","The cloud provider's, since bucket defaults are its decision to make","Storage services default to private access precisely so a team has to make a deliberate choice to expose data. The provider secures the hardware and the service itself, but who can read a bucket's contents is a configuration decision that always belongs to the customer.",{"question":902,"type":379,"options":903,"correctAnswer":906,"explanation":908},"AWS, Azure, and Google Cloud each use a two-part phrase to describe their own half of the shared responsibility model. What is AWS's phrase for it?",[904,905,906,907],"Total cloud security","Infrastructure ownership","Security of the cloud","Provider-managed compliance","AWS calls its half \"security of the cloud\": the physical data centers, the hypervisor, and the global network. The customer's half is \"security in the cloud\": everything built on top of that infrastructure, including data, access policies, and, depending on the service, the guest operating system.",{"question":910,"type":379,"options":911,"correctAnswer":397,"explanation":912},"Under an IaaS service like a virtual machine, the provider patches the guest operating system for you.",[396,397],"IaaS hands you the heaviest slice of the responsibility split. The provider patches the hypervisor and physical host, but the guest operating system, including its security patches, is the customer's job. That job moves to the provider only once you move up to a managed PaaS service.",{"question":914,"type":379,"options":915,"correctAnswer":918,"explanation":920},"A team migrates an image-upload feature from a Node.js server running on an EC2 instance to an S3 bucket plus a Lambda function. Which responsibility does this move from the team to AWS?",[916,917,918,919],"Encrypting the uploaded files","Setting the S3 bucket's access policy","Patching the operating system and runtime the function executes in","Deciding what the Lambda function's IAM role is allowed to touch","Lambda removes the guest operating system from the customer's plate entirely: there is no server to patch. Bucket access policy, IAM role permissions, and encryption choices stay with the customer no matter which compute service sits underneath, because those are data and identity decisions, not infrastructure ones.",{"question":922,"type":409,"options":923,"correctAnswers":928,"explanation":929},"Which of the following stay the customer's responsibility no matter whether the service is IaaS, PaaS, or SaaS? (Select all that apply.)",[924,925,926,927],"Data classification and encryption choices","Configuring identity and access management","Patching the hypervisor","Physical security of the data center",[924,925],"Data and identity never cross the line to the provider, regardless of how much of the stack it manages. The hypervisor and the physical data center sit at the opposite end: they are always the provider's job, since the customer never has physical or hypervisor-level access to change them.",{"question":931,"type":379,"options":932,"correctAnswer":934,"explanation":937},"A healthcare startup's cloud provider is ISO 27001 certified. What does that certification mean for the startup's own application?",[933,934,935,936],"The startup's application automatically inherits ISO 27001 certification","The certification covers the provider's infrastructure only; the startup still needs its own compliance evidence for its access controls and data handling","The startup no longer needs to configure any access controls","ISO 27001 only applies to on-premises data centers, not cloud providers","A provider's certification proves its own data centers, hypervisor, and managed services meet a standard. It says nothing about how the startup configured its buckets, wrote its access policies, or handled customer data on top of that infrastructure, which is exactly the gap a compliance audit checks.",{"question":939,"type":379,"options":940,"correctAnswer":942,"explanation":945},"An exam scenario asks who is responsible for configuring the security group rules on a virtual machine instance. Who is it?",[941,942,943,944],"The provider, since security groups are a network-layer control","The customer, since network access rules for an IaaS instance are the customer's configuration","It depends on the region the instance runs in","Neither; security groups are optional and rarely tested","Security groups act like a firewall around your instance, and under IaaS, configuring that firewall is squarely the customer's job. The provider secures the physical network between data centers; you decide which ports on your own instance are reachable and from where.",{"title":658,"description":659},"courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/01-cloud-security/01-shared-responsibility-model","dqw8QYJKVWltBzXhNhUxBUuhEuBDzLKtUbobZBYy53M"]