AWS Certified Security Specialty SCS-C02 (SCS-C02) — Questions 1–75

Modifying the KMS key policy is the correct approach because the key policy is the resource-based policy that directly controls which principals can call kms:Decrypt on the CMK. By explicitly listing only authorized IAM roles as principals with Decrypt permission, you ensure that even if an S3 bucket policy or object ACL grants read access to ciphertext, those roles cannot decrypt it without the key. This is a robust data protection strategy because it combines S3 access control with KMS key-level authorization.

AWS Firewall Manager is the service designed to centrally configure and administer VPC security rules across accounts in an AWS Organization. It lets you create security group policies and network ACL policies that are automatically applied to new and existing VPC resources, enforcing a consistent security posture. This central management capability directly matches the scenario of managing VPC security centrally.

An IAM role is the correct entity for granting temporary access because it is designed to be assumed. When a principal assumes a role, AWS STS returns temporary security credentials with a limited lifetime, governed by the role's trust policy and permissions policy. This is the standard mechanism for federated access, cross-account access, and EC2 instance profiles.

AWS IAM Access Analyzer is correct because it performs automated, semantic analysis of the trust policy attached to the IAM role and identifies whether the role can be assumed by principals outside your AWS account or AWS organization. It generates concrete findings for external access, including the exact external principal and the action that grants access, so your security team can directly review and remediate the role. Other services merely log or aggregate activity; Access Analyzer specifically applies reachability logic to the policy statements.

An SCP that denies cloudtrail:StopLogging and cloudtrail:DeleteTrail is an effective preventive control at the organization level. SCPs are inherited by all member accounts and cannot be bypassed by the account's IAM administrators or even the root user, guaranteeing that the CloudTrail trail remains active and undisputed. This directly addresses the requirement to ensure that no one can stop or remove the audit history, making it a correct answer.

Create an IAM role with an S3 access policy, then place that role in an instance profile and attach the profile to the EC2 instance at launch or via the console/API. When the instance starts, it uses the role's trust policy to assume the role and receives temporary credentials from the instance metadata service (IMDSv1 or IMDSv2) that are automatically rotated. The SDK then uses these credentials to sign requests to S3 for the duration of the role session, enforcing the exact permissions granted by the role while avoiding the need to embed static keys.

AWS Config does not record API calls; CloudTrail already records the session issuer in management events.

This is the officially supported AWS method for adding encryption at rest to an existing unencrypted RDS instance. You take a manual snapshot, copy that snapshot while specifying a KMS key (which encrypts the snapshot copy), and then restore the encrypted snapshot to a new DB instance. The restored instance is encrypted at the storage layer, and you can repoint your application to its new endpoint before decommissioning the original instance. After creation, encryption on that restored instance cannot be disabled.

The ALB is the public entry point for the web application, so its security group must permit inbound HTTP from any IPv4 address. Allowing 0.0.0.0/0 on port 80 is required for clients on the internet to reach the load balancer. The ALB then forwards requests to the EC2 instances, whose own security group controls traffic from the ALB only.

EventBridge matches CloudTrail events against a rule pattern, for example filtering on the root account's ARN, and routes matches to an SNS topic or Lambda function. This provides the near-real-time detection and notification mechanism the scenario requires.

To retrieve credentials dynamically, the application must use the Secrets Manager API to fetch the secret at runtime. This requires code changes to call GetSecretValue and appropriate IAM permissions for the EC2 instance role to access the secret. This approach eliminates hardcoded credentials and allows automatic rotation to take effect without application changes.

The StringNotEquals operator evaluates to true when the volume's tag value is anything other than Production, so the Deny applies only to non-Production volumes. Production-tagged volumes fail the negative condition and are therefore allowed by the Deny statement to be deleted. If the goal is to protect Production volumes from deletion, the policy should use StringEquals with the value Production so that only matching volumes are denied.

SSE-KMS integrates Amazon S3 with AWS Key Management Service to perform server-side encryption using envelope encryption: S3 calls KMS to generate a data key, encrypts the object with it, and stores the encrypted data key alongside the object. It supports customer-managed KMS keys, enabling granular access control through IAM and KMS policies, automatic key rotation, and audit logs via CloudTrail. This makes it particularly suitable for sensitive data requiring separation of duties and compliance traceability, though it is only one of several valid S3 server-side encryption options.

