Free Practice Questions for Amazon Web Services SCS-C03 Exam

AWS IAM supports identity federation by allowing external identity providers that use OpenID Connect (OIDC) to authenticate and assume IAM roles. According to the AWS Certified Security – Specialty documentation, IAM OIDC identity providers are the recommended approach for enabling third-party systems, such as external CI/CD pipelines or Git-based repositories, to securely obtain temporary AWS credentials without using long-term access keys.

By creating an OIDC identity provider in IAM and configuring the IAM role trust policy to trust the external IdP, the company enables secure, token-based authentication. The trust policy can include conditions that restrict which repositories, branches, or workflows are allowed to assume the role, enforcing least privilege. AWS Security Specialty guidance emphasizes that this method eliminates static credentials and relies on short-lived tokens issued by the OIDC provider.

Option B is incorrect because IAM Roles Anywhere is designed for workloads running outside AWS that use X.509 certificates, not OIDC. Option C is intended for workforce identity federation, not machine-to-machine authentication. Option D is invalid because AWS RAM does not provide identity federation or authentication capabilities.

This solution aligns with AWS best practices for secure, scalable, and low-overhead authentication for external workloads.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS IAM OIDC Identity Providers

AWS IAM Role Trust Policies

In AWS IAM Identity Center (formerly AWS Single Sign-On), users and groups do not automatically gain access to all accounts in an AWS Organization simply because the accounts exist. Access is explicitly granted by assigning aprincipal(user or group) to a specific AWS account along with apermission set. Permission sets define the IAM policies that are provisioned into the target account as IAM roles.

In this scenario, employees in theCloudActive Directory group can access nearly all AWS accounts, which confirms that AD Connector synchronization is functioning correctly, eliminating option B. The fact that Account A exists but is inaccessible strongly indicates that the required account assignment is missing. Without explicitly assigning the Cloud group to Account A with a valid permission set, IAM Identity Center will not provision the necessary IAM role, and users will not see or access the account in the AWS access portal.

Option A is incorrect because accounts do not need to be placed in an OU to be accessible through IAM Identity Center. Option D is incorrect because IAM permissions boundaries do not control access to entire accounts and are not applied at the account level to block IAM Identity Center access.

AWS Security Specialty documentation emphasizes thataccount assignments are mandatoryfor IAM Identity Center access, making option C the correct answer.

AWS CloudTrail provides a record of all API calls made in an AWS account, including calls initiated by AWS CloudFormation. According to the AWS Certified Security – Specialty Study Guide, CloudTrail is the primary source for troubleshooting authorization failures because it records denied actions and the policy type that caused the denial, including service control policies.

Reviewing CloudTrail logs allows a security engineer to identify which specific API calls failed during the CloudFormation deployment and whether the denial was caused by an SCP, an IAM policy, or a permission boundary. This evidence-based approach is the recommended first step before making any configuration changes.

Option B is unsafe and violates governance best practices by removing SCPs in production. Option C may be necessary later, but it does not identify whether SCPs are the root cause. Option D introduces unnecessary risk and bypasses the purpose of differentiated controls across OUs.

AWS documentation emphasizes observing and validating before modifying security controls, making CloudTrail log analysis the correct initial troubleshooting step.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS Organizations Service Control Policies

AWS CloudTrail Authorization Failure Analysis

AmazonMacieis the AWS service purpose-built todiscover and classify sensitive data in S3(PII, financial data, credentials, etc.) and produce findings that can be aggregated centrally. In a multi-account organization, the recommended centralized model is to designate adelegated administrator accountfor Macie so the security team can manage discovery across member accounts from one place.

To make the findings visible from a single location and integrate them with broader security visibility,AWS Security Hubprovides centralized aggregation of security findings across accounts and services. By also configuring the security account as thedelegated administrator for Security Hub, the company can aggregate findings across the organization. Macie integrates with Security Hub so that sensitive data discovery findings flow into Security Hub’s centralized view, giving the security team a single console and API surface to build an “inventory” of sensitive data locations and severity.

Inspector (options B and C) is focused on vulnerability management (EC2, ECR, and related scanning use cases), not sensitive data classification in S3. Trusted Advisor is not the primary destination for sensitive data discovery findings at organizational scale. Therefore, Macie + Security Hub with delegated administration in the security account is the correct solution.

Amazon Detective is specifically designed to help security teams investigate and visualize the root cause of security findings. According to AWS Certified Security – Specialty documentation, Detective automatically aggregates and correlates data from GuardDuty, CloudTrail, and VPC Flow Logs to provide interactive visualizations and timelines.

Detective enables investigators to pivot from GuardDuty findings to IAM roles, API calls, network traffic, and resource behavior. This makes it the most efficient tool for understanding how IAM roles were used during suspicious activity.

Amazon Inspector focuses on vulnerability assessment, not behavioral investigation. Security Hub aggregates findings but does not provide deep investigation graphs. Manual analysis with Athena requires significantly more effort.

AWS guidance explicitly recommends Amazon Detective for root cause analysis and visualization of security incidents.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

Amazon Detective Investigation Capabilities

AWS Threat Detection and Analysis

AWS Organizations service control policies (SCPs) are designed to enforce preventive guardrails across accounts without requiring application-level changes. According to the AWS Certified Security – Specialty documentation, SCPs can restrict specific API actions or require certain condition keys to enforce security standards centrally. AWS Lambda function URLs support two authentication modes: AWS_IAM and NONE. When the authentication type is set to NONE, the function URL becomes publicly accessible, which introduces a significant security risk in production environments.

