Free SCS-C03 Practice Test Questions and Answers (2026)

To resolve deployment failures from inconsistent user permissions, the best practice is to use an AWS CloudFormation service role. This decouples the deployment's permissions from the user's permissions.

1. First, create an IAM service role with a trust policy that allows the CloudFormation service (cloudformation.amazonaws.com) to assume it (B).

2. To ensure the deployment is "MOST securely" executed, attach tightly scoped IAM policies to this role, granting it only the permissions needed to manage the stack's resources (C). This adheres to the principle of least privilege.

3. Finally, update the CloudFormation stack to use this service role's ARN during create or update operations (E). This ensures all deployments use the same, consistent, and securely-scoped set of permissions.

A. Create a composite principal service role.

This is not a standard AWS IAM term. A service role for CloudFormation requires a specific service principal, not a "composite" one.

D. Attach service ARNs in policy resources.

This is too vague. Policies should contain specific resource ARNs, but "attach scoped policies" (C) is the more accurate and comprehensive description of the security best practice.

F. Allow iam:PassRole to the service role.

This permission is granted to the IAM user or role initiating the deployment, not as a configuration on the service role itself. While necessary for the user, it's not a step in creating the secure role and stack configuration.

1. AWS CloudFormation User Guide, "AWS CloudFormation service roles": "To control the permissions that CloudFormation can exercise, you can use an AWS Identity and Access Management (IAM) service role. When you use a service role, AWS CloudFormation makes calls to other services on your behalf by using the permissions that are granted to the role... To associate a service role with a stack, you specify the role when you create, update, or change sets for the stack." This supports options B and E.

2. AWS IAM User Guide, "Creating a role to delegate permissions to an AWS service": This guide details the process of creating a service role. In the "Select trusted entity" step, you would choose "AWS service" and then "CloudFormation" as the use case, which automatically populates the trust policy with the cloudformation.amazonaws.com service principal. This supports option B.

3. AWS IAM User Guide, "IAM JSON policy elements: Resource": "Use the Resource element to specify the object or objects that the statement covers." and "For the principle of least privilege, you must grant permissions to specific resources." This documentation supports the practice of creating scoped policies (Option C) by specifying resource ARNs.

4. AWS IAM User Guide, "Granting a user permissions to pass a role to an AWS service": "To configure many AWS services, you must pass an IAM role to the service. This allows the service to assume the role later and perform actions on your behalf... To pass a role (and its permissions) to an AWS service, a user must have the iam:PassRole permission." This explains that PassRole is a permission for the user, not a configuration step for the role or stack itself.

Amazon S3 Lifecycle configuration rules provide the ability to automatically manage objects throughout their lifecycle. A lifecycle rule can be configured with an Expiration action to direct Amazon S3 to delete objects after a specified number of days since their creation. In this scenario, setting an expiration action for 3 days (72 hours) will ensure that objects are automatically and permanently removed from the bucket, fulfilling the security requirement to prevent them from residing in the bucket for longer than the specified period. This is the most direct and intended method for this use case.

A. S3 Versioning is for preserving, retrieving, and restoring every version of every object stored in a bucket. While lifecycle rules can expire noncurrent versions, versioning itself does not expire the current object.

C. S3 Intelligent-Tiering is a storage class designed to optimize storage costs by automatically moving data to the most cost-effective access tier. It does not inherently handle object expiration.

D. Presigned URLs grant temporary access to an S3 object for a specified duration. The expiration of the URL only revokes access via that URL; it does not delete the object from the S3 bucket.

1. AWS S3 Documentation, "Managing your storage lifecycle": "You can use S3 Lifecycle to define rules that control the lifecycle of your objects... For example, you can create a lifecycle rule that expires all objects with a specific prefix 3 days after creation." This directly supports the use of a lifecycle rule for expiration.

Source: AWS Documentation, Amazon S3 User Guide, "Managing your storage lifecycle".

2. AWS S3 Documentation, "Lifecycle action for your object": This document details the Expiration action. It states, "This action expires objects, and Amazon S3 deletes the expired objects on your behalf... You can specify expiration in the following ways: Number of days after object creation."

Source: AWS Documentation, Amazon S3 User Guide, "Lifecycle configuration elements", section on "Lifecycle action for your object".

3. AWS S3 Documentation, "Sharing objects using presigned URLs": "A presigned URL gives you access to the object identified in the URL... The presigned URLs are valid for the specified duration." This confirms that the URL expires, not the object itself.