Service control policies set permission guardrails across an AWS Organizations root, and an explicit deny for iam:CreateUser applies to every principal in every member account, including account administrators. This centrally prevents new IAM users organisation-wide, satisfying the requirement without editing each account individually.

S3 server access logs provide a comprehensive, per-request record of every call made to a bucket, including requester identity, bucket name, object key, request type, HTTP status, error codes, source IP address, User-Agent, and timestamps. This granular data is exactly what is needed to trace unauthorized access or data exfiltration during a compromise. Unlike CloudTrail, server access logs are enabled directly on the S3 bucket and capture all requests, even those that are denied or made anonymously, making them the most direct evidence source.

This is the correct condition because it explicitly requires the s3:x-amz-server-side-encryption header to carry the value aws:kms. In a bucket policy, a Deny with this condition rejects any PutObject call that is not using SSE-KMS, thereby enforcing KMS encryption on all stored objects. It targets the encryption mode directly and avoids the ambiguity of key-ID or source-based checks.

Shield Advanced is integrated natively with Amazon CloudWatch Events (now Amazon EventBridge), publishing real-time events such as DDoSDetected, AwsShibboleth, and AwsServiceEventNotification. Rather than polling or manual monitoring, you create a CloudWatch Events rule that matches these Shield event types and sets an AWS Lambda function as its target; the Lambda function then formats the event detail and publishes a message to an Amazon SNS topic, enabling timely notifications to your incident-response team. This pattern is the documented, reliable way to automate responses to Shield Advanced findings because it puts the filtering and routing logic in the event bus, not in the notification channel itself.

VPC Flow Logs record source/destination IPs, ports, and protocol for all traffic in a VPC. Anomalies such as outbound calls to known threat-intel IPs, repeated failed connection attempts, or large data transfers can signal a compromised EC2 instance. However, Flow Logs are raw metadata requiring additional analytics (e.g., Athena queries) to surface threats.

AWS WAF managed rule groups such as AWSManagedRulesSQLiRuleSet and AWSManagedRulesCommonRuleSet are purpose-built to detect SQL injection (SQLi) and cross-site scripting (XSS) using context-aware inspection that decodes and normalizes the request. Unlike simple regex matching, these rule groups apply heuristic and signature-based analysis that catches encoded payloads, comment obfuscation, and case variations, and AWS continuously updates them to address new evasion techniques, making them the appropriate, low-maintenance solution for this threat.

This statement is correct because the resource ARN uses the ${aws:username} variable, which automatically resolves to the IAM user name making the API call. The resulting ARN matches only that user's own IAM user resource, restricting CreateAccessKey, UpdateAccessKey, DeleteAccessKey, and similar key actions to the caller's own keys. This is the standard pattern for delegating self-service access key management while preserving separation of duties.

Automatic key rotation is a feature of AWS KMS customer managed keys that rotates the backing key material annually while retaining the same key ID and ARN. Applications continue to use the same key identifier, and AWS KMS automatically uses the new material for new encryption operations. This meets the requirement for transparent yearly rotation without application changes. The rotation is managed by AWS KMS and requires no additional infrastructure.

Creating a CloudHSM cluster with at least two HSMs in different Availability Zones ensures that if one HSM or AZ becomes unavailable, the other HSM can continue serving cryptographic operations. CloudHSM automatically synchronizes users, keys, and policies across all HSMs in the cluster, so the remaining HSM has the same key material. This architecture provides redundancy, high availability, and aligns with AWS recommended best practices for CloudHSM. Hence, it is the correct answer for improving durability/availability while keeping the HSM-based control.

Enabling default encryption on the bucket with SSE-S3 or SSE-KMS ensures every object placed in S3 is automatically encrypted at rest, even if the client does not send an encryption header. SSE-S3 uses AES-256 managed by AWS, while SSE-KMS uses envelope encryption with a customer-managed KMS key, giving you auditability, key rotation, and fine-grained access control. This is the simplest baseline measure to satisfy typical encryption-at-rest requirements for a new S3 data protection strategy.

Enabling automatic rotation in Secrets Manager with a 30-day interval is the correct managed solution. Secrets Manager schedules the rotation, invokes the configured Lambda rotation function, and coordinates the change of the database password with the secret's version lifecycle using AWSCURRENT and AWSPREVIOUS staging labels. You simply choose the rotation interval, and the service handles all scheduling, retries, and permissions, providing the lowest operational overhead. This also works with common database services like RDS via the built-in rotation templates.

