AWS Certified Security Specialty (SCS-C03) Prep That Works

The immediate containment step for exposed access keys is todisable (deactivate) the compromised IAM access key(Option B). This prevents any further use of the leaked credentials, which is essential once secrets are publicly exposed. Creating a new key (Option D) may be part of recovery later, but it does not stop abuse of the already exposed key unless the exposed key is first deactivated.

To determine whether the credentials were used, you need evidence of access activity. Among the provided options, the best fit is generating and reviewing theIAM credential report(Option E). The report includes metadata such as access key status and “last used” style details that help triage whether the user’s credentials have been exercised recently. While deeper investigation would typically rely on CloudTrail “AccessKeyId” searches, the credential report is a quick AWS-native step aligned to the answer choices.

Option A is not correct: IAM Access Analyzer helps identify external access paths to resources and validate policies; it does not provide a definitive history of what a specific access key did. Option C is not a GuardDuty capability—GuardDuty generates findings; it does not “block” a specific access key. Therefore, deactivating the key and using credential reporting to assess recent usage best matches the requirements.

Amazon SQS is an AWS-managed service and does not operate within customer VPCs. Therefore, security groups and network ACLs cannot be used to control access to SQS, making options A and B invalid. According to AWS Certified Security – Specialty documentation, the recommended approach to securely access AWS services from within a VPC is throughinterface VPC endpoints (AWS PrivateLink).

By creatinginterface VPC endpoints for Amazon SQS, the company ensures that traffic to SQS stays within the AWS network and does not traverse the public internet. Adding anSQS resource policywith the aws:SourceVpce condition restricts access so that only requests originating from the specified VPC endpoint are allowed. Additionally, using the aws:PrincipalOrgId condition ensures that only principals belonging to the same AWS Organization can access the queue.

Option D introduces an external tool, increasing cost and compliance complexity, which directly violates the requirement to minimize investment outside AWS.

AWS documentation clearly identifiesVPC endpoints combined with IAM condition keysas a best practice for securing service access in multi-account environments.

AWS Certified Security – Specialty Official Study Guide

Amazon SQS Security Best Practices

AWS Organizations Documentation

AWS PrivateLink User Guide

AWS incident response best practices emphasizerapid containment, credential revocation, and threat detectionto minimize the blast radius of a compromise. According to the AWS Certified Security – Specialty Official Study Guide, when unauthorized resources such as an Amazon S3 bucket hosting malware are discovered, immediate action must be taken to stop further misuse of the account and to prevent recurrence.

Rotating or deleting all AWS access keys (Option D)is a critical containment step. If an IAM user has been compromised, any long-term credentials associated with that user must be revoked immediately to prevent continued unauthorized access. AWS guidance explicitly lists access key rotation or deletion as a first-response action for suspected credential compromise.

Deleting unrecognized or unauthorized resources (Option F)directly removes the malicious infrastructure that is being abused. In this case, deleting the unauthorized S3 bucket immediately stops malware distribution and reduces reputational and compliance impact.

Turning on Amazon GuardDuty (Option B)enables continuous threat detection by analyzing CloudTrail events, VPC Flow Logs, and DNS logs. GuardDuty can identify additional malicious activity, compromised credentials, or persistence mechanisms that the attacker may have established. AWS documentation recommends enabling GuardDuty during or immediately after an incident to detect ongoing or future threats.

Option A does not reduce the impact of the current compromise. Option C is overly disruptive and not recommended; credential rotation should be targeted. Option E is unnecessary because there is no indication that EBS-backed compute resources are involved.

AWS incident response guidance clearly prioritizescredential revocation, malicious resource removal, and threat detectionto minimize consequences.

AWS Certified Security – Specialty Official Study Guide

AWS Incident Response Best Practices

Amazon GuardDuty User Guide

AWS IAM Security Best Practices

The threat is client ID manipulation to break authorization boundaries. The strongest control is tobind the MQTT client identity to the authenticated device identity(the Thing) rather than trusting arbitrary client IDs provided by the client. Using theThing name as the client ID(Option A) removes ambiguity and makes the identifier predictable and tied to a registered identity.

On the authorization side, AWS IoT Core policies can use policy variables. Allowing iot:Connect only when the resource matches client/${iot:Connection.Thing.ThingName} (Option E) ensures the connection is permittedonlyif the client ID exactly equals the authenticated Thing name from the TLS certificate/Thing principal context. This prevents attackers from injecting special characters or choosing a different client ID to escalate access, because the policy evaluation ties the allowed client resource to the Thing identity, not the attacker-controlled string.