Source: AWS Documentation, Amazon S3 User Guide, "Sharing objects using presigned URLs".

4. AWS S3 Documentation, "Using versioning in S3 buckets": "Use S3 Versioning to keep multiple versions of an object in the same bucket. For example, you can use versioning to preserve, retrieve, and restore every version of every object stored in your buckets." This clarifies that versioning's primary purpose is object preservation, not timed deletion.

Source: AWS Documentation, Amazon S3 User Guide, "Using versioning in S3 buckets".

Amazon Macie is the designated AWS service for discovering and protecting sensitive data in Amazon S3 using machine learning and pattern matching. To meet the requirement of managing this process across all accounts from a single security account, AWS Organizations is used. You can designate a delegated administrator account for Amazon Macie, allowing it to manage and view findings for all member accounts.

Similarly, AWS Security Hub is designed to aggregate, organize, and prioritize security findings from various AWS services. It also supports a delegated administrator model, enabling the central security account to view and manage findings, including those from Macie, from all accounts in the organization. This combination directly addresses the prompt's requirements.

B. Use Amazon Inspector with Security Hub.

Amazon Inspector is a vulnerability management service for compute workloads (e.g., EC2, ECR), not for discovering sensitive data within Amazon S3 buckets.

C. Use Inspector with Trusted Advisor.

Neither Inspector nor Trusted Advisor is designed for discovering sensitive data within S3 buckets. Trusted Advisor provides high-level best practice recommendations.

D. Use Macie with Trusted Advisor.

While Macie is the correct discovery tool, Trusted Advisor is not the appropriate service for centralizing and managing detailed security findings from other services like Security Hub is.

1. Amazon Macie Documentation - Managing multiple accounts in Amazon Macie: "To manage Macie for multiple accounts, you can integrate Macie with AWS Organizations. After you do this, you can designate a specific AWS account as the delegated Macie administrator account for your organization." (AWS Documentation, Amazon Macie User Guide, "Managing multiple accounts").

2. AWS Security Hub Documentation - Managing accounts with AWS Organizations: "We recommend that you use a centralized configuration to manage Security Hub for multiple accounts in AWS Organizations... You designate a Security Hub administrator account that can manage Security Hub for a set of accounts in your organization." (AWS Documentation, AWS Security Hub User Guide, "Managing accounts with AWS Organizations").

3. Amazon Macie Documentation - Integrating Amazon Macie with AWS Security Hub: "Amazon Macie integrates with AWS Security Hub to help you centralize and prioritize your security findings... When you enable the integration, Macie automatically begins publishing policy and sensitive data findings to Security Hub." (AWS Documentation, Amazon Macie User Guide, "Integrations", "Integrating with AWS Security Hub").

4. Amazon Inspector Documentation - What is Amazon Inspector?: "Amazon Inspector is a vulnerability management service that continuously scans your AWS workloads for software vulnerabilities and unintended network exposure." (AWS Documentation, Amazon Inspector User Guide, "What is Amazon Inspector?").

This option represents the best practice for both immediate mitigation and forensic investigation. Terminating the instance immediately stops all malicious activity, including outbound connections, providing the most effective containment. By ensuring the "Delete on Termination" flag is disabled for the attached EBS volumes, the data is preserved in its last state. A new, clean EC2 instance can then be launched in a separate, isolated environment (like another subnet) to conduct a forensically sound analysis by mounting the preserved EBS volumes as secondary drives. This prevents the compromised system from being active during the investigation, which could lead to evidence tampering or further compromise.

A. Logging into a compromised instance and installing tools is poor forensic practice. It alters the system's state, potentially destroying evidence and alerting the attacker.

B. This approach is overly complex and risky. It involves re-enabling network traffic to the compromised instance, which could allow the attack to resume or the attacker to cover their tracks.

D. AWS WAF is a web application firewall that operates at Layer 7. It cannot be attached directly to an EC2 instance to block arbitrary outbound TCP/IP connections to malicious addresses.

1. AWS Security Incident Response Guide (Whitepaper), Page 13, "Containment" and Page 14, "Data acquisition": The guide states, "A common containment strategy is to isolate the affected host from the network... For EC2 instances, you can change the security group to a previously prepared forensics security group... Alternatively, you can terminate the instance." For data acquisition, it recommends, "For EBS-backed instances, you can create a snapshot of the EBS volume... You can then create a new volume from the snapshot and attach it to your forensics instance." Option C aligns perfectly with this "terminate and analyze volume" strategy.