If the new instance was launched without appending the security group that contains the SSH rule, or was attached to a different security group, the rule never applies to that instance. Security group membership is determined at launch time for the primary ENI, and editing rules on the intended group only affects instances that are actually associated with it. To resolve this, you must attach the correct security group to the running instance or relaunch with the right group selected.

The AWS Encryption SDK encrypts objects on the EC2 instance before upload, so plaintext never reaches S3 and keys remain outside AWS's control. This satisfies the stem's client-side encryption requirement for data at rest in S3.

This is the correct automated response because Amazon EventBridge natively receives GuardDuty findings and can invoke a Lambda function as a target. The Lambda function first calls the EC2 CreateSnapshot API, ensuring a forensic copy of the EBS volume is preserved before any state changes. Then, instead of terminating the instance, it uses AWS Systems Manager Automation with a predefined document to modify the security group to allow only the trusted management IP, and finally stops the instance—which preserves the instance for further analysis and minimizes the risk of losing evidence.

An explicit `Deny` in the bucket policy overrides the execution role's `Allow`, so the Lambda invocation fails despite having `s3:PutBucketPolicy`. Because the function and bucket share an account, cross-account trust is irrelevant; the blocking constraint is the bucket policy's explicit deny, which must be reviewed and removed.

Creating IAM roles in each member account that allow incident responders in the security account to assume those roles is a standard centralized access pattern. This grants the responders the exact permissions needed to investigate and remediate incidents in any affected account, while maintaining least privilege and full auditability. It avoids the need for shared credentials or per-account logins, and ensures that every cross-account assumption is recorded in CloudTrail for accountability.

AWS CloudTrail records every AWS API call as an event, capturing the identity of the caller, the source IP address, the request parameters, and the response elements. For an audit of all resource changes, CloudTrail is the authoritative source because nearly every modification to an AWS resource is implemented through a management-plane API call that gets logged.

Using HTTPS endpoints for S3 API calls means every request and response is encrypted with TLS, preventing attackers from reading or tampering with data in transit between an EC2 instance and S3. All AWS SDKs and the AWS CLI are configured to use HTTPS by default when sending S3 operations, and S3's TLS endpoints provide server authentication via AWS-managed certificates. This is the correct, native mechanism to meet the data-in-transit protection requirement for EC2-to-S3 communication.

iam:ChangePassword is the precise self-service action that enables a user to update their own console password (or password used for programmatic access via the password-based APIs). When a user calls ChangePassword, IAM verifies the existing password and then replaces it, with the permission scoped to the principal's own identity. It is the only action among these options that directly corresponds to the requirement of letting a user change their own password.

Enabling automatic key rotation on a customer managed key lets AWS KMS rotate the backing key material annually without changing the key ID or ARN, so existing ciphertext and applications continue working. This satisfies the yearly rotation requirement.

CloudTrail log file integrity validation employs a SHA-256 hash chain to detect any modification, deletion, or forgery of log files. CloudTrail periodically creates signed digest files that list the hash of every log file delivered in that period along with the hash of the previous digest, and each digest is signed with a private key held by AWS. You can verify the signature using the publicly available key and recompute hashes to confirm the logs have not been altered, which directly addresses the need to ensure the API call history is trustworthy and tamper-evident.

The CloudTrail event shows eventName AuthorizeSecurityGroupIngress with request parameters that add a security group ingress rule. Specifically, it opens port 22 (SSH) to 0.0.0.0/0, meaning all IPv4 addresses on the internet can attempt SSH connections to the associated EC2 instance. This is a well-known misconfiguration that exposes administrative access externally and is the correct security finding to investigate.

CloudTrail’s event history is designed as a durable, tamper-evident record of account activity, which auditors can use as evidence for compliance controls. It captures management events for 90 days in the console and can deliver to S3 or CloudTrail Lake for long-term retention, enabling organizations to satisfy audit requirements across frameworks like SOC 2, PCI DSS, and HIPAA. This audit trail is a core reason CloudTrail is considered essential for compliance.

AWS Config continuously records the configuration of each S3 bucket and evaluates the recorded state against managed rules such as s3-bucket-server-side-encryption-enabled. When a bucket is noncompliant, Config can trigger Auto Remediation via a Systems Manager Automation document to append or modify the bucket's encryption configuration. This works on existing buckets in near-real time, and also on any new bucket created, making it a direct enforcement mechanism.

