SCS-C03 Practice Questions

The problem describes a misconfiguration where subnets intended to be private have a direct route to the internet gateway, making them public. To remediate this, instances in the private subnets need a way to access the internet for tasks like software updates without being directly exposed. This is the function of a NAT gateway.

For a resilient and cost-effective architecture, a NAT gateway should be provisioned in a public subnet within each Availability Zone (AZ). Then, the route tables associated with the private subnets must be modified. The default route (0.0.0.0/0) should be changed from the internet gateway to the NAT gateway located in the same AZ. This ensures private resources can initiate outbound traffic to the internet while remaining isolated from inbound connections.

B. A NAT gateway must be placed in a public subnet to have a route to the internet; placing it in a private subnet would render it non-functional.

C. Every VPC route table automatically includes a non-modifiable local route for the VPC CIDR range, so this action is both unnecessary and impossible.

E. Routing 0.0.0.0/0 to the internet gateway is the definition of a public subnet and describes the exact misconfiguration that needs to be corrected.

1. Amazon VPC User Guide, "NAT gateways": "To create a NAT gateway, you must specify the public subnet in which the NAT gateway should reside... You must also update the route table associated with one or more of your private subnets to point internet-bound traffic to the NAT gateway." This supports options A and D. The guide also states, "For Availability Zone independence, create a NAT gateway in each Availability Zone and configure your routing to ensure that resources use the NAT gateway in the same Availability Zone." This further validates the specifics of options A and D.

Source: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html (See sections: "NAT gateway basics" and "NAT gateway use cases").

2. Amazon VPC User Guide, "Route tables for your VPC": "Every route table contains a local route for communication within the VPC... This route is added by default to all route tables. You can't modify or remove it." This confirms that option C is incorrect. The guide also defines a public subnet as one with a route to an internet gateway, confirming that option E describes the problem, not the solution.

Source: https://docs.aws.amazon.com/vpc/latest/userguide/VPCRouteTables.html (See section: "Route table basics").

3. AWS Well-Architected Framework - Reliability Pillar: This framework emphasizes designing systems that withstand component failures. The recommendation to deploy NAT gateways in each AZ and route traffic to the local NAT gateway aligns with the principle of building highly available, fault-tolerant systems by avoiding cross-AZ dependencies, which could become single points of failure.

Source: https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-for-failure.html (See section: "Withstand component failures").

The most effective and non-disruptive first step in troubleshooting permission-related failures in AWS is to analyze the relevant logs. AWS CloudTrail records API calls made in an AWS account, including those initiated by AWS CloudFormation. By reviewing the CloudTrail event history for the failed deployment, the security engineer can identify the specific API call that was denied. The error message in the CloudTrail event will provide the exact reason for the failure, clarifying whether the denial was due to the IAM role's permissions or a restriction imposed by a Service Control Policy (SCP) attached to the Production OU. This diagnostic step provides precise data before any changes are made to the production environment.

B. Removing SCPs from a production environment, even temporarily, is a high-risk action that can expose the environment to unintended actions. It is not a recommended first step for diagnosis.

C. While the IAM role's permissions might be the issue, the fact that the deployment works in other OUs suggests an environmental difference, like an SCP. Checking logs first is more direct as it will pinpoint the exact failed API call.

D. Modifying production SCPs to match a non-production environment without understanding the root cause is poor security practice and could inadvertently weaken necessary production controls.

1. AWS CloudTrail User Guide: "You can use the information collected by CloudTrail to determine the request that was made, the IP address from which the request was made, who made the request, when it was made, and so on... For example, you can identify IAM permission errors by reviewing CloudTrail logs for failed API calls." (Source: AWS CloudTrail User Guide, "Logging IAM and AWS STS API calls with AWS CloudTrail").

