AWS Security, Governance, and Compliance Concepts for CLF-C02

AWS Artifact is the self-service, no-cost portal in the AWS Management Console where AWS publishes its own compliance documentation and where you accept legal agreements with AWS. When an auditor, regulator, or customer asks you to prove that AWS infrastructure meets a compliance standard, you do not open a support ticket or email an account manager; you download the evidence from Artifact. It has three areas:

• Reports gives on-demand downloads of third-party audit reports and certifications covering AWS itself, such as SOC 1, SOC 2, and SOC 3 reports, the PCI DSS attestation of compliance, and ISO certifications such as ISO 27001.
• Agreements lets you review, accept, and manage legal agreements with AWS, such as the Business Associate Addendum (BAA) that a US healthcare organization needs before it processes protected health information (PHI) on AWS.
• Third-party reports holds compliance reports from independent software vendors who sell on AWS Marketplace, so you can review a vendor's own audit evidence.

Account vs organization agreements. An account agreement covers only the account that accepted it. If you use AWS Organizations, you can instead accept an organization agreement, which covers the management account and every member account, including accounts added later. An organization agreement can be accepted only from the Organizations management account; a member account cannot accept one on behalf of the others. So a company with dozens of accounts that will all hold PHI accepts the organization BAA once, from the management account.

The key mental model: Artifact contains AWS's compliance evidence, not yours. A SOC 2 report from Artifact attests to the controls AWS operates for the infrastructure and services AWS manages; it says nothing about how you configured your own application, and it does not describe your resources. Demonstrating that your workloads are compliant is your job, and different services (covered later in this lesson) help you do it. Artifact needs no infrastructure and has no charge: it is a document portal, not a monitoring tool.

Beyond Artifact, AWS publishes public compliance information on its AWS Compliance pages, including the compliance programs AWS participates in and the AWS services in scope by compliance program list.

Compliance requirements differ because the rules a workload must satisfy depend on where you operate, what industry you are in, and which AWS services you use. There is no single global checklist, and CLF-C02 expects you to recognize all three dimensions.

Geography. Many jurisdictions impose data residency or data protection rules that dictate where personal data may be stored and processed. The European Union's GDPR is the best-known example; other countries, such as Japan, have their own rules. AWS supports these needs through its Region model: you choose the AWS Region where your content is stored, and AWS commits not to move your content out of the Region you selected unless you agree (or it is required by law). Copies in another Region exist only when you create them, for example through replication or backups you configure. Amazon CloudFront edge locations are different: they cache copies of content close to viewers to make delivery faster, but they do not decide where your original data is stored. The origin (an S3 bucket or a server in the Region you chose) remains the authoritative copy, and depending on the price class, cached copies can be served from edge locations in many countries. Residency is decided by Region choice, not by edge locations.

Some requirements need dedicated infrastructure. AWS GovCloud (US) Regions are isolated Regions designed for US government agencies and contractors with regulated workloads, such as those subject to ITAR (International Traffic in Arms Regulations) or FedRAMP High. They are operated by AWS employees who are screened US citizens on US soil. What makes GovCloud (US) suitable is that isolation and personnel screening; infrastructure that simply places AWS closer to users or on premises does not add those controls.

Industry. Regulated industries add their own frameworks: US healthcare organizations work under HIPAA, payment-card processors must meet PCI DSS, and public-sector workloads may require FedRAMP authorization. Your industry determines which reports you pull from Artifact, which agreements you accept, and which controls you must implement yourself.

Service. Compliance also varies among AWS services. Not every service is in scope for every program. AWS maintains a services in scope by compliance program list (and, for HIPAA, a list of HIPAA eligible services); before putting regulated data such as cardholder data or PHI on a service, especially a newly launched one, check that it is on the list for that program. Encryption defaults, Region count, or the existence of a SOC report do not answer that question.

In scope is not the same as compliant. A service being in scope means AWS's controls for that service were included in the third-party assessment. It does not make an application built on it compliant. Under the shared responsibility model, the customer still has to meet, and provide evidence for, its own controls (for example, how it configures access, encrypts data, and handles cardholder data), usually through its own assessment. AWS's attestation covers AWS's part only.

HIPAA-flavoured features: which one does what

Encryption at rest protects stored data, and encryption in transit protects data while it moves across a network. Encryption is the exam's favourite example of a cloud security benefit, and CLF-C02 tests it first as a classification exercise and then through who holds the keys and where the encryption happens.