CloudTrail captures management-plane and (with data events) object-level API calls. Each event includes the IAM user, role, or federated user that made the request, along with source IP, access key, timestamp, and request/response details. For S3, enabling data events on the bucket records GetObject/PutObject with full caller identity, making it the definitive audit source for identifying which IAM principal performed an action.

Referencing the ALB's security group as the source in the instances' inbound rule allows traffic only from ENIs belonging to that group, and it tracks ALB IP changes automatically. This satisfies the requirement that only ALB traffic reaches the instances.

Enabling default encryption on the S3 bucket automatically applies server-side encryption to every object written to it. You can choose SSE-S3 (AES-256) or SSE-KMS (with a customer managed CMK), and S3 encrypts objects at rest without any client-side changes. Any PUT request that omits encryption headers receives the bucket's default encryption, ensuring a consistent security posture for all stored data.

AWS KMS is a fully managed service for creating and controlling the encryption keys used across AWS services, and it natively integrates with Amazon S3 through SSE-KMS. You can create a customer managed key, define key policies and grants, set automatic annual rotation, and control access via IAM policies and key conditions. With envelope encryption, KMS protects each S3 object with a unique data key that is encrypted by your KMS key, allowing you to centrally manage, monitor, and revoke the master key while still receiving CloudTrail logs for every decrypt operation.

CloudHSM provides a dedicated HSM, offloading encryption.

Amazon GuardDuty continuously analyses CloudTrail management events, VPC Flow Logs and DNS logs using threat intelligence to surface findings such as unauthorised API calls. It satisfies the real-time detection constraint, and its findings can trigger EventBridge rules that invoke Lambda to update network ACLs, delivering the automated IP blocking the team requires.

The IAM Credential Report is the purpose-built tool for this task because it generates a CSV containing every IAM user in the account along with password and access key metadata, including the last-used dates. By reviewing the 'password_last_used' and 'access_key_last_used' columns, you can immediately identify users who have never signed in or never used their keys. This report can also be refreshed programmatically via AWS CLI or the IAM console, making it the most direct audit mechanism.

CloudTrail can only write log files to an S3 bucket that already exists and is located in the same AWS Region as the trail. If the bucket was accidentally deleted, renamed, or created in another Region, every delivery attempt fails, and the trail's status shows a delivery error. Confirming this prerequisite is therefore the correct first troubleshooting step, because no policy or role change can compensate for a missing or misregioned destination.

The simulator's explicitDeny result for iam:DeleteUser can only be produced by a Deny statement within the policy. In IAM's evaluation logic, an explicit Deny always overrides any Allow, making the action undeniably forbidden regardless of other permissions. This matches the correct interpretation of the simulation output, as the policy visibly contains a statement that rejects DeleteUser.

CloudTrail log file integrity validation creates a SHA-256 hash of each log file, chains that hash to the previous file's hash, and signs the resulting digest with a private key. The public key is distributed by AWS, so you can independently verify both the signature and the hash chain to detect any modification, deletion, or reordering of log files. It is the only option listed that provides cryptographic proof of log integrity.

This rule set meets the requirement by allowing inbound HTTPS on 443 for public clients and providing the minimal outbound rules needed for stateful-like behavior in a stateless NACL. The outbound TCP 1024-65535 rule allows responses to return to clients' ephemeral source ports, while the outbound TCP 443 rule permits the instance to fetch software updates. Together they allow required traffic while blocking unnecessary outbound communication, aligning with least privilege and the scenario's goal.

Requiring server-side encryption via the 's3:x-amz-server-side-encryption' condition key is a valid access restriction because it makes the presence and value of the x-amz-server-side-encryption header a precondition for the S3 operation. For example, you can require that the header equals AES256 or aws:kms, which denies requests that do not carry an encryption header even if the principal otherwise has s3:PutObject permission. This condition key is evaluated per request, giving you fine-grained, attribute-based control that enforces encryption compliance on all uploads.

Enabling encryption at rest on the RDS instance protects data files and automated backups using AWS KMS-managed keys, addressing the at-rest requirement. Setting rds.force_ssl=1 in the DB parameter group configures the MySQL/PostgreSQL engine to accept only TLS/SSL-encrypted connections, forcing all clients to negotiate an encrypted transport. Applying this parameter group requires a reboot, and after that every connection—including from read replicas—must use SSL, thereby satisfying both at-rest and in-transit encryption.