2. AWS Organizations User Guide: "If a user or role has an IAM permission policy that grants access to an action that is also blocked by the applicable SCPs, the user or role is denied access to that action." This confirms that an SCP can cause an "insufficient IAM permissions" error even if the IAM role has the necessary Allow statement. (Source: AWS Organizations User Guide, "Service control policies (SCPs)", section "Effects of SCPs on permissions").

3. AWS CloudFormation User Guide: "Insufficient IAM permissions. The IAM role that you are using to create or update the stack doesn't have sufficient permissions... To troubleshoot, check the AWS CloudTrail logs for the specific API calls that are failing with an access denied error." (Source: AWS CloudFormation User Guide, "Troubleshooting AWS CloudFormation", section "Troubleshooting stack creation and update errors").

When changing the external identity provider (IdP) for AWS IAM Identity Center, the primary task is to update the identity source configuration. Since the new IdP may use different attribute names in its SAML assertion compared to the old one (even if both use the same underlying Active Directory), the attribute mappings within IAM Identity Center must be modified. These mappings tell IAM Identity Center how to interpret incoming user information, such as username and email, from the SAML assertion sent by the new IdP. This ensures that federated users are correctly identified and authorized.

A. Disabling users is a disruptive and incorrect step. Since the underlying directory is the same, the user identities persist; only the authentication source is changing.

C. IAM roles managed by IAM Identity Center trust the IAM Identity Center service principal, not the external IdP directly. This trust relationship does not need to be changed.

D. While correct clock synchronization (NTP) is a prerequisite for any SAML federation to function, it is a general operational requirement, not the specific configuration step for migrating between IdPs.

1. AWS IAM Identity Center User Guide, "Manage your identity source": This section details the process of configuring an external IdP. It states, "When you change your identity source, you must reconfigure the settings for that source. For example, if you change from one external IdP to another, you must provide the new IdP metadata and reconfigure attribute mappings." This directly supports updating the mappings as the core action.

2. AWS IAM Identity Center User Guide, "Attribute mappings": This page explains that you must configure attribute mappings in IAM Identity Center to match the attributes from your IdP. It explicitly lists attributes like Subject, email, and name that must be mapped from the IdP's assertion, confirming that this is a critical configuration step when connecting any IdP.

3. AWS IAM Identity Center User Guide, "How permission sets work": This documentation explains that IAM Identity Center creates IAM roles in AWS accounts and that the trust policy for these roles allows principals authenticated by IAM Identity Center to assume them. The trust is with IAM Identity Center, not the external IdP, which invalidates option C.

The most effective solution is to use an AWS WAF rate-based rule. This rule type is specifically designed to count requests from individual source IP addresses over a rolling five-minute period. By creating a web ACL with a rate-based rule, setting the threshold to 10,000, and associating it with the CloudFront distribution, you can automatically track and act on excessive requests. AWS WAF natively integrates with Amazon CloudWatch, publishing metrics for rule actions. A CloudWatch alarm can be configured to monitor the metric for this rule and, upon being triggered, send a notification to the designated Amazon SNS topic. This approach is direct, managed, and scalable.

A. CloudFront standard logs are not processed in real-time, and metric filters are not designed for aggregating counts per unique IP address efficiently.

B. VPC Flow Logs capture network-level traffic and would see CloudFront's IP, not the end-user's IP, making it unsuitable for this application-level requirement.

C. An ASN match rule blocks or allows traffic based on the Autonomous System Number of the source, not the request rate from an individual IP address.

1. AWS WAF Developer Guide, "Rate-based rule statement": This section states, "A rate-based rule tracks the rate of requests for each originating IP address... AWS WAF counts the requests from any single IP address in a trailing, continuously updated, 5-minute period." This directly confirms the mechanism for counting requests per IP over the required time frame.

2. AWS WAF Developer Guide, "Monitoring with Amazon CloudWatch": This page details the integration, explaining, "You can monitor your web ACLs and rules using CloudWatch, which collects raw data from AWS WAF and processes it into readable, near real-time metrics... You can set alarms that watch for certain thresholds". This supports using CloudWatch alarms on WAF metrics.