Encryption at rest protects data that is stored: on a disk, in an object store, or in a database. If someone obtained the underlying storage media, the data would be unreadable without the keys. On AWS, at-rest encryption is delivered through integration with AWS Key Management Service (KMS), which creates the encryption keys and controls who can use them through key policies and IAM. Amazon S3 buckets, Amazon EBS volumes, Amazon RDS databases, and DynamoDB tables can all encrypt stored data with KMS keys, often with a single setting.

KMS vs AWS CloudHSM. KMS is a managed, multi-tenant service: its keys are protected by hardware security modules (HSMs) that AWS operates and shares across customers, and you never touch the hardware. AWS CloudHSM gives you dedicated, single-tenant HSMs in your own VPC; your own administrators manage the users and keys on them. Choose CloudHSM only when a regulation or policy demands key storage on hardware no other customer shares and that only you control; otherwise KMS is the simpler default. (KMS can also use a CloudHSM cluster as a custom key store, but the dedicated hardware still comes from CloudHSM.)

Encryption in transit protects data while it moves: between a client and an AWS endpoint, between services, or between Regions. The standard mechanism is TLS (the protocol behind HTTPS). AWS Certificate Manager (ACM) provisions and automatically renews the TLS certificates that Elastic Load Balancing and Amazon CloudFront use to serve HTTPS, so no one has to renew certificates by hand. AWS service API endpoints accept TLS connections, so calls to AWS are encrypted on the wire. Storing a certificate in Secrets Manager or encrypting a bucket does not encrypt traffic.

Server-side vs client-side encryption. TLS protects data only until it reaches the endpoint; there it is decrypted. With server-side encryption the service encrypts your data after it receives it, so AWS briefly handles the plaintext. In Amazon S3 that covers every server-side option:

Who supplies the key changes control and audit, not where encryption happens. If a policy says AWS must never handle the plaintext, even during upload, only client-side encryption meets it: you encrypt before sending, and AWS stores ciphertext it cannot read without your key.

The classification rule is mechanical: stored data (S3 object, EBS volume or snapshot, database backup) is at rest and pairs with KMS; moving data (browser to website, application to API, viewer to CloudFront) is in transit and pairs with TLS, HTTPS, and ACM. A well-secured workload uses both; they are complementary, not alternatives.

AWS security logs are captured by the service that sees the activity and are stored mainly in Amazon S3 (durable, low-cost, long-term retention) and Amazon CloudWatch Logs (search, metric filters, and alarms). Know the main sources, what each records, and where its data ends up.

• AWS CloudTrail records API activity across your account: console actions, console sign-ins, CLI commands, and SDK calls. Every account has event history, a console view of the last 90 days of management events. It is not stored in a bucket you own and it cannot be kept longer. For durable, multi-year retention you create a trail, which delivers log files to an Amazon S3 bucket you choose, and optionally also to CloudWatch Logs for alerting.
• VPC Flow Logs capture metadata about IP traffic to and from network interfaces in your VPC: source and destination addresses, ports, protocol, and whether traffic was accepted or rejected. They publish to CloudWatch Logs or Amazon S3 (or Amazon Data Firehose). They contain no request paths, HTTP status codes, or API callers.
• Amazon S3 server access logs record requests made to an S3 bucket: who requested which object and when. They are delivered to another S3 bucket you designate.
• Elastic Load Balancing access logs record each request an Application Load Balancer receives: the client's IP address, the request path, latencies, and the response status codes. They are off by default; when enabled, they are written to an S3 bucket you specify. Application Load Balancers also offer a newer CloudWatch Logs integration that can deliver to CloudWatch Logs, Amazon Data Firehose, or S3.
• Amazon CloudWatch Logs is the general-purpose log service: applications, AWS services, and the logs above can stream into it for search, retention, metric filters, and alarms.

Outputs that are not a full API record. Some features are built on CloudTrail data but are not an archive of it. CloudTrail Insights events are recorded only when CloudTrail detects unusual API activity (such as a burst of calls), so they are not a record of every call. GuardDuty findings are threat detections derived from CloudTrail and other logs, not the logs themselves, and GuardDuty keeps them for only 90 days. CloudTrail event history is likewise a 90-day console view rather than an archive you own. When you need every management API call kept for years, the answer is a trail delivering log files to S3.

Logging is the foundation of everything else in this task: Amazon GuardDuty analyzes CloudTrail events, VPC Flow Logs, and DNS query logs to find threats; CloudWatch turns log entries into alarms; and auditors ask for the S3 archive. Without captured logs there is nothing to monitor, audit, or investigate.

Customers secure resources on AWS by combining detectors that each look for a different kind of problem with a service that brings their findings together and DDoS protection at the edge. The exam tests whether you can keep them apart.