Option D is weaker because it effectively allows whatever client ID is presented (it matches the same value the client supplies), so it does not prevent crafted client IDs from being used. Option C is unrelated to the described MQTT connect authorization (and references an action not aligned with the scenario). Option B is an application-side check and can be bypassed by a malicious client; enforcement must be at AWS IoT Core policy level.

Comprehensive and Detailed 100to 150 words of Explanation From AWS Certified Security – Specialty topics:

Session Manager requires the target EC2 instance to be a managed node, which means Systems Manager Agent must be installed and running, and the instance profile must grant permissions for Systems Manager communication. In a private VPC with no internet connectivity, the instances need private connectivity to Systems Manager service endpoints through VPC interface endpoints. Depending on configuration, endpoints commonly include Systems Manager, EC2 messages, and Systems Manager messages; EC2 endpoint access can also be needed for related management operations. A NAT gateway would create internet-bound egress and conflicts with the private VPC requirement. A transit gateway does not provide AWS Systems Manager service connectivity by itself. Preventing SSH key pair creation is not required for Session Manager operation.

================

Comprehensive and Detailed 100to 150 words of Explanation From AWS Certified Security – Specialty topics:

AWS Backup uses backup plans to define backup frequency, lifecycle behavior, cold storage transition, and retention. For snapshot-based backups, AWS Backup supports retention periods from 1 day up to 100 years, or indefinitely if no retention is specified. Therefore, a backup plan with a 5-year retention period is the correct lifecycle-management mechanism. Tags alone do not enforce retention. The customer does not directly manage an S3 bucket that AWS Backup uses for RDS snapshots, so S3 versioning or S3 Lifecycle policies are not the correct control path. RDS native automated backups have shorter retention limits, but AWS Backup snapshot retention is managed through the AWS Backup plan and is the appropriate service-level mechanism for long-term retention.

================

Amazon S3 Block Public Access provides centralized controls to prevent public access through bucket policies and ACLs. AWS Certified Security – Specialty guidance recommends enabling Block Public Access to reduce accidental exposure and to enforce guardrails that override public grants. Enabling Block Public Access on the bucket removes current public exposure when combined with correcting policies/ACLs and prevents future misconfiguration. To ensure the bucket cannot be made public again, the security engineer must prevent principals from disabling Block Public Access. An SCP that denies s3:PutPublicAccessBlock prevents changes that would remove or weaken the PublicAccessBlock configuration, enforcing the guardrail across the OU or account. Options A and D do not directly address public exposure control. Option B denies object reads but does not ensure public access cannot be re-enabled; it also does not address the root misconfiguration pathways and could disrupt legitimate access patterns. Option C specifically combines the correct preventive control (PublicAccessBlock) with organizational enforcement to stop future reversal.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

Amazon S3 Block Public Access

AWS Organizations SCP Guardrails for S3 Controls

AWS WAF supportsWAF loggingas a dedicated feature that can deliver logs to destinations such as Amazon S3 (commonly via Kinesis Data Firehose). These logs contain rich request details (rule matches, action taken, headers, URI, source IP, etc.) that are essential for determining whether traffic spikes are due to application-layer attacks. For analysis with low operational overhead, storing logs inS3and querying them withAmazon Athenais a standard pattern. Usingpartition projectionfurther reduces administrative work by avoiding manual partition management and enabling efficient queries over time-based prefixes.

Options A and D incorrectly route WAF logs through CloudTrail; WAF request logs are not delivered “to a CloudTrail trail.” CloudTrail records AWS API activity, not per-request WAF inspection logs. Option B describes querying S3 data directly with OpenSearch using “partition projection,” which is an Athena/Glue concept; OpenSearch is typically used by ingesting data into an index (often via Firehose), not by directly querying S3 objects as a table in that manner.

Therefore, enabling WAF logs to S3 and analyzing them with Athena using partition projection is the correct solution.

Amazon S3 pre-signed URLs grant temporary access based on the permissions of the principal that generates them. AWS Certified Security – Specialty documentation explains that fine-grained authorization can be enforced by combining pre-signed URLs with IAM policy conditions.

By tagging each invoice object with a client identifier and adding a condition to the EC2 instance role policy using s3:ResourceTag/ClientId, the role can generate pre-signed URLs only for objects associated with a specific client. This ensures that each client can access only their own invoices, even though the URLs are temporary and unauthenticated.

Option A over-permissions clients. Option C is unnecessary because instance profiles already use temporary credentials. Option D violates AWS best practices by using long-term credentials.

AWS recommends resource tagging with IAM policy conditions for scalable, secure access control.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

Amazon S3 Pre-Signed URLs

IAM Policy Conditions and Resource Tags