3. Amazon CloudWatch User Guide, "Using Amazon CloudWatch alarms": This guide describes how to create alarms and configure actions. The section on "Alarm actions" explicitly lists "Notify an Amazon SNS topic" as a possible action when an alarm changes state.

4. AWS WAF Developer Guide, "Associating or disassociating a web ACL with an AWS resource": This document confirms that a web ACL can be associated with an Amazon CloudFront distribution, which is a prerequisite for the solution.

This solution correctly implements the AWS best practice for secure, cross-account access. An IAM role is created in the company's production account (the trusting account), which will contain the necessary audit permissions. The role's trust policy correctly identifies the consultant agency's AWS account as the trusted principal, allowing users from that account to assume the role. Crucially, the trust policy can enforce the use of MFA by including a condition key (aws:MultiFactorAuthPresent). This approach provides temporary credentials via the sts:AssumeRole action, satisfying the requirement to forbid long-term credentials.

A. Creating IAM users directly in the production account generates long-term credentials (passwords and access keys), which is explicitly forbidden by the company's policy.

B. Amazon Cognito is a service for managing user identity for web and mobile applications, not for providing cross-account administrative access to the AWS environment.

C. This configuration is backward. The IAM role must be created in the account whose resources need to be accessed (the company's account), not in the consultant's account.

1. AWS Identity and Access Management User Guide, "IAM tutorial: Delegate access across AWS accounts using IAM roles": This document outlines the exact procedure described in the correct answer. It states, "You can use roles to delegate access to resources that are in different AWS accounts that you own... The trusting account owns the resources to be accessed, and the trusted account contains the users who need to access the resources." This confirms the role must be in the company's account.

2. AWS Identity and Access Management User Guide, "IAM JSON policy elements: Principal": This section explains how to specify a trusted principal in a role's trust policy. It shows that to trust an entire AWS account, you specify the account ARN in the Principal element, such as "Principal": { "AWS": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:root" }. This validates specifying the consultant agency's account as the principal.

3. AWS Identity and Access Management User Guide, "Configuring MFA-protected API access": This guide provides an example policy that demonstrates how to enforce MFA for role assumption. The policy includes a Condition block: "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}. This must be added to the role's trust policy to meet the MFA requirement.

4. AWS Identity and Access Management User Guide, "Security best practices in IAM": This guide states, "Require temporary credentials... For human users, require federation with an identity provider to access AWS using temporary credentials... We recommend that you require your human users to use temporary credentials to access AWS." This supports the use of roles (which provide temporary credentials) over IAM users (which have long-term credentials).

Amazon S3 Lifecycle configuration is the native, automated, and most efficient feature for managing object lifecycles, including expiration. A lifecycle rule can be configured to permanently delete objects a specified number of days after their creation. This directly enforces the policy to remove data older than 45 days without requiring custom code, complex orchestration, or additional costs associated with services like Lambda. It is the purpose-built, scalable solution provided by AWS for this exact use case.

B. Triggering a Lambda function on every object upload to scan and delete old data is highly inefficient, costly, and not a scalable approach for this task.

C. A scheduled Lambda function is more complex and costly than a native S3 Lifecycle rule and requires maintaining custom code to replicate a built-in S3 feature.

D. S3 Intelligent-Tiering is a storage class that automatically optimizes storage costs by moving objects between access tiers; it does not delete data based on age.

1. Amazon S3 User Guide, "Managing your storage lifecycle": This document explicitly describes using lifecycle rules for object expiration. It states, "You can define rules to schedule the deletion of objects after a specified period." The Expiration action is detailed as the mechanism to "specify when objects expire."

Source: AWS Documentation, Amazon S3 User Guide, Section: "Lifecycle configuration elements", Subsection: "Expiration action".

2. Amazon S3 User Guide, "Tutorial: Configuring a lifecycle rule for a versioning-suspended bucket": This tutorial provides a step-by-step example of setting up a lifecycle rule to permanently delete objects after a specific number of days, directly matching the question's requirement.

Source: AWS Documentation, Amazon S3 User Guide, Section: "Tutorials and examples", Subsection: "Example 1: Specifying an expiration action".

3. Amazon S3 User Guide, "Using S3 Intelligent-Tiering": This source clarifies the function of S3 Intelligent-Tiering. It states, "The S3 Intelligent-Tiering storage class is designed to optimize storage costs by automatically moving data to the most cost-effective access tier when access patterns change." This confirms it is for cost optimization, not data deletion.

Source: AWS Documentation, Amazon S3 User Guide, Section: "Amazon S3 storage classes".

Configuring the Amazon S3 Block Public Access feature at the AWS account level is the most effective and efficient method to meet the requirements. This single action establishes a security baseline that applies to all existing and future S3 buckets within the account. It prevents the application of public bucket policies or Access Control Lists (ACLs), directly mitigating the risk of unintended data exposure from misconfigurations. This "set-it-and-forget-it" approach provides a broad, preventative control with the least possible operational overhead, as it does not require configuration on a per-bucket or per-object basis.

B. Configure the S3 Block Public Access feature for all objects that are in the bucket.

This is incorrect because the Block Public Access feature is configured at the bucket or account level, not on individual objects.

C. Deactivate ACLs for objects that are in the bucket.

While disabling ACLs (using S3 Object Ownership) is a best practice for simplifying access management, it must be done per bucket and does not prevent a misconfigured bucket policy from making the bucket public.

D. Use AWS PrivateLink for Amazon S3 to access the bucket.

AWS PrivateLink secures the network path to S3 from a VPC but does not prevent the S3 bucket or its objects from being configured for public access.

1. AWS Documentation - Amazon S3 User Guide: "Blocking public access to your Amazon S3 storage". This guide states, "Amazon S3 Block Public Access provides settings for access points, buckets, and accounts to help you manage public access to Amazon S3 resources... We recommend that you turn on Block Public Access for all your accounts and buckets unless you know that you need public access." This confirms that the account-level setting is the most comprehensive and recommended approach.

Source: Amazon S3 User Guide, Section: "Blocking public access to your Amazon S3 storage".

2. AWS Documentation - Amazon S3 User Guide: "How S3 Block Public Access works". The documentation details the four settings that can be applied at the account or bucket level. Applying them at the account level ensures that "no bucket in your account can be made public," which directly addresses the question's requirements with minimal effort.

Source: Amazon S3 User Guide, Section: "How S3 Block Public Access works".

3. AWS Documentation - Amazon S3 User Guide: "Controlling ownership of objects and disabling ACLs for your bucket". This document explains that disabling ACLs simplifies access control but notes that access is then defined using resource-based policies. This does not inherently prevent a public bucket policy, unlike the Block Public Access feature.

Source: Amazon S3 User Guide, Section: "Controlling ownership of objects and disabling ACLs for your bucket".

4. AWS Documentation - Amazon S3 User Guide: "Accessing S3 using an interface endpoint (AWS PrivateLink)". This guide explains that PrivateLink provides private connectivity to S3. It does not mention anything about preventing public access configurations on the S3 bucket itself, as it is a network-level control.

Source: Amazon S3 User Guide, Section: "Accessing S3 using an interface endpoint (AWS PrivateLink)".

AWS Audit Manager is the purpose-built AWS service for simplifying how customers assess risk and compliance with regulations and industry standards. It provides prebuilt frameworks, such as PCI DSS v4.0, which map AWS resources to the requirements of the standard. Audit Manager automates the collection of evidence from AWS services and, crucially, allows users to upload and attach manual evidence. This directly addresses the compliance team's need to add their own documentation. Finally, it generates detailed assessment reports that consolidate both automated and manual evidence, fulfilling the core requirements of the question.

A. AWS Trusted Advisor provides best-practice recommendations but does not offer a structured framework for PCI DSS compliance, nor does it have a feature to add manual evidence or generate formal audit reports.

B. AWS Config with conformance packs is used for assessing resource configurations against best practices. While it provides evidence for automated checks, it is not designed for managing a full audit or incorporating manual evidence.

C. AWS Security Hub aggregates security findings and checks against standards like PCI DSS. However, its primary function is security posture management, not end-to-end audit management with manual evidence collection and report generation.

1. AWS Audit Manager User Guide - What Is AWS Audit Manager?: "AWS Audit Manager helps you to continuously audit your AWS usage to simplify how you assess risk and compliance with regulations and industry standards... You can also customize frameworks and controls in Audit Manager to meet your specific business requirements... Audit Manager collects evidence from two sources: automated and manual." This confirms its role in automated and manual evidence collection for compliance.

2. AWS Audit Manager User Guide - Standard frameworks: This page lists "Payment Card Industry Data Security Standard (PCI DSS) v4.0" as a supported standard framework, directly addressing the question's requirement.

3. AWS Audit Manager User Guide - Working with evidence: "When you create an assessment, Audit Manager automatically starts to collect evidence from your AWS accounts and services... In addition to the automated evidence that Audit Manager collects, you can also upload your own files as manual evidence." This explicitly confirms the capability to add manual evidence.

4. AWS Audit Manager User Guide - Generating assessment reports: "After you review the evidence in your assessment and make sure that it's ready for an audit, you can generate an assessment report. An assessment report is a finalized document that summarizes the relevant evidence that's collected for your audit." This confirms the reporting capability.

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).