Amazon GuardDuty: threat detection. GuardDuty continuously analyzes account and network activity (CloudTrail events, VPC Flow Logs, and DNS query logs) using machine learning, anomaly detection, and threat intelligence to detect active threats: compromised credentials, API calls from unusual locations or known malicious IP addresses, an EC2 instance communicating with a malicious IP or a cryptocurrency-mining domain. It has no agents to install for its core detection, but it must be enabled in each account and Region; after a free trial it is billed by the volume of data it analyzes. GuardDuty Malware Protection for S3 scans newly uploaded objects in the buckets you choose for malware, which is a threat, so it belongs to GuardDuty rather than Macie.

Amazon Inspector: vulnerability management. Inspector scans your workloads (EC2 instances, container images in Amazon ECR, and AWS Lambda functions) for software vulnerabilities (known CVEs, such as an unpatched OS package or a library in a function's code) and unintended network exposure, then prioritizes findings by risk. GuardDuty watches for attacks happening now; Inspector finds the weaknesses an attacker could exploit later.

Amazon Macie: sensitive data discovery. Macie uses machine learning and pattern matching to discover sensitive data, such as credit card numbers or personal information, in Amazon S3, and reports buckets with weak security settings. Data = Macie, threats = GuardDuty, vulnerabilities = Inspector.

AWS Security Hub and AWS Security Hub CSPM: bringing findings together. In 2025 AWS split Security Hub into two services. AWS Security Hub CSPM (cloud security posture management) is the original service: it runs automated control checks of your resources against security standards such as AWS Foundational Security Best Practices and CIS AWS Foundations Benchmark. The current AWS Security Hub receives findings from Security Hub CSPM, GuardDuty, Inspector, Macie, and IAM Access Analyzer, then correlates and prioritizes them in one console, with exposure findings and automated response workflows. Neither one does the work of the detectors: they do not analyze DNS logs or flow logs for threats or scan instances for CVEs. Security Hub can only show findings that an enabled detector has produced; it never generates threat findings of its own.

AWS Shield: DDoS protection. Shield defends against distributed denial-of-service attacks. Shield Standard is automatic and free for every AWS customer, protecting against the most common network- and transport-layer attacks with no setup. Shield Advanced is a paid subscription that adds:

• enhanced detection and mitigation for larger, more sophisticated attacks on resources such as CloudFront, Route 53, Elastic Load Balancing, Global Accelerator, and Elastic IPs;
• near-real-time visibility into attacks, with metrics and reports on events affecting your resources;
• 24/7 access to the Shield Response Team (SRT), AWS's DDoS specialists;
• DDoS cost protection: service credits for usage charges on protected resources that spike because of an attack;
• health-based detection, which uses Route 53 health checks to detect and respond to attacks faster and more accurately;
• automatic application layer DDoS mitigation, which creates and manages AWS WAF rules for you during a layer-7 attack.

Only Shield Standard is both on by default and free. AWS WAF (layer-7 request filtering, a Task 2.4 topic) must be configured and is billed by web ACLs, rules, and requests, and GuardDuty must be enabled and is usage-billed. A company that wants DDoS protection without paying anything already has Shield Standard.

Governance services answer accountability questions rather than attack questions: how is it performing, who did what, what does it look like, and can we prove it to an auditor. Each service owns one of those questions.

Amazon CloudWatch: "how is it performing, and tell me when something happens." CloudWatch is the monitoring and observability service. It collects metrics (CPU utilization, request counts, latency), stores and searches logs (CloudWatch Logs, including application logs from EC2 instances), graphs metrics on dashboards, and fires alarms that notify you (usually through Amazon SNS) or trigger automated actions when a threshold is crossed. CloudWatch tells you about health and performance; it does not record who changed a resource.

AWS CloudTrail: "who did what, when, and from where?" CloudTrail records API calls and account activity as events: the identity that made the call, the time, the source IP address, and the parameters. If a bucket was deleted last week and you need to know which user or role did it, CloudTrail holds the answer.

Turning a CloudTrail event into an alert. CloudTrail records events but does not page anyone. A common pattern for near-real-time alerts, such as an email within minutes of a root user console sign-in, is: a trail sends its events to CloudWatch Logs → a metric filter matches the event pattern → a CloudWatch alarm fires on the metric → an Amazon SNS topic sends the email. (Amazon EventBridge rules on CloudTrail events are another route.) An alert can only be as fast and as specific as its data source, so it must be built on the service that records the activity itself as an event, not on a report generated periodically or on a log of a different kind of activity.

AWS Config: "what does my resource look like, what did it look like before, and does it follow our rules?" Config records the configuration state of your resources over time (a timeline of changes, with configuration history files delivered to S3) and evaluates resources against Config rules, flagging noncompliant ones, for example an EBS volume created without encryption or an S3 bucket that allows public access. A conformance pack deploys a collection of rules at once, such as a HIPAA- or PCI-aligned sample pack.

Detect vs fix. A Config rule only detects. To fix a noncompliant resource without anyone stepping in, attach a remediation action to the rule: it runs an AWS Systems Manager Automation runbook (for example, one that blocks public access on a bucket) and can be set to run automatically. The general principle: anything that notifies, reports, or adds more checks tells you about the problem but leaves the resource unchanged; only an action that modifies the resource fixes it.

AWS Audit Manager: "assemble evidence for my audit." Audit Manager continuously collects evidence from your AWS usage, maps it to controls in prebuilt or custom frameworks (such as PCI DSS, HIPAA, or GDPR-aligned frameworks), and builds audit-ready assessment reports. It automates the evidence-gathering for your audits, which is what distinguishes it from Artifact, where you download AWS's completed audit reports. It collects evidence; it does not block actions that break a control. Availability change: Audit Manager is in maintenance mode. From 30 April 2026 it cannot be set up in new accounts or new Regions, and no new frameworks are added; existing customers keep using it. AWS points new users to AWS Config conformance packs, which evaluate framework-aligned rules but do not build Audit Manager-style assessment reports. The exam guide still names Audit Manager, so know what it does, but do not treat it as the choice for a brand-new account.

IAM access reports are the reporting tools in this task: the credential report shows the state of every user's credentials, and last accessed information shows which permissions are actually used. Both feed access reviews that governance and auditors ask for. (Creating and managing users, roles, and policies is Task 2.3.)

The credential report is a snapshot: IAM generates a new one at most every four hours, so it is evidence for periodic reviews, not a source of near-real-time alerts. Last accessed information is the tool for roles, because the credential report does not list them. Do not confuse either with IAM Access Analyzer, which reports resources shared with principals outside your account or organization and unused access; it does not report MFA status.

Most Task 2.2 questions reduce to matching a need to a service. This table puts the services side by side.

The confusions that matter most:

• CloudTrail vs CloudWatch vs Config: CloudTrail = who did it (API activity). CloudWatch = how is it performing (metrics, dashboards, alarms). Config = what does or did it look like (configuration state, history, and rules).
• GuardDuty vs Inspector vs Macie: GuardDuty detects threats from activity (and malware in S3 uploads); Inspector finds vulnerabilities in workloads; Macie finds sensitive data in S3.
• Security Hub vs the detectors: GuardDuty, Inspector, and Macie produce findings; Security Hub brings them together and prioritizes them; Security Hub CSPM runs standards checks.
• Audit Manager vs Artifact: Audit Manager gathers evidence about your environment for your audits; Artifact hands you AWS's own audit reports about the underlying cloud.
• Detect vs fix: rules, packs of rules, and notifications detect; a Config remediation action changes the resource and fixes it.

A payments startup running on AWS must demonstrate PCI DSS compliance to a banking partner. Here is how the services in this task divide the work.

First, the bank asks for proof that AWS's infrastructure is PCI-compliant. The startup's engineer opens AWS Artifact and downloads the AWS PCI DSS attestation; no ticket, no waiting. The team also checks the services in scope list before choosing services for cardholder data, knowing that AWS's attestation covers only AWS's part: the startup's own controls still need their own assessment. Because the account is new, the team cannot set up AWS Audit Manager, so it deploys a PCI-aligned AWS Config conformance pack to check its resources and gathers the rest of the evidence itself.

For technical controls, cardholder data in Amazon S3 and Amazon RDS is encrypted at rest with AWS KMS keys, and the public API sits behind an Application Load Balancer serving HTTPS with a certificate from AWS Certificate Manager, which is encryption in transit. AWS Config rules flag any bucket that becomes public, and a remediation action blocks the public access automatically. AWS CloudTrail delivers a complete API history to an S3 bucket, the ALB writes access logs to S3, and a CloudWatch metric filter and alarm email the team if anyone signs in as the root user.

For ongoing defense, Amazon GuardDuty watches CloudTrail, VPC Flow Logs, and DNS logs for threats; Amazon Inspector scans the EC2 fleet, container images, and Lambda functions for CVEs; Amazon Macie confirms no card numbers have leaked into the wrong bucket; AWS Security Hub pulls those findings into one prioritized view; and AWS Shield Standard is already absorbing common DDoS attacks at no cost. Each quarter, the team downloads the IAM credential report to prove MFA is on and keys are rotated, and uses last accessed information to trim unused role permissions. Every question in this task is a fragment of a story like this one: identify which part of the story it asks about, and the right service follows.