Amazon GuardDuty continuously analyses CloudTrail management and data events, VPC Flow Logs and DNS logs using machine learning and threat intelligence to surface anomalous API activity. It satisfies the stem's detection requirement without agents or manual rule authoring, unlike CloudWatch alarms, which need explicit metric thresholds you define yourself.

Restoring a DB instance from an encrypted snapshot creates a new instance that is automatically encrypted using the KMS key that encrypted the snapshot. This process preserves the data while transferring encryption settings to the restored instance, making it a valid method for both new deployments and migrations from existing encrypted data. You may optionally choose a different customer-managed key during the restore, but encryption is guaranteed to be enabled.

SSE-S3 (Server-Side Encryption with Amazon S3-managed keys) encrypts each object using AES-256 with a unique key, and that key is then protected by a regularly rotated master key owned by S3. When enabled, S3 automatically encrypts data as it writes to disk and decrypts it transparently on retrieval, with no additional key management burden for the customer. This is a fully managed, low-overhead method for encrypting data at rest in S3.

AWS WAF is a managed Layer 7 web application firewall that you attach by associating a web access control list (ACL) with a supported resource, specifically an Application Load Balancer for regional HTTP/S requests or Amazon CloudFront for edge-based delivery. An ALB terminates HTTP/HTTPS and forwards requests to targets, giving WAF a point to inspect URI, headers, and body; CloudFront provides the same inspection at CloudFront edge locations before origin processing. This is the supported integration path, along with API Gateway and App Runner, so the correct target is an ALB or CloudFront.

Patch groups in Systems Manager Patch Manager are defined by tagging managed nodes with the key `Patch Group` (case-sensitive) and then associating that group to a patch baseline using `Register-PatchBaselineForPatchGroup`. This association is what directs Patch Manager to evaluate and apply the baseline, including approval rules and custom patches, to every instance in that group. Without the explicit patch-group-to-baseline registration, simply having a tag on instances does not change which baseline is applied; the baseline must be knowingly assigned to the group.

The correct approach is to add a bucket policy with a Deny effect for s3:DeleteObject that includes a Condition such as StringNotEquals on aws:PrincipalAccount with the management account's ID. This denies deletion for every principal that is not in the management account, while excluding the management account itself from the Deny so that its principals can delete. By using this resource-based policy and the aws:PrincipalAccount condition key, you enforce that only users or roles from the management account can delete objects from the S3 bucket.

The aws:PrincipalOrgID condition key is a global condition that checks the organization ID associated with the principal's account, allowing you to require that the principal comes from an account that is a member of a specified AWS organization. In a resource-based policy, it directly validates organizational membership for cross-account access, making it the appropriate choice for ensuring that only principals from your organization can access the resource.

AWS Config continuously evaluates bucket configurations against the s3-bucket-public-read-prohibited managed rule, which checks both bucket ACLs and bucket policies for public read access. When a violation is detected, an automatic remediation action invokes an AWS Systems Manager Automation runbook (e.g., AWS-DisableS3BucketPublicRead) to remove the public grant or apply a deny. This is a fully automated lifecycle: detect, remediate, and re-evaluate until compliant, without human intervention, making it the correct solution.

This is the correct permission needed to upload any object to S3, regardless of whether server-side encryption is enabled. When using SSE-S3, S3 automatically encrypts the object with a unique key that is itself wrapped by a master key managed by S3, all happening transparently in the service. The caller only needs the standard s3:PutObject permission; no separate KMS or encryption-specific permissions are required for the upload to succeed with encryption.

A metric filter in CloudWatch Logs inspects incoming log events and matches patterns such as { $.eventName = "StopInstances" }. Each matching event increments a custom metric (e.g., StopInstancesCount), which is what turns raw log data into a numeric measure that a CloudWatch alarm can monitor. Without this metric filter, CloudWatch Logs data remains unstructured and cannot directly trigger alerts.

GuardDuty multi-account architecture requires you to designate an administrator account (via AWS Organizations delegated administrator or invitation) that owns the GuardDuty detectors and manages all member accounts. The administrator account aggregates findings from every member account, giving you a single-pane-of-glass view and allowing you to configure threat lists and managed rules centrally. This designated administrator is the foundation for cross-account management and is mandatory for any multi-account GuardDuty setup.

CloudTrail delivers API activity to CloudWatch Logs, where a metric filter counts DeleteBucket events and drives an alarm. This satisfies the requirement to detect unauthorised delete calls, since CloudTrail alone records but does not alert.