This solution correctly addresses all requirements. Amazon Macie is the designated AWS service for discovering and classifying sensitive data within Amazon S3 buckets. By setting the security account as the delegated administrator for Macie within AWS Organizations, you can centrally manage and run sensitive data discovery jobs across all member accounts. Similarly, designating the security account as the delegated administrator for AWS Security Hub allows it to aggregate security findings from all accounts. The native integration between Macie and Security Hub ensures that all sensitive data findings are automatically published to and consolidated within the security account's Security Hub dashboard, providing a single location for visibility and management.

B: Amazon Inspector is a vulnerability management service for compute workloads (EC2, ECR, Lambda) and does not scan Amazon S3 buckets for sensitive data content.

C: This option is incorrect for two reasons: Amazon Inspector does not scan S3 buckets for sensitive data, and AWS Trusted Advisor is not the primary service for aggregating security findings.

D: While Amazon Macie is the correct service for discovery, AWS Trusted Advisor is not the appropriate tool for centralizing security findings; AWS Security Hub is designed for this purpose.

1. Amazon Macie Documentation - Managing multiple accounts: "With AWS Organizations, you can designate a specific member account to be the delegated Macie administrator for your organization... The delegated administrator can then enable and manage Macie for any or all of the other accounts in the organization."

Source: AWS Documentation, Amazon Macie User Guide, "Managing multiple accounts in Amazon Macie".

2. AWS Security Hub Documentation - Integrating Security Hub with Amazon Macie: "AWS Security Hub works with Amazon Macie to check for sensitive data in your Amazon Simple Storage Service (Amazon S3) buckets. Macie is a data security service that uses machine learning and pattern matching to discover and help protect your sensitive data... Macie publishes findings to Security Hub."

Source: AWS Documentation, AWS Security Hub User Guide, "Amazon Macie integration".

3. AWS Security Hub Documentation - Managing accounts with AWS Organizations: "We recommend that you use a dedicated account as the Security Hub administrator account for the organization. Using a dedicated account isolates the Security Hub configuration from your production workloads."

Source: AWS Documentation, AWS Security Hub User Guide, "Designating a Security Hub administrator account".

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." It scans Amazon EC2 instances, container images in Amazon ECR, and AWS Lambda functions.

Source: AWS Documentation, Amazon Inspector User Guide, "What is Amazon Inspector?".