Source: AWS Security Incident Response Guide, August 2023.

2. AWS EC2 User Guide for Linux Instances, "Instance lifecycle" and "Amazon EBS volumes": The documentation details that when an instance is terminated, it is shut down and cannot be restarted. It also explains the DeleteOnTermination attribute for EBS volumes, which, when set to false, ensures the volume is preserved after the instance is terminated. This preserved volume can then be attached to another instance.

Source: AWS Documentation, Amazon EC2 User Guide for Linux Instances, Sections: "Terminate your instance" and "Amazon EBS volume types".

3. AWS Well-Architected Framework - Security Pillar, Page 55, "SEC 10: How do you detect and investigate security events?": This framework emphasizes the need for processes to investigate security events. The best practice is to "collect evidence in a forensically sound manner." Attaching a preserved EBS volume to a clean analysis instance, as described in option C, is a forensically sound method, whereas logging into the live system (Options A, D) is not.

Source: AWS Well-Architected Framework, Security Pillar, July 2023.

4. AWS WAF Developer Guide, "What is AWS WAF?": The official documentation states, "AWS WAF is a web application firewall that helps protect your web applications or APIs... You can deploy AWS WAF on Amazon CloudFront, Application Load Balancer, Amazon API Gateway, or AWS AppSync." This confirms WAF cannot be used to block arbitrary outbound traffic from an EC2 instance as suggested in option D.

Source: AWS WAF, API Gateway, AppSync, and CloudFront Developer Guide.

