[{"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-encryption-and-data-protection-en":4,"lesson-cloud-computing-fundamentals-security-and-reliability-cloud-security-encryption-and-data-protection-en":252,"next-cloud-computing-fundamentals-security-and-reliability-cloud-security-encryption-and-data-protection-en":467},null,{"locked":5,"reason":3,"meta":6,"item":17},false,{"title":7,"description":8,"isFree":5,"estimatedMinutes":9,"difficulty":10,"learningObjectives":11},"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,"intermediate",[12,13,14,15,16],"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":18,"title":7,"body":19,"description":8,"difficulty":10,"estimatedMinutes":9,"extension":172,"infographics":173,"isFree":5,"learningObjectives":187,"meta":188,"navigation":189,"path":190,"quiz":191,"seo":249,"stem":250,"__hash__":251},"courses/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/01-cloud-security/02-identity-and-access-management.md",{"type":20,"value":21,"toc":159},"minimark",[22,27,31,34,38,41,44,48,51,54,59,63,71,74,78,81,85,88,92,152,156],[23,24,26],"h2",{"id":25},"one-password-the-whole-account","One password, the whole account",[28,29,30],"p",{},"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,32,33],{},"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,35,37],{"id":36},"root-user-iam-users-and-roles","Root user, IAM users, and roles",[28,39,40],{},"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,42,43],{},"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,45,47],{"id":46},"two-separate-checks-authentication-then-authorization","Two separate checks: authentication, then authorization",[28,49,50],{},"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,52,53],{},"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.",[55,56],"infographic",{"alt":57,"slug":58},"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,60,62],{"id":61},"least-privilege-start-narrow-not-broad","Least privilege: start narrow, not broad",[28,64,65,66,70],{},"Say a developer's role needs to read files from one reporting bucket and nothing else. A least-privilege policy grants exactly that: the ",[67,68,69],"code",{},"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,72,73],{},"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,75,77],{"id":76},"the-boundary-groups-versus-roles","The boundary: groups versus roles",[28,79,80],{},"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,82,84],{"id":83},"misconception-a-strong-password-is-enough","Misconception: a strong password is enough",[28,86,87],{},"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,89,91],{"id":90},"exam-cues-matching-the-scenario-to-the-tool","Exam cues: matching the scenario to the tool",[93,94,95,108],"table",{},[96,97,98],"thead",{},[99,100,101,105],"tr",{},[102,103,104],"th",{},"The scenario says...",[102,106,107],{},"Points to",[109,110,111,120,128,136,144],"tbody",{},[99,112,113,117],{},[114,115,116],"td",{},"\"Assumed temporarily,\" \"no long-lived credentials,\" \"used by an application or service\"",[114,118,119],{},"IAM role",[99,121,122,125],{},[114,123,124],{},"\"Grant the same permissions to a whole team of people\"",[114,126,127],{},"IAM group",[99,129,130,133],{},[114,131,132],{},"\"Minimum permissions needed for a task\"",[114,134,135],{},"Least privilege",[99,137,138,141],{},[114,139,140],{},"\"Second factor,\" \"even if the password is compromised\"",[114,142,143],{},"Multi-factor authentication",[99,145,146,149],{},[114,147,148],{},"\"Vendor tool can't assume a role,\" \"legacy system,\" \"programmatic access from outside AWS\"",[114,150,151],{},"Long-term access key, as the fallback case",[23,153,155],{"id":154},"where-this-leaves-you","Where this leaves you",[28,157,158],{},"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":160,"searchDepth":161,"depth":161,"links":162},"",3,[163,165,166,167,168,169,170,171],{"id":25,"depth":164,"text":26},2,{"id":36,"depth":164,"text":37},{"id":46,"depth":164,"text":47},{"id":61,"depth":164,"text":62},{"id":76,"depth":164,"text":77},{"id":83,"depth":164,"text":84},{"id":90,"depth":164,"text":91},{"id":154,"depth":164,"text":155},"md",[174],{"slug":58,"concept":175,"style":176,"aspectRatio":177,"labels":178},"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","16:9",[179,180,181,182,183,184,185,186],"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.",[12,13,14,15,16],{},true,"/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/01-cloud-security/02-identity-and-access-management",{"passingScore":192,"questions":193},70,[194,203,211,217,223,231,241],{"question":195,"type":196,"options":197,"correctAnswer":199,"explanation":202},"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?","single",[198,199,200,201],"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":204,"type":196,"options":205,"correctAnswer":208,"explanation":210},"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?",[206,207,208,209],"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":212,"type":196,"options":213,"correctAnswer":135,"explanation":216},"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?",[214,143,135,215],"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":218,"type":196,"options":219,"correctAnswer":221,"explanation":222},"IAM groups and IAM roles are the same thing: both let you attach policies to more than one identity at once.",[220,221],"True","False","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":224,"type":196,"options":225,"correctAnswer":228,"explanation":230},"A workload running on an EC2 instance needs to read from an S3 bucket. Which approach matches current best practice?",[226,227,228,229],"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":232,"type":233,"options":234,"correctAnswers":239,"explanation":240},"Which of the following are genuine benefits of requiring multi-factor authentication? (Select all that apply.)","multiple",[235,236,237,238],"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",[235,237],"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":242,"type":196,"options":243,"correctAnswer":246,"explanation":248},"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?",[244,245,246,247],"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":7,"description":8},"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":253,"item":263},{"title":254,"description":255,"isFree":5,"estimatedMinutes":256,"difficulty":10,"learningObjectives":257},"Encryption and Data Protection","How encryption at rest and encryption in transit protect data at different points in its journey, how key management keeps encrypted data useless to anyone without permission, and where encryption's protection ends.",19,[258,259,260,261,262],"Distinguish encryption at rest from encryption in transit and identify which point in a request each one protects","Explain how AES-256 and TLS map to at-rest and in-transit protection respectively","Describe the isolation model behind managed key services and why it separates data access from key access","Compare a managed key service against a dedicated hardware security module and identify when each fits","Correct the misconception that encryption alone replaces the need for access control",{"id":264,"title":254,"body":265,"description":255,"difficulty":10,"estimatedMinutes":256,"extension":172,"infographics":396,"isFree":5,"learningObjectives":406,"meta":407,"navigation":189,"path":408,"quiz":409,"seo":464,"stem":465,"__hash__":466},"courses/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/01-cloud-security/03-encryption-and-data-protection.md",{"type":20,"value":266,"toc":385},[267,271,274,277,280,284,287,290,294,297,300,304,308,311,315,318,322,325,329,332,336,380,382],[23,268,270],{"id":269},"the-same-file-two-different-risks","The same file, two different risks",[28,272,273],{},"A support engineer debugging an issue captures network traffic between an app and its database while sitting in a coffee shop. If that connection is not encrypted, the engineer, or anyone else on the same Wi-Fi running the same capture, can read every password and every field moving through it, in plain text, as it happens.",[28,275,276],{},"Now picture a different moment entirely: months later, a decommissioned backup drive from that same database is sold or discarded without being wiped, and someone plugs it in. If the data on it was never encrypted, they can read it directly off the disk, no network capture required.",[28,278,279],{},"Same data, two completely different attack points, months apart. Protecting against one does nothing to protect against the other, which is why cloud platforms treat them as two separate controls: encryption in transit for data on the move, and encryption at rest for data sitting still.",[23,281,283],{"id":282},"encryption-at-rest-aes-256-and-server-side-encryption","Encryption at rest: AES-256 and server-side encryption",[28,285,286],{},"Encryption at rest protects data written to storage, disks, backups, database files, so that anyone who gains access to the physical or logical storage medium without authorization sees only unreadable ciphertext. The standard mechanism across every major cloud provider is AES-256, the 256-bit Advanced Encryption Standard block cipher, applied automatically or on request to data as it's written.",[28,288,289],{},"AWS calls its default approach server-side encryption: the storage service itself encrypts data before writing it and decrypts it on the way back out, all inside the service, using keys managed through a key management system. A customer typically doesn't touch the cipher directly; they choose a key management option and the storage service handles the rest.",[23,291,293],{"id":292},"encryption-in-transit-tls","Encryption in transit: TLS",[28,295,296],{},"Encryption in transit protects data while it's moving between two points on a network, a mobile app and a server, a load balancer and an application instance, one microservice and another. The standard mechanism is TLS, Transport Layer Security, which wraps a connection so that anyone capturing the raw network traffic sees only ciphertext, not the request or response itself.",[28,298,299],{},"As of mid-2024, every AWS API endpoint requires at least TLS 1.2 and supports TLS 1.3, the newer, faster version of the protocol. That baseline reflects an industry-wide pattern: older TLS versions and their predecessor, SSL, get retired as cryptographic weaknesses accumulate, and current guidance keeps pushing the accepted minimum forward.",[55,301],{"alt":302,"slug":303},"A diagram tracing a request from client through network to server to storage, showing TLS protecting the network segment as data moves and AES-256 protecting the storage segment where data comes to rest.","encryption-and-data-protection-request-path",[23,305,307],{"id":306},"the-gap-in-the-middle-data-in-use","The gap in the middle: data in use",[28,309,310],{},"Notice what neither protection covers. Once a request reaches the application server, the data has to be decrypted in memory, briefly, for the application to actually do anything with it, run a calculation, render a page, check a condition. That in-memory state is sometimes called data in use, and it sits outside what standard at-rest and in-transit encryption reach. It is a narrower, more specialized problem, and it is why \"encrypted everywhere\" is a simplification: encryption at rest and in transit cover the overwhelming majority of a request's journey, but not the instant the application is actively working with the plaintext.",[23,312,314],{"id":313},"key-management-separating-who-can-decrypt-from-who-holds-the-key","Key management: separating who can decrypt from who holds the key",[28,316,317],{},"Encrypting data is only half the problem; controlling who can decrypt it is the other half, and that is what a key management service does. AWS KMS runs inside hardware security modules built so that plaintext keys never leave the module, not even for AWS's own employees. A request to encrypt or decrypt something is authorized independently through the same IAM permissions covered in the previous lesson, which means access to the data and access to the key that unlocks it are two separately controlled layers. Compromising one does not automatically hand over the other, and every use of a key gets logged, giving an auditable trail of exactly when and by whom a piece of data was decrypted.",[23,319,321],{"id":320},"the-boundary-managed-key-service-versus-dedicated-hardware","The boundary: managed key service versus dedicated hardware",[28,323,324],{},"Most workloads use a managed key service like AWS KMS: shared, multi-tenant hardware behind a simple API, with AWS handling provisioning, patching, and availability. Some workloads, usually driven by a specific regulatory requirement, need a dedicated hardware security module instead, like AWS CloudHSM, giving the customer direct administrative control over single-tenant hardware they alone manage. The decision rule is narrow: default to the managed service, and reach for dedicated hardware only when a compliance requirement specifically mandates single-tenant control, since that option trades convenience for a burden of scaling and administration the customer now owns.",[23,326,328],{"id":327},"misconception-encryption-replaces-access-control","Misconception: encryption replaces access control",[28,330,331],{},"It's tempting to treat \"everything is encrypted\" as the end of the security conversation. It is not. Encryption protects data against someone who steals the storage medium or intercepts the network traffic without authorization. It does nothing to stop someone who already holds valid, authorized credentials, whether a legitimate employee or an attacker who has phished one, from reading data they're permitted to access, because the whole point of encryption is that authorized access decrypts it correctly. That is exactly the gap the previous lesson's IAM controls exist to close, and the two protections are meant to work together, not substitute for each other.",[23,333,335],{"id":334},"exam-cues-at-rest-or-in-transit","Exam cues: at rest or in transit",[93,337,338,346],{},[96,339,340],{},[99,341,342,344],{},[102,343,104],{},[102,345,107],{},[109,347,348,356,364,372],{},[99,349,350,353],{},[114,351,352],{},"\"Data written to disk,\" \"stored,\" \"a backup file\"",[114,354,355],{},"Encryption at rest",[99,357,358,361],{},[114,359,360],{},"\"Traveling over the network,\" \"between client and server,\" \"an API call\"",[114,362,363],{},"Encryption in transit",[99,365,366,369],{},[114,367,368],{},"\"Control who can use a key,\" \"authorized to decrypt\"",[114,370,371],{},"Key management, not encryption itself",[99,373,374,377],{},[114,375,376],{},"\"Single-tenant hardware,\" \"direct administrative control of the HSM\"",[114,378,379],{},"Dedicated hardware security module",[23,381,155],{"id":154},[28,383,384],{},"Encryption at rest and encryption in transit protect the same data at two different points in its journey, and a complete design needs both, since covering one leaves the other wide open. Neither one, though, decides who is allowed to ask for that data in the first place; that job stayed with identity and access management in the previous lesson. Together, the two controls answer \"who can act\" and \"what happens if a disk or a network gets compromised anyway.\" The next lesson turns to a related question: how a team proves, to an auditor or a regulator, that both controls are actually in place.",{"title":160,"searchDepth":161,"depth":161,"links":386},[387,388,389,390,391,392,393,394,395],{"id":269,"depth":164,"text":270},{"id":282,"depth":164,"text":283},{"id":292,"depth":164,"text":293},{"id":306,"depth":164,"text":307},{"id":313,"depth":164,"text":314},{"id":320,"depth":164,"text":321},{"id":327,"depth":164,"text":328},{"id":334,"depth":164,"text":335},{"id":154,"depth":164,"text":155},[397],{"slug":303,"concept":398,"style":176,"aspectRatio":177,"labels":399},"A left-to-right diagram tracing one request across four stages: Client, Network, Server, Storage. A shield icon spans the Network stage between Client and Server, labeled with TLS and captioned 'in transit.' A lock icon sits at the Storage stage, labeled with AES-256 and captioned 'at rest.' The Server stage in the middle is visually distinct, unshaded, captioned that data is briefly decrypted in memory there to be processed. A footer strip carries the takeaway that in-transit and at-rest protections cover different points in the same journey and neither substitutes for access control.",[400,401,402,403,404,405],"Client: request originates","Network: TLS encrypts data in transit between client and server","Server: data is briefly decrypted in memory to be processed","Storage: AES-256 encrypts data at rest on disk","In transit and at rest protect different points in the same journey.","Encryption protects stolen disks and intercepted traffic, not misused valid credentials.",[258,259,260,261,262],{},"/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/01-cloud-security/03-encryption-and-data-protection",{"passingScore":192,"questions":410},[411,419,427,435,439,447,456],{"question":412,"type":196,"options":413,"correctAnswer":416,"explanation":418},"A support engineer debugging an issue captures network traffic between an app and its database over public Wi-Fi. If that traffic isn't encrypted, what has the engineer, or anyone else running the same capture, just been able to read?",[414,415,416,417],"Nothing; network traffic cannot be captured without physical access to the server","Only the destination IP address, never the data itself","Every password and every piece of data moving through that connection, in plain text","Only encrypted data, since all cloud traffic is encrypted automatically regardless of configuration","Unencrypted network traffic is readable by anyone positioned to capture it, which is exactly why encryption in transit exists. A protocol like TLS turns that same capture into unreadable ciphertext, protecting the data for the entire trip between client and server.",{"question":420,"type":196,"options":421,"correctAnswer":423,"explanation":426},"Which pair correctly matches a protection to what it defends?",[422,423,424,425],"TLS protects data at rest; AES-256 protects data in transit","AES-256 protects data at rest; TLS protects data in transit","Both TLS and AES-256 protect only data in transit","Both TLS and AES-256 protect only data at rest","AES-256 is a block cipher applied to data written to disk, protecting it if the physical storage is ever accessed without authorization. TLS operates at the network layer, encrypting data as it travels between two endpoints, so someone intercepting the connection sees only ciphertext.",{"question":428,"type":196,"options":429,"correctAnswer":431,"explanation":434},"A managed key service like AWS KMS separates who can use a key to decrypt data from who can access the key material itself. Why does this separation matter?",[430,431,432,433],"It doesn't matter; the two are the same thing in practice","It lets the provider isolate control over data access from control over the encryption keys, adding a layer of separation even the provider's own employees cannot bypass","It only matters for compliance paperwork, not actual security","It means customers never need to manage any permissions at all","Managed key services run inside hardware security modules designed so plaintext keys never leave the module, not even for the provider's own staff. Keeping key-use permissions and data-access permissions as separate, independently controlled layers means compromising one doesn't automatically hand over the other.",{"question":436,"type":196,"options":437,"correctAnswer":221,"explanation":438},"A managed key service and a dedicated hardware security module solve the same problem the same way, so the choice between them never matters.",[220,221],"A managed key service runs on shared, multi-tenant hardware behind a convenient API, which fits most workloads. A dedicated hardware security module gives a customer direct administrative control over single-tenant hardware, which specific compliance requirements sometimes mandate. Picking the dedicated option without that requirement adds operational overhead most workloads don't need.",{"question":440,"type":196,"options":441,"correctAnswer":444,"explanation":446},"A team encrypts all of its stored customer data with AES-256, then concludes it no longer needs to review who has IAM access to that data. What is wrong with this conclusion?",[442,443,444,445],"Nothing is wrong; encryption alone is always sufficient","AES-256 is not a real encryption standard","Encryption protects the data if the storage medium is stolen, but anyone with valid, authorized access decrypts it exactly as intended, so access control is still doing separate, necessary work","Encryption should be disabled entirely once access controls are in place","Encryption defends against a stolen disk or an intercepted connection. It does nothing to stop someone who holds valid credentials, whether an authorized employee or an attacker who has stolen those credentials, from reading data they're permitted to access. That is exactly what IAM and least privilege exist to control.",{"question":448,"type":233,"options":449,"correctAnswers":454,"explanation":455},"Which of the following scenarios point toward encryption in transit rather than encryption at rest? (Select all that apply.)",[450,451,452,453],"An API call carrying a password between a mobile app and a server","A nightly backup file written to a storage bucket","A request moving between a load balancer and an application server","A database file sitting untouched on disk overnight",[450,452],"Both correct scenarios describe data actively moving across a network connection, exactly what TLS protects. The backup file and the untouched database file both describe data sitting on storage media, which is what AES-256 style at-rest encryption protects instead.",{"question":457,"type":196,"options":458,"correctAnswer":462,"explanation":463},"According to current AWS guidance, what is the minimum TLS version all AWS API endpoints require as of mid-2024?",[459,460,461,462],"TLS 1.0","SSL 3.0","TLS 1.1","TLS 1.2, with all endpoints also supporting TLS 1.3","AWS requires at least TLS 1.2 for API requests and supports TLS 1.3 across all its service endpoints, reflecting the same steady tightening of minimum encryption standards seen across the industry as older protocol versions are retired for known weaknesses.",{"title":254,"description":255},"courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/01-cloud-security/03-encryption-and-data-protection","6HexOgHCohnAScCFce6j_cjODzlA7oxo-Yt6roMKwZs",{"locked":5,"reason":3,"meta":468,"item":477},{"title":469,"description":470,"isFree":5,"estimatedMinutes":471,"difficulty":10,"learningObjectives":472},"Governance and Compliance","How cloud governance sets an organization's own rules for resource use, how compliance proves those rules satisfy an external framework or regulation, and where a provider's certifications end and a customer's own evidence has to begin.",18,[473,474,475,476],"Distinguish governance from compliance and explain what each one is answering","Compare ISO 27001, SOC 2, PCI DSS, HIPAA, and GDPR by what each covers and who typically needs it","Explain what a provider's compliance report proves and what it leaves for the customer to demonstrate separately","Distinguish data residency from data sovereignty and identify which one a scenario is actually testing",{"id":478,"title":469,"body":479,"description":470,"difficulty":10,"estimatedMinutes":471,"extension":172,"infographics":706,"isFree":5,"learningObjectives":707,"meta":708,"navigation":189,"path":709,"quiz":710,"seo":761,"stem":762,"__hash__":763},"courses/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/01-cloud-security/04-governance-and-compliance.md",{"type":20,"value":480,"toc":695},[481,485,488,491,495,498,501,505,595,598,602,605,609,612,615,619,622,626,629,633,690,692],[23,482,484],{"id":483},"a-certificate-that-didnt-cover-what-they-thought","A certificate that didn't cover what they thought",[28,486,487],{},"A healthcare startup signs up with a major cloud provider, sees the SOC 2 and ISO 27001 badges on the provider's compliance page, and tells its board the platform is HIPAA-compliant. Months later, an actual HIPAA audit asks for the startup's own access logs, its encryption configuration, and records of staff security training, none of which the provider's certifications ever claimed to cover.",[28,489,490],{},"This is the same gap the first lesson in this topic named as a misconception, now playing out in full: a provider's certification proves its own infrastructure meets a standard. Whether the application built on top of it meets that same standard is a separate question, and it's exactly what governance and compliance, as a discipline, exist to answer.",[23,492,494],{"id":493},"governance-asks-inward-compliance-points-outward","Governance asks inward, compliance points outward",[28,496,497],{},"Governance is an organization's own rulebook for how its cloud resources get configured and used: who reviews access requests, how resources get tagged, what configuration baseline every new service has to meet before it goes live. It's internally driven, and a company can have strong governance with no external framework in play at all.",[28,499,500],{},"Compliance is different: it's proving, to an auditor, a regulator, or a customer's own procurement team, that an organization's practices meet a specific external bar. That bar might be a certifiable standard a company chooses to pursue, or a law it has no choice but to satisfy. Good governance makes compliance easier to demonstrate, but the two answer different questions: governance asks \"are we doing this consistently,\" compliance asks \"can we prove it to someone outside the organization.\"",[23,502,504],{"id":503},"the-compliance-landscape-what-each-framework-actually-covers","The compliance landscape: what each framework actually covers",[93,506,507,523],{},[96,508,509],{},[99,510,511,514,517,520],{},[102,512,513],{},"Framework",[102,515,516],{},"What it covers",[102,518,519],{},"Who typically needs it",[102,521,522],{},"Certification or law",[109,524,525,539,553,567,581],{},[99,526,527,530,533,536],{},[114,528,529],{},"ISO 27001",[114,531,532],{},"A full information security management system: risk assessment, access control, incident management",[114,534,535],{},"Any organization, internationally recognized",[114,537,538],{},"Certification, valid 3 years",[99,540,541,544,547,550],{},[114,542,543],{},"SOC 2",[114,545,546],{},"Five trust service criteria: security, availability, processing integrity, confidentiality, privacy",[114,548,549],{},"US-focused, especially SaaS and tech vendors",[114,551,552],{},"Attestation report, an auditor's opinion",[99,554,555,558,561,564],{},[114,556,557],{},"PCI DSS",[114,559,560],{},"Protecting payment card data specifically, 12 requirements from network security to access restriction",[114,562,563],{},"Any organization that stores, processes, or transmits cardholder data",[114,565,566],{},"Certifiable standard",[99,568,569,572,575,578],{},[114,570,571],{},"HIPAA",[114,573,574],{},"Protecting patient health information (PHI)",[114,576,577],{},"US healthcare organizations and their vendors",[114,579,580],{},"US federal law",[99,582,583,586,589,592],{},[114,584,585],{},"GDPR",[114,587,588],{},"Personal data of individuals in the EU, including international transfer rules",[114,590,591],{},"Any organization handling EU residents' personal data, regardless of where the organization is based",[114,593,594],{},"EU law",[28,596,597],{},"ISO 27001 and SOC 2 overlap substantially in the controls they check, enough that a well-run compliance program can often satisfy both without duplicating the work, but they serve different audiences: SOC 2 is what a US enterprise customer usually asks for, ISO 27001 is what an international one usually expects.",[23,599,601],{"id":600},"where-to-find-the-providers-half-of-the-evidence","Where to find the provider's half of the evidence",[28,603,604],{},"A cloud provider doesn't email its compliance reports on request; it publishes them through a self-service portal. AWS's version is called AWS Artifact, giving any account on-demand access to AWS's own SOC 1/2/3, ISO, and PCI reports, each generated with a unique watermark for the requester. That portal is the customer's starting point when an auditor asks \"show me the provider's controls,\" and it's free to use. What it can never hand over is the other half of the evidence, the customer's own configuration, access logs, and internal processes, because AWS Artifact only documents AWS's side of the shared responsibility line.",[23,606,608],{"id":607},"data-residency-versus-data-sovereignty","Data residency versus data sovereignty",[28,610,611],{},"These two terms get used interchangeably, and the exam boundary between them is worth naming explicitly. Data residency is about physical location: where, geographically, is the data stored. Data sovereignty is about legal jurisdiction: whose laws govern that data, regardless of where it happens to sit.",[28,613,614],{},"GDPR is a useful case study because it clarifies which one it actually cares about. GDPR does not require EU personal data to physically stay inside the EU. What it requires, under its rules on international transfers, is that any transfer of personal data outside the EU or EEA receive protection that's essentially equivalent to what GDPR itself provides, through mechanisms like an adequacy decision covering the destination country, or standard contractual clauses between sender and receiver. A company can choose an EU cloud region for good operational reasons, lower latency to EU users, a simpler story for customers, but doing so addresses residency, a location question. It does not, by itself, satisfy the legal transfer question GDPR is actually asking if that same data later gets copied, backed up, or processed somewhere outside the EU.",[23,616,618],{"id":617},"a-worked-example-choosing-a-region-for-eu-personal-data","A worked example: choosing a region for EU personal data",[28,620,621],{},"Say a team is building a service that stores personal data belonging to EU residents. Picking an EU-based region keeps that data physically close to its users and gives a simple answer to \"where does our data live.\" But the team still has to check every place that data travels afterward: a support tool hosted outside the EU, an analytics pipeline in a US region, a backup replicated to another continent. Each of those is a transfer under GDPR's Chapter 5 rules, and each one needs its own legal basis, an adequacy decision for that destination, or contractual clauses, regardless of how carefully the primary region was chosen.",[23,623,625],{"id":624},"misconception-revisited-inheriting-a-badge","Misconception, revisited: inheriting a badge",[28,627,628],{},"The first lesson in this topic named this misconception in the context of security generally; here it is the specific, recurring compliance mistake: assuming a provider's certification transfers automatically to whatever a customer builds on top of it. It never does. AWS Artifact, or its equivalent on any provider, hands over evidence of the provider's own controls. The customer still has to assemble evidence of its own: access reviews, encryption configuration from the previous lesson, employee training, incident response processes, everything that HIPAA, PCI DSS, or a customer's own security questionnaire actually asks to see.",[23,630,632],{"id":631},"exam-cues-matching-a-scenario-to-a-framework","Exam cues: matching a scenario to a framework",[93,634,635,643],{},[96,636,637],{},[99,638,639,641],{},[102,640,104],{},[102,642,107],{},[109,644,645,652,659,666,674,682],{},[99,646,647,650],{},[114,648,649],{},"\"Patient health information,\" \"healthcare provider\"",[114,651,571],{},[99,653,654,657],{},[114,655,656],{},"\"Credit card data,\" \"cardholder data environment\"",[114,658,557],{},[99,660,661,664],{},[114,662,663],{},"\"Personal data of EU individuals,\" \"international transfer\"",[114,665,585],{},[99,667,668,671],{},[114,669,670],{},"\"Where our data is physically stored\"",[114,672,673],{},"Data residency",[99,675,676,679],{},[114,677,678],{},"\"Whose laws apply to our data\"",[114,680,681],{},"Data sovereignty",[99,683,684,687],{},[114,685,686],{},"\"Need the provider's own audit reports\"",[114,688,689],{},"AWS Artifact, or the provider's equivalent portal",[23,691,155],{"id":154},[28,693,694],{},"Compliance is never something a customer inherits wholesale from a provider's badge page; it's something assembled from the provider's certified infrastructure plus the customer's own controls layered on top, the exact same boundary the shared responsibility model drew at the start of this topic, now applied specifically to proving it to an outsider. That closes out Cloud Security: you can now name who owns which security task, how identity and encryption enforce that ownership, and how governance and compliance prove it holds up under audit. The next topic in this domain leaves security behind and asks a different question entirely: once a system is secure, how does it stay running.",{"title":160,"searchDepth":161,"depth":161,"links":696},[697,698,699,700,701,702,703,704,705],{"id":483,"depth":164,"text":484},{"id":493,"depth":164,"text":494},{"id":503,"depth":164,"text":504},{"id":600,"depth":164,"text":601},{"id":607,"depth":164,"text":608},{"id":617,"depth":164,"text":618},{"id":624,"depth":164,"text":625},{"id":631,"depth":164,"text":632},{"id":154,"depth":164,"text":155},[],[473,474,475,476],{},"/courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/01-cloud-security/04-governance-and-compliance",{"passingScore":192,"questions":711},[712,720,728,732,736,744,752],{"question":713,"type":196,"options":714,"correctAnswer":717,"explanation":719},"A healthcare startup sees the SOC 2 and ISO 27001 badges on its cloud provider's compliance page and tells its board the platform is fully HIPAA-compliant. An auditor later asks for the startup's own access logs, encryption configuration, and staff training records. What did the startup get wrong?",[715,716,717,718],"Nothing; the provider's certifications cover HIPAA automatically","SOC 2 and ISO 27001 aren't real compliance frameworks","It assumed the provider's infrastructure certifications covered its own application-level controls, which HIPAA also requires evidence for","HIPAA does not apply to healthcare data stored in the cloud","This is the same boundary the shared responsibility model draws for security, applied to compliance: a provider's certification proves its own infrastructure meets a standard, but a customer's access controls, encryption configuration, and internal processes need their own separate compliance evidence.",{"question":721,"type":196,"options":722,"correctAnswer":724,"explanation":727},"What is the clearest distinction between governance and compliance in a cloud context?",[723,724,725,726],"They are two names for the same activity","Governance is an organization's own rules for how cloud resources are configured and used; compliance is proving those rules satisfy an external framework or regulation","Governance only applies to cost management, and compliance only applies to security","Compliance is optional, while governance is legally required","Governance is internally driven, an organization deciding its own policies for access review, tagging, or configuration standards. Compliance points outward, demonstrating to an auditor, regulator, or customer that those internal practices meet a specific external bar, whether that bar is a certifiable standard or a legal requirement.",{"question":729,"type":196,"options":730,"correctAnswer":557,"explanation":731},"A company processes credit card payments directly and needs to prove it protects cardholder data. Which framework specifically governs this?",[571,585,557,529],"PCI DSS is built specifically around protecting payment card data, with 12 requirements covering everything from network security to restricting access by business need to know. HIPAA covers health data, GDPR covers personal data of EU individuals, and ISO 27001 is a general information security management standard, not payment-specific.",{"question":733,"type":196,"options":734,"correctAnswer":221,"explanation":735},"ISO 27001 and SOC 2 are functionally identical, so a company that has one never needs to pursue the other.",[220,221],"ISO 27001 is an internationally recognized certification for an information security management system, valid for three years and widely expected outside the US. SOC 2 is a US-focused attestation report evaluated against five trust service criteria. Their controls overlap substantially, but a company selling into both US and international markets often ends up needing both.",{"question":737,"type":196,"options":738,"correctAnswer":739,"explanation":743},"A team wants to hand its auditor AWS's own SOC 2 and PCI reports as part of a compliance review, without contacting an AWS sales representative. Which AWS service is built exactly for this?",[739,740,741,742],"AWS Artifact","AWS IAM","AWS KMS","Amazon CloudWatch","AWS Artifact is a self-service portal giving any AWS account on-demand access to AWS's own compliance reports, including SOC 1/2/3, ISO, and PCI documentation, each generated with a unique watermark. It's the customer's way to retrieve the provider's half of the compliance evidence without a manual request process.",{"question":745,"type":196,"options":746,"correctAnswer":749,"explanation":751},"A company decides to store all EU customer data in an EU-based cloud region and concludes this alone satisfies GDPR's requirements for that data. What does this conclusion overlook?",[747,748,749,750],"GDPR does not apply to data stored in the EU","GDPR requires all data to be stored outside the EU","Data residency, where data physically sits, is different from GDPR's actual requirement, which governs international transfers and requires adequate protection wherever data eventually moves","Storing data in a specific region has no relationship to any compliance framework","GDPR itself does not mandate that personal data stay physically inside the EU. What it mandates is that any transfer outside the EU or EEA receive essentially equivalent protection, through mechanisms like an adequacy decision or standard contractual clauses. Choosing an EU region is a reasonable practice, but it addresses data residency, a physical-location question, not the legal-transfer question GDPR is actually asking.",{"question":753,"type":233,"options":754,"correctAnswers":759,"explanation":760},"Which of the following are true about NIST SP 800-144, the guidelines on security and privacy in public cloud computing? (Select all that apply.)",[755,756,757,758],"It is published by the US National Institute of Standards and Technology","It is a legally binding regulation enforced worldwide","It discusses security and privacy challenges and safeguards for organizations moving to public cloud","It is aimed at people making decisions about cloud computing initiatives, including security professionals and IT managers",[755,757,758],"NIST publications like SP 800-144 are guidance documents, widely referenced and often required for US federal systems, but not a global legal mandate in the way GDPR is. They're written for the people actually deciding how an organization approaches cloud security, from executives to system administrators.",{"title":469,"description":470},"courses/cloud-computing-fundamentals/en/domains/03-security-and-reliability/01-cloud-security/04-governance-and-compliance","_PCoeERQGlRTd0TQ-nUyl6XNcQqfriWuYbxryLMEJ28"]