LiME is a loadable kernel module designed specifically for Linux memory acquisition. Loading it on the target system grants direct access to the kernel's physical address space, allowing a full RAM image to be written to a file or over the network; unloading it restores the system to a usable state.

The AWSServiceRoleForRDS service-linked role is a predefined IAM role that gives RDS the ability to call AWS services, including KMS, on your behalf for tasks such as encrypting and decrypting database storage. When this role is missing, RDS cannot assume it to perform kms:Encrypt, kms:Decrypt, or kms:GenerateDataKey operations, causing failures when you create, modify, or start an encrypted instance. This is the root cause in this scenario; you can verify or create the role with the AWS CLI command aws iam create-service-linked-role --aws-service-name rds.amazonaws.com.

The AWS Config managed rule `s3-bucket-server-access-logging-enabled` can be configured with a `tag` parameter. When a tag is specified, the rule only evaluates S3 buckets that have that exact tag. If the engineer did not apply the required tag to all buckets, or if the rule was configured with a tag that does not match all buckets, some buckets will be excluded.

Enabling EBS encryption by default in the Region is the easiest and most reliable method because it instructs the EC2 service to always encrypt newly created volumes and snapshots at the storage layer. When enabled, every new EBS volume and every new snapshot is encrypted with your default AWS KMS key (either the aws/ebs managed key or a customer-managed key you designate). This setting applies to all volumes created in that Region, including root volumes launched from unencrypted AMIs, without requiring you to modify applications or remember to check an encryption box.

AWS CloudTrail is the native audit service that records every API call and user activity as CloudTrail event history. Each event includes the identity of the caller, source IP, time, request parameters, and response, allowing engineers to detect unauthorized API calls by analyzing management and data events. This event history can be delivered to an S3 bucket and queried with Athena, or streamed to CloudWatch Logs for real-time alerting.

The bucket policy includes a Deny statement with a Bool condition on aws:SecureTransport set to "false". This condition matches only when the request is made over plain HTTP, not TLS/SSL. Consequently, HTTP requests are explicitly denied, while HTTPS requests do not match the condition and therefore are not blocked by this statement. Any valid allow from another policy can therefore permit HTTPS access.

This principal ARN explicitly identifies the IAM role 'AllowedRole' in the account. When the role is assumed (by an EC2 instance, Lambda, or an STS AssumeRole call), the role's temporary credentials include the role's ARN as the principal, so the KMS key policy exactly matches it. This is the correct least-privilege configuration because no other IAM user or role can use the key unless the role allows it, and the key policy does not expose the key to the entire account. You could further restrict it by adding a condition like kms:ViaService to limit it to S3, but this is the best answer among the options.

The correct method is to filter CloudTrail management events for eventName='RunInstances' (eventSource='ec2.amazonaws.com') and match the target instance ID, which appears in the responseElements.instancesSet.items field because the ID is generated when the instance is created. Each event's userIdentity block contains the ARN of the IAM user or role, access key ID, session context, and source IP, giving a definitive audit answer. For large accounts, use Athena or CloudTrail Lake to query the logs by instance ID rather than manually browsing Event history.

Creating an IAM user with administrative privileges and using that user for day-to-day management reduces the exposure of the root user credentials, which is a core AWS account security best practice. This allows you to enforce MFA, assign permissions via IAM policies, rotate credentials, and audit actions through CloudTrail, none of which are possible with the root user in a least-privilege manner. While AWS now recommends using IAM Identity Center with roles for human access, an admin IAM user protected by MFA is still a valid baseline for root-user credential protection.

Enabling encryption at rest protects the database by encrypting data files in the underlying block storage, along with automated backups, snapshots, and read replicas, using an AWS KMS customer master key (AES-256). This satisfies compliance requirements such as PCI DSS or HIPAA and defends against theft of physical storage or unauthorized access to snapshots. Must be configured at instance creation time; to encrypt an existing unencrypted instance, you have to create an encrypted snapshot and restore from it.

Amazon GuardDuty is a continuous threat detection service that consumes AWS CloudTrail S3 data events, VPC flow logs, and DNS logs to identify suspicious S3 access, such as requests from unusual geographies, compromised credentials, or bucket exfiltration attempts. When a finding is generated, GuardDuty publishes it to Amazon CloudWatch Events (now part of Amazon EventBridge), enabling automated notification through SNS or invocation of Lambda for remediation. This end-to-end pipeline provides the real-time, actionable alerting required for S3 access anomalies.