AWS KMS grants are the ideal mechanism for providing temporary, programmatic access to KMS keys. A grant is a policy instrument that allows an AWS principal (such as an IAM role for the application's software process) to use a KMS key without modifying the key policy. The security team can create a grant for the application team's process when access is needed and then revoke it when the access is no longer required. This is managed via API calls (CreateGrant, RevokeGrant), making it the solution with the least operational overhead for temporary and occasional access, while maintaining the security team's administrative control over the key policy.

A. Exporting key material is a significant security risk, bypasses KMS auditing and controls, and is only possible for keys with imported material. It represents extremely high operational and security overhead.

B. Editing the key policy for temporary access is operationally inefficient, error-prone, and can be subject to policy update propagation delays. Grants are specifically designed to avoid this overhead.

D. Creating a new key and importing material for each temporary access request is unnecessarily complex, costly, and introduces significant operational overhead compared to using a grant on an existing key.

1. AWS KMS Developer Guide, "Using grants in AWS KMS": "A grant is a policy instrument that allows AWS principals to use AWS KMS keys... They are often used for temporary permissions because you can create them, use their permissions, and revoke them without changing your key policies or IAM policies." This directly supports the use of grants for temporary access with low overhead.

2. AWS KMS Developer Guide, "Managing access to AWS KMS keys": This section details the different access control mechanisms. It explains that grants are a way to delegate permissions, often programmatically, which is distinct from the more static key policy. This aligns with the scenario of a software process needing access.

3. AWS KMS API Reference, "CreateGrant": The documentation for the CreateGrant API action states, "You can use a grant to allow an AWS principal to use a KMS key... without modifying the key policy." This confirms the programmatic and low-overhead nature of the solution.

4. AWS KMS API Reference, "RevokeGrant": The documentation for the RevokeGrant action shows how permissions can be programmatically and immediately removed, fulfilling the requirement for temporary access. This is more efficient than reverting a policy change.

AWS CloudTrail Lake is a managed security and audit data lake designed specifically for this use case. It allows for the aggregation, immutable storage, and analysis of activity data. It meets all requirements cost-effectively: it can capture data events, retain them for up to 10 years (3650 days), and the data stored is immutable by design. It includes a SQL-based query engine for complex analysis and integrated dashboards for visualization. As a single, serverless service, it eliminates the operational overhead and cost of managing separate storage, processing, and visualization services, making it the most cost-effective solution.

B. The CloudTrail Event History feature only retains events for the last 90 days, which does not meet the 7-year retention requirement.

C. This solution is technically viable but not the most cost-effective. A persistent Amazon EMR cluster incurs continuous costs, and managing a multi-service pipeline adds significant operational overhead.

D. This architecture is more complex and costly than CloudTrail Lake. It involves data transfer costs and the continuous expense of an Amazon OpenSearch Service domain, even with cold storage.

1. AWS CloudTrail User Guide, "Working with AWS CloudTrail Lake": "CloudTrail Lake event data stores are immutable. This means that events can't be changed after they're ingested." This document also states, "You can configure your event data store to keep your event data for up to 3,650 days (about 10 years)."

2. AWS CloudTrail User Guide, "Querying with AWS CloudTrail Lake": "You can run SQL-based queries on your events in the CloudTrail Lake." This confirms the capability for complex queries.

3. AWS CloudTrail User Guide, "Create and manage dashboards in AWS CloudTrail Lake": This section details the integrated visualization capabilities, stating "You can create dashboards to visualize the data in your event data stores."

4. AWS CloudTrail User Guide, "Viewing events with CloudTrail Event history": "Event history is limited to the past 90 days of events in an AWS Region." This confirms that option B is incorrect due to the retention limit.

5. AWS CloudTrail Pricing: The pricing model for CloudTrail Lake is pay-as-you-go for ingestion and query scanning, which is typically more cost-effective for this use case than provisioning and managing persistent clusters like EMR (Option C) or OpenSearch (Option D).

The Lambda function, running within a VPC with no internet access, cannot reach the public AWS Secrets Manager endpoint. The most secure method to enable this communication is by creating an interface VPC endpoint for Secrets Manager. This endpoint, powered by AWS PrivateLink, creates an Elastic Network Interface (ENI) with a private IP address inside the VPC. All traffic from the Lambda function to the Secrets Manager service is then routed securely through this private endpoint, remaining entirely within the AWS network and never traversing the public internet. This approach maintains the security posture of the isolated VPC.

A. A NAT gateway requires an internet gateway and routes traffic over the public internet, which is less secure than using a private endpoint.

B. Gateway VPC endpoints are a different technology and are only supported for Amazon S3 and Amazon DynamoDB, not for AWS Secrets Manager.

D. An internet gateway provides direct, two-way internet access, which is the least secure option and contradicts the requirement of a private, isolated VPC.

1. AWS Secrets Manager User Guide, "Use AWS Secrets Manager with VPC endpoints": "To allow your Lambda rotation function to access Secrets Manager and the database or service without that traffic leaving the Amazon network, we recommend you configure interface VPC endpoints. Interface endpoints send traffic to AWS services using AWS PrivateLink." This directly confirms that an interface endpoint is the recommended and secure solution.

2. Amazon VPC User Guide, "Interface VPC endpoints (AWS PrivateLink)": This document lists the AWS services available through interface endpoints, which includes AWS Secrets Manager. It states, "An interface endpoint is an elastic network interface with a private IP address that serves as an entry point for traffic destined to a supported AWS service..."

3. Amazon VPC User Guide, "Gateway VPC endpoints": This official documentation explicitly states, "A gateway endpoint is a gateway that you specify as a target for a route in your route table for traffic destined to a supported AWS service. The following AWS services are supported: Amazon S3, DynamoDB." This confirms that a gateway endpoint cannot be used for Secrets Manager.

4. AWS Lambda Developer Guide, "Configuring VPC access for a Lambda function": "When you connect a function to a VPC, it doesn't have access to the internet unless your VPC provides it... To grant your function internet access, you can configure a NAT gateway... To access AWS services without using a NAT gateway, you can configure an interface VPC endpoint." This explains the networking context and presents the interface endpoint as the secure alternative to a NAT gateway.

Amazon GuardDuty is a managed threat detection service that continuously monitors for malicious activity and unauthorized behavior. It can be centrally managed across hundreds of AWS accounts by designating a GuardDuty administrator account, typically through integration with AWS Organizations. This approach provides centralized visibility and management of security findings from all member accounts. GuardDuty automatically analyzes various data sources, including AWS CloudTrail event logs, VPC Flow Logs, and DNS logs, using machine learning and threat intelligence to identify threats. This fully managed solution requires minimal setup and maintenance, directly addressing the need for automatic detection with the least operational effort.

B. Centralize CloudWatch logs and use Inspector.

Amazon Inspector is a vulnerability management service for workloads like EC2 instances, not a real-time threat detection service for logs.

C. Centralize CloudTrail logs and query with Athena.

This solution is not automatic; it requires security analysts to manually write and run queries in Amazon Athena to search for threats, which is high operational effort.

D. Stream logs to Kinesis and process with Lambda.

This requires building and maintaining a custom detection solution using AWS Lambda, which represents the highest operational effort among the choices.

1. Amazon GuardDuty Documentation - Managing GuardDuty accounts with AWS Organizations: "To simplify the management of your multi-account environment, we recommend that you use our integration with AWS Organizations... The delegated GuardDuty administrator account can enable and manage GuardDuty for all accounts in the organization." This confirms the centralized management and low-effort scaling capability.

2. Amazon GuardDuty Documentation - How Amazon GuardDuty works: "GuardDuty is a regional security monitoring service that helps you identify and prioritize potential threats... GuardDuty processes data from multiple AWS sources, such as AWS CloudTrail event logs, Amazon VPC Flow Logs, and DNS logs." This highlights its automatic, log-based detection capabilities.

3. Amazon Inspector Documentation - What is Amazon Inspector?: "Amazon Inspector is a vulnerability management service that continuously scans your AWS workloads for software vulnerabilities and unintended network exposure." This clarifies that Inspector's purpose is vulnerability scanning, not log analysis for threat detection.

4. AWS Documentation - Querying AWS CloudTrail logs: This page details the process of setting up tables in the AWS Glue Data Catalog and using Amazon Athena to run standard SQL queries on CloudTrail logs stored in S3. This process demonstrates the manual, query-based nature of the solution, contrasting with GuardDuty's automatic detection.

A Network Load Balancer (NLB) operates at the transport layer (Layer 4) and is designed for ultra-low latency and high throughput, making it ideal for volatile traffic patterns. By configuring a TCP listener, the NLB passes the encrypted TLS traffic directly to the backend ECS containers without decrypting it. This "pass-through" mechanism ensures a true end-to-end encryption tunnel is established between the client and the container. The container itself is responsible for TLS termination. This approach minimizes latency and computational overhead on the load balancer, providing the highest scalability and performance while maintaining end-to-end security.

A. Terminating TLS at the NLB breaks end-to-end encryption, as traffic is decrypted and then re-encrypted. This also adds latency compared to a simple pass-through configuration.

B. An Application Load Balancer (ALB) operates at Layer 7, which inherently has higher latency than a Layer 4 NLB. Terminating TLS at the ALB also breaks true end-to-end encryption.

D. Amazon Route 53 provides DNS-level routing, not connection-based load balancing. It is less effective at handling rapid changes in target health and distributing traffic for volatile workloads compared to an NLB.

1. AWS Documentation, Elastic Load Balancing User Guide, "What is a Network Load Balancer?": "A Network Load Balancer functions at the fourth layer of the Open Systems Interconnection (OSI) model... It is capable of handling millions of requests per second while maintaining ultra-low latencies." This supports the scalability and low-latency claims.

2. AWS Documentation, Elastic Load Balancing User Guide, "Listeners for your Network Load Balancers": Under the "TCP listeners" section, it states, "When you use a TCP listener... the load balancer passes the request through to the targets without modification. The TCP connection is terminated by the targets." This confirms the pass-through capability for end-to-end encryption.

3. AWS Documentation, Amazon ECS Developer Guide, "Service load balancing": "We recommend that you use a Network Load Balancer for TCP or UDP traffic load balancing, and for use cases that require high performance." This directly recommends NLB for high-performance ECS workloads.

4. AWS Documentation, Elastic Load Balancing User Guide, "Product comparisons for Elastic Load Balancing": The feature comparison table highlights that the Network Load Balancer is "Optimized for volatile workloads and ultra-low latency," while the Application Load Balancer is for "Advanced request-based routing." This reinforces that NLB is the superior choice for the stated requirements.

Amazon Inspector is the dedicated AWS vulnerability management service designed to scan workloads. It provides two key features that directly address the requirements. First, Amazon Inspector enhanced scanning for Amazon ECR automatically scans container images for both operating system and programming language package vulnerabilities. Second, Amazon Inspector Lambda code scanning specifically analyzes the custom application code within Lambda functions to identify code security vulnerabilities, such as injection flaws or data leaks. This combination provides comprehensive vulnerability coverage for both the container images and the Lambda function code as requested.

A. Amazon GuardDuty is a threat detection service, not a vulnerability scanner. It does not perform static scanning of ECR images or Lambda code for vulnerabilities.

B. GuardDuty's Runtime Monitoring and Lambda Protection features detect threats and anomalies during execution, not by scanning the code or container images for pre-existing vulnerabilities at rest.

D. AWS Security Hub is a security posture management service that aggregates findings from other services like Amazon Inspector. It does not perform the scanning itself.

1. Amazon Inspector User Guide - Scanning Lambda functions with Amazon Inspector: "Amazon Inspector scans your AWS Lambda functions and Lambda layers for application package vulnerabilities... In addition to scanning for package vulnerabilities, Amazon Inspector also scans your Lambda functions for code vulnerabilities. Amazon Inspector Lambda code scanning scans the custom application code within your Lambda functions and layers for code vulnerabilities based on detectors from Amazon CodeGuru Detector Library and security best practices."

2. Amazon Inspector User Guide - Scanning Amazon ECR container images with Amazon Inspector: "Amazon Inspector integrates with Amazon ECR to scan container images for vulnerabilities... Enhanced scanning provides both operating system and programming language package vulnerability scanning for your container images."

3. Amazon GuardDuty User Guide - GuardDuty Lambda Protection: "GuardDuty Lambda Protection is a feature in Amazon GuardDuty that monitors the AWS Lambda function executions in your AWS account for potential security threats." (This confirms its focus is on runtime threat detection, not static vulnerability scanning).

4. AWS Security Hub User Guide - What is AWS Security Hub?: "Security Hub collects security data from across AWS accounts, services, and supported third-party partner products and helps you analyze your security trends and identify the highest priority security issues." (This confirms its role as an aggregator of findings, not a scanner).

AWS Systems Manager Session Manager provides secure, auditable, and managed instance access without needing to open inbound ports, manage SSH keys, or maintain bastion hosts. It meets all the specified requirements:

1. No exposed management ports: Session Manager uses the SSM Agent, which communicates with the AWS endpoint over an outbound HTTPS (port 443) connection. This eliminates the need to open inbound ports like SSH (22).

2. Full session logging: Session Manager can be configured to log all session activity, including every command and its output, to Amazon CloudWatch Logs or an Amazon S3 bucket, satisfying the compliance need for full logging.

3. Authentication through IAM Identity Center: Access to start a session is controlled by IAM policies. These policies can be attached to an IAM role within an IAM Identity Center permission set, allowing for centralized authentication and authorization.

A. The EC2 serial console is primarily for troubleshooting boot, network, or startup issues and is not intended for full, interactive shell sessions. Its logging is less comprehensive for auditing interactive commands.

B. EC2 Instance Connect requires the instance's security group to allow inbound SSH traffic (port 22) from the EC2 Instance Connect service, which violates the "no exposed management ports" requirement. It also lacks native session logging.

D. This approach explicitly opens remote access ports, which directly violates the core requirement of having no exposed management ports. It is an anti-pattern when a more secure option like Session Manager exists.

1. AWS Systems Manager User Guide, "AWS Systems Manager Session Manager": "Session Manager provides secure and auditable instance management without the need to open inbound ports, maintain bastion hosts, or manage SSH keys." It also states, "You can audit session activity in your AWS account using AWS CloudTrail. You can also log session data to Amazon S3 or Amazon CloudWatch Logs."

2. AWS Systems Manager User Guide, "Setting up Session Manager": Step 2 of the setup process details creating an instance profile with permissions for the SSM Agent. Step 4 covers granting IAM users session permissions, which is the mechanism used by IAM Identity Center permission sets.

3. AWS Security Blog, "How to use IAM Identity Center to provide access to your AWS Systems Manager tools": This blog post outlines the exact pattern described in the correct answer, stating, "You can use IAM Identity Center to provide your users with access to AWS Systems Manager tools, such as Session Manager... This allows you to provide your users with secure access to your instances without having to manage individual SSH keys."

4. Amazon EC2 User Guide for Linux Instances, "Connect to your Linux instance with EC2 Instance Connect": Under "Prerequisites," the documentation states, "The security group attached to your instance must have an inbound rule that allows SSH traffic (TCP port 22) from your IP address or from the IP address range for the AWS EC2 Instance Connect service." This confirms the need for an open port.

This solution correctly addresses all requirements. AWS CloudFormation StackSets with service-managed permissions are designed to deploy resources across an AWS Organization. Enabling automatic deployment ensures that the stack is provisioned in all existing and future member accounts. By configuring a delegated administrator for AWS CloudFormation, the company can manage these StackSets from a designated member account instead of the management account. This adheres to the security best practice of minimizing the use of the management account, fulfilling the principle of least privilege for routine operational tasks.

A. This approach is incorrect because it requires manual intervention to add new accounts, failing the automation requirement. It also unnecessarily uses the management account for a task that can be delegated.

C. While Systems Manager can deploy resources and supports delegated administration, AWS CloudFormation StackSets are the purpose-built, more direct, and idiomatic service for provisioning infrastructure from templates across an organization.

D. This solution fails because it uses the management account, violating the principle of least privilege. Additionally, sharing a runbook does not automatically deploy resources to new accounts without a separate triggering mechanism.

1. AWS CloudFormation User Guide: The section "Register a delegated administrator" states, "You can register a delegated administrator account to create and manage stack sets with service-managed permissions for your organization. By registering a delegated administrator, you can create and manage stack sets from the delegated administrator account." This directly supports using a delegated administrator.

Source: AWS CloudFormation User Guide, "Working with AWS CloudFormation StackSets," section "Register a delegated administrator."

2. AWS CloudFormation User Guide: The section on creating stack sets with service-managed permissions explains the auto-deployment feature. "When you enable auto-deployment, stack instances are automatically deployed to an account when it is added to a target organization or OU." This confirms the capability to deploy to future accounts automatically.

Source: AWS CloudFormation User Guide, "Create a stack set with service-managed permissions," section "Auto-deployment."

3. AWS Organizations User Guide: The guide on best practices for the management account explicitly recommends delegating tasks. "To help you follow this best practice, AWS has created the delegated administrator feature... you can delegate administrative tasks for a specific AWS service to a designated member account."

Source: AWS Organizations User Guide, "Best practices for the management account."

4. AWS Organizations User Guide: The documentation lists services that can be integrated with Organizations, including AWS CloudFormation, which can be registered as a delegated administrator.

Source: AWS Organizations User Guide, "AWS services that you can use with AWS Organizations," section "Services that support delegated administrator."

The solution requires two actions: immediate remediation and long-term prevention. First, enabling Amazon S3 Block Public Access on the bucket or account level immediately removes all forms of public access. This feature overrides any conflicting bucket policies or Access Control Lists (ACLs). Second, to ensure this setting cannot be reversed, a Service Control Policy (SCP) must be applied through AWS Organizations. By creating an SCP with a Deny statement for the s3:PutPublicAccessBlock action and attaching it to the relevant account, you prevent any IAM principal (including the root user) within that account from modifying the Block Public Access configuration. This combination effectively meets both requirements.

A. KMS encryption protects data at rest but does not control network access. Denying s3:GetObject via SCP would block all read access, not just public access.

B. While enabling Block Public Access is correct, denying s3:GetObject via SCP is an incorrect preventive measure as it blocks all object retrieval, which is overly restrictive.

D. Object Lock is a WORM (Write-Once, Read-Many) feature for data immutability and retention; it is not related to managing public access permissions.

1. AWS S3 Developer Guide, "Blocking public access to your Amazon S3 storage": This document explains that S3 Block Public Access provides settings to manage public access to S3 resources. It states, "Amazon S3 Block Public Access can override ACLs and bucket policies so that you can enforce uniform limits on public access to these resources." (See section: How Amazon S3 Block Public Access works).

2. AWS Organizations User Guide, "Service control policies (SCPs)": This guide details how SCPs act as a guardrail to control permissions in an organization. It clarifies, "SCPs are JSON policies that specify the maximum permissions for an organization or organizational unit (OU)... SCPs limit permissions for IAM users and roles in member accounts, including the member account's root user." (See section: Introduction to SCPs).

3. AWS IAM User Guide, "Actions, resources, and condition keys for Amazon S3": This documentation lists all IAM actions for S3. The s3:PutPublicAccessBlock action is defined as granting permission to create or modify the PublicAccessBlock configuration for an account or a bucket, confirming it is the correct action to deny for prevention. (See the Action summary table for Amazon S3).

4. AWS S3 Developer Guide, "Using S3 Object Lock": This source describes Object Lock as a feature to "store objects using a write-once-read-many (WORM) model," which is unrelated to controlling public access. (See section: How S3 Object Lock works).

Amazon Inspector is a vulnerability management service that continuously scans AWS workloads. A specific feature, Amazon Inspector Lambda scanning, is designed to identify software vulnerabilities in Lambda functions and associated layers. It performs two types of scans: one for vulnerabilities in application package dependencies (e.g., libraries) and another for code vulnerabilities within the function's custom code, directly addressing the requirement to scan for code vulnerabilities. This is an automated, continuous process once enabled.

A. Use Amazon Macie.

Macie is a data security service for discovering and protecting sensitive data (like PII) stored in Amazon S3, not for scanning Lambda function code for vulnerabilities.

C. Use GuardDuty and Security Hub.

GuardDuty is a threat detection service, and Security Hub aggregates security findings. Neither service performs static code analysis or scans Lambda functions for code vulnerabilities.

D. Use GuardDuty Lambda Protection.

This GuardDuty feature detects runtime threats and anomalous behavior in Lambda functions, such as malicious invocations, but it does not scan the function's code for vulnerabilities.

1. AWS Documentation: Amazon Inspector User Guide. "Scanning AWS Lambda functions with Amazon Inspector." This section states, "When you activate Lambda scanning, Amazon Inspector automatically discovers all of your Lambda functions... and immediately starts scanning them for vulnerabilities... Amazon Inspector scans Lambda functions for two types of vulnerabilities: Package vulnerabilities... [and] Code vulnerabilities."

2. AWS Documentation: Amazon Inspector User Guide. "Amazon Inspector scans for code vulnerabilities." This page details how Inspector uses automated reasoning and machine learning to detect code vulnerabilities in Lambda functions, covering categories like injection flaws and data leaks.

3. AWS Documentation: Amazon Macie User Guide. "What is Amazon Macie?" The first sentence clarifies its purpose: "Amazon Macie is a data security service that discovers sensitive data by using machine learning and pattern matching."

4. AWS Documentation: Amazon GuardDuty User Guide. "Lambda Protection in GuardDuty." This document explains, "GuardDuty Lambda Protection is a feature in Amazon GuardDuty that monitors AWS CloudTrail management events and VPC Flow Logs to detect threats against your Lambda functions." This confirms its focus is on runtime threat detection, not static code scanning.

AWS Config is the primary service for assessing, auditing, and evaluating the configurations of AWS resources. It continuously monitors and records your AWS resource configurations and allows you to automate the evaluation of recorded configurations against desired configurations. For this scenario, AWS Config provides managed rules that can specifically check Amazon Aurora instances for compliance with the stated security requirements. These rules include checks for public accessibility (rds-instance-public-access-check), storage encryption (rds-storage-encrypted), deletion protection (rds-instance-deletion-protection-enabled), and log exports (aurora-mysql-log-exports-enabled), providing the required continuous monitoring and real-time visibility into the compliance status.

A. Use AWS Audit Manager with a custom framework.

AWS Audit Manager is designed for collecting evidence for audits, not for real-time configuration monitoring and alerting. It often uses AWS Config as an evidence source.

C. Use AWS Security Hub configuration policies.

AWS Security Hub aggregates security findings and uses AWS Config rules for many of its checks. AWS Config is the foundational service that performs the actual configuration evaluation.

D. Use EventBridge and Lambda with custom metrics.

This is a custom-built solution that requires significant development and maintenance effort, whereas AWS Config provides a managed, out-of-the-box solution for this exact purpose.

---

1. AWS Config Documentation - rds-storage-encrypted: "Checks whether storage encryption is enabled for your Amazon Relational Database Service (Amazon RDS) DB instances."

Source: AWS Config Developer Guide, "List of AWS Config Managed Rules", rds-storage-encrypted.

2. AWS Config Documentation - rds-instance-deletion-protection-enabled: "Checks if an Amazon Relational Database Service (Amazon RDS) instance has deletion protection enabled."

Source: AWS Config Developer Guide, "List of AWS Config Managed Rules", rds-instance-deletion-protection-enabled.

3. AWS Config Documentation - rds-instance-public-access-check: "Checks whether the Amazon Relational Database Service (RDS) instances are not publicly accessible."

Source: AWS Config Developer Guide, "List of AWS Config Managed Rules", rds-instance-public-access-check.

4. AWS Config Documentation - aurora-mysql-log-exports-enabled: "Checks if an Amazon Aurora MySQL DB cluster has the specified log types exported to Amazon CloudWatch Logs." (The specified log types can include 'audit').

Source: AWS Config Developer Guide, "List of AWS Config Managed Rules", aurora-mysql-log-exports-enabled.

5. AWS Config Documentation - What Is AWS Config?: "AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. Config continuously monitors and records your AWS resource configurations and allows you to automate the evaluation of recorded configurations against desired configurations."

Source: AWS Config Developer Guide, "What Is AWS Config?".