By using an SCP that explicitly denies the lambda:CreateFunctionUrlConfig and lambda:UpdateFunctionUrlConfig actions when the lambda:FunctionUrlAuthType condition key equals NONE, the organization ensures that unauthenticated function URLs cannot be created or modified in production accounts. This enforcement occurs at the AWS Organizations level and applies automatically to all accounts within the specified organizational units (OUs). Developers are not required to change their workflows or add additional controls, satisfying the requirement of no additional developer effort.

Option A relates to browser-based access controls and does not provide authentication or authorization enforcement. Option B is not valid because AWS WAF cannot be attached directly to AWS Lambda function URLs. Option C is incorrect because SCPs do not grant permissions; they only limit permissions. AWS documentation clearly states that SCPs define maximum available permissions and are evaluated before IAM policies.

This approach aligns with AWS best practices for centralized governance, least privilege, and preventive security controls.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS Organizations Service Control Policies Documentation

AWS Lambda Security and Function URL Authentication Overview

AWS Firewall Manager applies and enforces AWS WAF protections based on thepolicy scopeyou define. In this scenario, the policy is explicitly scoped toonlythose resources that have the tag keyWAF-protectedwith a value oftrue. If the API Gateway REST API does not have that exact tag (correct key, correct value, correct spelling/case), Firewall Manager will treat the resource asout of scope. Out-of-scope resources are not evaluated for compliance and are not remediated, so the expected automatic association of the web ACL will never occur.

This is the most common reason for “nothing happens” when Firewall Manager is configured with tag-based scoping: the resource is missing the tag, the value is different (for example “True” vs “true”), or the tag was applied to a different resource than the one Firewall Manager evaluates.

Option A is incorrect because AWS WAF web ACLscanprotect API Gateway REST APIs (regional). Option C is not a blocker because a web ACL can generally be associated with multiple resources (within the supported scope). Option D is irrelevant to preventing association here; CloudFront uses a global scope and does not inherently block regional associations.

To achieve true separation of duties, the company needs a design whereS3 access alone is not sufficientto read plaintext data.SSE-KMS with a customer managed KMS keyprovides that separation because successful object reads require both: (1) S3 permissions to read the object and (2) permission to use the KMS key to decrypt it. This enables the operations team to manage bucket and object permissions while the security team independently controls key usage through theKMS key policy(and grants). If either team misconfigures only their part, the data is still protected: an overly permissive bucket policy won’t expose plaintext unless KMS decrypt is also allowed; similarly, KMS permissions alone are not sufficient without S3 read access.

Option B also adds a bucket policy requirement enforcingSSE-KMSso objects are consistently protected with the customer managed key. SSE-S3 options (A and C) do not provide the same separation because S3 manages the keys and decryption is not independently controlled by a separate team via KMS policies. Option D is invalid because SSE-C uses customer-provided keys that are supplied with each request and are not stored/managed in KMS as described. Therefore, SSE-KMS with customer managed keys plus restrictive key policy is the correct solution.

Amazon S3 Lifecycle rules provide anative, fully managed mechanismto automatically transition or delete objects based on their age. According to the AWS Certified Security – Specialty Official Study Guide, S3 Lifecycle policies are therecommended and most secure methodfor enforcing data retention requirements because they operate automatically, consistently, and without custom code.

By configuring a lifecycle rule to delete objects after 45 days, the company ensures that sensitive datasets are retained long enough to support the 30-day model training process while remaining compliant with the data retention policy. Lifecycle rules are enforced by Amazon S3 itself and apply uniformly to all objects in the bucket or to objects that match specific prefixes or tags.

Option B and Option C introduce unnecessary operational complexity and risk by relying on custom Lambda code and scheduling. These approaches are more error-prone, harder to audit, and less reliable than a built-in S3 capability. Option D is incorrect because S3 Intelligent-Tiering manages storage cost optimization and does not delete data.

AWS documentation explicitly states thatS3 Lifecycle rules are the standard control for enforcing retention and deletion policies, particularly for sensitive data stored at scale.

AWS Certified Security – Specialty Official Study Guide

Amazon S3 Lifecycle Configuration Documentation

AWS Data Protection Best Practices

AWS IAM Access Analyzer policy generation is specifically designed to help security engineers generate least-privilege IAM policies based on actual usage recorded in AWS CloudTrail. According to the AWS Certified Security – Specialty documentation, policy generation analyzes historical CloudTrail data to identify the exact API actions and resources that a role has accessed over a specified time period.

Because the role has been actively used for three months, there is sufficient CloudTrail data for IAM Access Analyzer to generate a refined customer managed policy automatically. This significantly reduces manual effort and eliminates the need to analyze logs or infer permissions. The generated policy can be reviewed and attached directly to the role, ensuring least privilege access with minimal engineering effort.

Option B only validates existing policies for security warnings and does not reduce permissions. Option C requires manual analysis of CloudWatch logs, which is time-consuming and error-prone. Option D does not analyze real usage and cannot generate role-specific least privilege policies.

AWS documentation explicitly recommends IAM Access Analyzer policy generation as the fastest and most accurate method to refine IAM permissions based on observed behavior.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS IAM Access Analyzer Policy Generation

AWS IAM Least Privilege Best Practices