SCS-C03 Practice Exam — SCS-C03：Security - Specialty

The core issue in the scenario is that the existing S3 bucket policy is configured with a resource element that only targets the S3 bucket itself, not the individual objects stored inside the bucket. Reading S3 objects requires object-level permissions, which rely on a resource pattern that includes the /* suffix to reference all objects in the bucket. Option C modifies the resource element to match the required object-level ARN format, which grants the Lambda function the necessary access to read objects in the bucket, resolving the error. This aligns with SCS-C03 domain objectives for identity and access management, specifically configuring resource-based policies for AWS services. Option Analysis: A. Incorrect. The problem does not stem from an incorrect principal or misconfigured condition element. Even if the principal is correctly set to the Lambda function's execution role, a policy without the correct object-level resource ARN will not grant access to read bucket objects. Removing the condition and changing the principal does not address the root cause of missing object-level resource access. B. Incorrect. The action element for reading S3 objects (s3:GetObject) is already correctly configured in the existing policy, as the error occurs specifically when attempting to read objects, not due to a missing or incorrect allowed action. Modifying the action element does not fix the resource mismatch that is blocking access. C. Correct. S3 bucket policies use distinct ARN formats for bucket-level and object-level resources. The base bucket ARN (arn:aws:s3:::DOC-EXAMPLE-BUCKET) only applies to bucket-level actions such as s3:ListBucket. To grant access to read objects, the resource must include the /* suffix to target all objects in the bucket, which is exactly what this option implements. This directly addresses the access error the Lambda function is encountering. D. Incorrect. S3 bucket policies apply only to S3 resources, so setting the resource element to a Lambda function ARN is invalid for an S3 bucket policy. The principal in an S3 bucket policy references the identity requesting access, while the resource must always reference S3 assets, so this configuration is non-functional and does not resolve the access issue. Key Concepts: 1. S3 ARN Format and Resource Scoping: S3 resource ARNs are split into two scopes: bucket-level ARNs (without a trailing wildcard) for actions that operate on the bucket itself, and object-level ARNs (with a /* trailing wildcard) for actions that operate on individual objects stored in the bucket. This is a critical IAM configuration requirement for S3 access policies tested in the SCS-C03 exam. 2. Resource-Based Policy Evaluation for Cross-Service Access: When an AWS service such as Lambda accesses another service like S3, both the identity-based policy attached to the Lambda execution role and the resource-based policy attached to the S3 bucket must explicitly allow the requested action on the target resource to grant access. 3. S3 Action Scope Alignment: All S3 actions are categorized as either bucket-scoped or object-scoped. Access to read objects uses the object-scoped s3:GetObject action, which requires a matching object-scoped resource ARN in the policy to be valid. References: Amazon S3 ARN Format, https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-arn-format.html Example S3 Bucket Policies, https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html

The scenario requires an authentication strategy for external web application users, with temporary credentials and minimal user database management overhead. The correct ordered implementation steps are as follows: 1. Configure Amazon Cognito user pools for user authentication. Cognito user pools provide a fully managed external user identity store, eliminating the need to build and maintain custom user databases, which directly meets the minimal management overhead requirement. 2. Create an Amazon Cognito application client to interact with the web application. The app client is a required entity that represents the web application in the Cognito user pool, enabling OIDC/OAuth 2.0 authentication flows and token issuance to authenticated users. 3. Implement an Amazon API Gateway HTTP API with AWS Lambda authorizers to validate tokens before forwarding requests to microservices. The Lambda authorizer validates JWT tokens issued by Cognito, and generates temporary, time-bound IAM policies to grant access to backend ECS microservices, fulfilling the temporary credentials requirement. 4. Set up an IAM role for each microservice. Grant each role appropriate permissions. These least-privilege IAM roles define the permissions each ECS-hosted microservice needs to operate, and enforce access controls to ensure only validated requests from API Gateway can invoke the microservices. The two excluded options are invalid for this use case: creating a DynamoDB table for user credentials introduces unnecessary custom user database management overhead, and AWS IAM Identity Center is designed for internal workforce identity management, not external customer authentication for public web applications. This solution aligns with the Identity and Access Management and Application Security domains of the SCS-C03 AWS Certified Security - Specialty exam. Option Analysis: Configure Amazon Cognito user pools for user authentication: Correct, first step. This managed service removes the burden of maintaining a custom user directory for external users, aligning with the minimal overhead requirement. Set up an IAM role for each microservice. Grant each role appropriate permissions: Correct, final step. These roles enforce least-privilege access for ECS workloads, restricting microservice permissions to only what is required for operation, and supporting secure access from validated API Gateway requests. Implement an Amazon API Gateway HTTP API with AWS Lambda authorizers to validate tokens before forwarding requests to microservices: Correct, third step. Lambda authorizers validate user tokens and issue temporary, scoped access policies, ensuring users only receive short-lived credentials to access backend resources. Create an Amazon DynamoDB table to store user credentials for each microservice: Incorrect. This requires manual management of user credentials and a custom user database, which directly violates the requirement to minimize user database management overhead. Cognito provides this functionality as a fully managed service. Create an Amazon Cognito application client to interact with the web application: Correct, second step. The app client enables the web application to integrate with the Cognito user pool, initiate authentication flows, and receive ID, access, and refresh tokens for authenticated users. Set up AWS IAM Identity Center to give users access to the microservices: Incorrect. IAM Identity Center is purpose-built for managing internal workforce access to AWS accounts and business applications, not for authenticating external customer users for public-facing web applications. Key Concepts: 1. Amazon Cognito External Identity Management: Cognito user pools are a fully managed service for external customer identity and access management, supporting standard OIDC/OAuth 2.0 flows and eliminating the need to build and maintain custom user databases, a core IAM security best practice tested in SCS-C03. 2. API Gateway Lambda Authorizers: Lambda (custom) authorizers validate bearer tokens for API requests and generate temporary, least-privilege IAM policies to control access to backend resources, ensuring users only receive short-lived, scoped access credentials, which aligns with temporary security credential best practices. 3. Least Privilege IAM Roles for Container Workloads: IAM roles for ECS tasks provide temporary credentials to microservices, with granular permissions tailored to each workload's requirements, reducing attack surface and meeting IAM security best practices for containerized applications. References: Amazon Cognito User Pools Developer Guide, https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html Use API Gateway Lambda Authorizers, https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html

The scenario describes an IAM policy that enforces multi-factor authentication (MFA) for all actions, leading to IAM users being unable to run Amazon EC2 CLI commands because long-term IAM user access keys do not include MFA verification context, so the aws:MultiFactorAuthPresent condition in the policy evaluates to false for these requests. The suggested answer B resolves this issue without weakening MFA enforcement by leveraging the AWS STS get-session-token operation, which lets users authenticate with their MFA device to generate temporary security credentials that explicitly include a valid MFA verification status. These temporary credentials satisfy the policy's MFA requirement, allowing users to run EC2 CLI commands while remaining compliant with the security mandate. This aligns with SCS-C03 Domain 1 (Securing Access to AWS Resources) objectives around implementing MFA enforcement for programmatic access. Option Analysis: A. Incorrect. Modifying the aws:MultiFactorAuthPresent condition value to true does not address the root cause that requests from users are made with long-term credentials that lack MFA verification. This change would not grant users access, and if implemented incorrectly could either remove MFA enforcement entirely or leave the access issue unresolved, violating the requirement to maintain MFA controls. B. Correct. The sts get-session-token CLI command is designed to generate temporary credentials for IAM users that include MFA verification when the --serial-number and --token-code parameters are provided. The resulting temporary credentials have the aws:MultiFactorAuthPresent flag set to true, which satisfies the policy's MFA requirement for EC2 actions. This solution requires no changes to the existing policy and maintains full MFA enforcement as required. C. Incorrect. Implementing SAML 2.0 federation is an unnecessary, overly complex solution for existing IAM users. The scenario does not mention a requirement for federated identity, and this approach would require extensive reconfiguration of identity management that is not needed to resolve the immediate CLI access issue. D. Incorrect. Creating an IAM role and modifying the existing policy to add sts:AssumeRole to NotAction introduces unnecessary operational complexity. Assuming a role is not required when get-session-token can directly generate valid MFA-authenticated credentials for the user's existing IAM identity, so this solution is not the most efficient or appropriate for the given scenario. Key Concepts: 1. IAM MFA Condition Keys: The aws:MultiFactorAuthPresent condition key is used in IAM policies to validate that a request was authenticated using a valid MFA device. Long-term IAM user access keys do not satisfy this condition, as they do not include MFA verification context, so temporary credentials with MFA attestation are required for programmatic access under MFA-enforcing policies. 2. STS GetSessionToken Operation: This AWS Security Token Service (STS) API returns short-term temporary security credentials for IAM or root users, and supports accepting MFA device parameters to generate credentials that mark the request as MFA-authenticated, making them compatible with MFA-enforced IAM policies. 3. Programmatic MFA Authentication for IAM Users: IAM users accessing AWS resources via CLI/API under MFA requirements cannot use long-term access keys directly, and must obtain MFA-verified temporary credentials from STS to satisfy policy conditions, which is a core identity security control tested in the SCS-C03 exam. References: IAM: Using multi-factor authentication (MFA) in AWS, https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html AWS STS API Reference: GetSessionToken, https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html

The scenario uses AWS Organizations with the default FullAWSAccess SCP, which grants all allowed actions by default for all accounts in the organization. The requirement is to restrict all non-global service usage to the eu-west-1 Region for all accounts in a target OU, including existing and future accounts, while permitting preapproved global services. The correct SCP (option C) implements an explicit deny for all API actions except the approved global services, and uses the aws:RequestedRegion condition to apply the deny only when the requested region is not eu-west-1. Since SCPs attached to an OU are automatically inherited by all accounts in that OU, including new accounts added after policy creation, this configuration meets all stated requirements. The explicit deny overrides the default allow permission from the default SCP to block unapproved activity outside eu-west-1, while excluding necessary global services that do not operate in a specific region to avoid unintended service disruption. Option Analysis: A. This option is incorrect. It typically uses an explicit Allow effect for actions in eu-west-1 instead of a Deny effect for actions outside eu-west-1. Since the default SCP grants FullAWSAccess, an additional allow policy does not block access to other regions, so it fails to enforce the required region restriction. B. This option is incorrect. It enforces the eu-west-1 region restriction but fails to exclude the approved global services from the deny rule. Global services like IAM, CloudFront, and Route 53 do not use region-specific API endpoints, so this policy would block access to these required global services and cause unintended outages. C. This option is correct. It uses an explicit Deny effect for all actions except the allowed global services, applies the deny only when the aws:RequestedRegion condition is not equal to eu-west-1, and is attached directly to the target OU. This configuration blocks all non-global service usage outside eu-west-1, preserves access to approved global services, and automatically applies to all existing and new accounts in the OU as required. D. This option is incorrect. It either uses an invalid condition key such as aws:Region instead of the correct aws:RequestedRegion, or includes explicit account ID references that require manual updates for new accounts. This means it either fails to correctly enforce the region restriction or does not automatically apply to future accounts added to the OU. Key Concepts: 1. SCP Inheritance: SCPs attached to an organizational unit (OU) are automatically inherited by all existing accounts in the OU and any new accounts added to the OU later, eliminating the need for per-account policy configuration for shared security guardrails. 2. Region Restriction SCP Design: When implementing region restrictions with SCPs, you must explicitly exclude global services from the deny rule, as these services do not operate in specific regions and will be blocked if included in the region-based deny. The aws:RequestedRegion condition key is the only supported key for filtering API requests by the target AWS Region. 3. SCP Evaluation Logic: SCPs follow the same deny-overrides-allow evaluation logic as IAM policies. When the default FullAWSAccess SCP is attached to the organization root, explicit deny policies are required to restrict permissions, as additional allow policies do not override the default allow for non-specified actions. References: AWS Organizations User Guide: Example SCPs for General Use Cases, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_general.html#example-scp-deny-region AWS Identity and Access Management User Guide: AWS Global Condition Context Keys, https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requestedregion

The scenario requires integration of an external identity provider (IdP) with AWS IAM Identity Center for federated authentication and optional automated user/group provisioning. The correct ordered sequence of valid steps is as follows: 1. Obtain the SAML metadata from the external IdP. This step collects required configuration details from the external IdP including its entity ID, assertion endpoint, and signing certificate, which are necessary for IAM Identity Center to trust the external IdP. 2. Configure the external IdP as the identity source in IAM Identity Center. During this step, the external IdP's SAML metadata is uploaded to IAM Identity Center to establish the AWS side of the SAML trust relationship. 3. Obtain the SAML metadata from IAM Identity Center. This metadata contains IAM Identity Center's service provider details including its entity ID and assertion consumer service URL, which must be added to the external IdP to complete the bidirectional SAML trust configuration for authentication. 4. Enable automatic provisioning in IAM Identity Center settings. This activates SCIM (System for Cross-domain Identity Management) provisioning on the AWS side, generating a unique SCIM endpoint URL and bearer token for the external IdP to use for syncing user and group records. 5. Enable automatic provisioning in the external IdP. The SCIM endpoint and token from IAM Identity Center are input to the external IdP's configuration to initiate automated sync of user and group updates to IAM Identity Center. The step to create an IAM role with a trust policy specifying the IdP's API endpoint is not used for this use case, as it applies to standalone SAML federation directly to IAM for individual AWS accounts, not IAM Identity Center managed federation where permission sets and access assignments are handled natively. Option Analysis: Configure the external IdP as the identity source in IAM Identity Center: Valid step, ordered second, establishes AWS side trust for the external IdP as the official source of user identities for IAM Identity Center. Create an IAM role that has a trust policy that specifies the IdP's API endpoint: Invalid, unused step. This step is only required for traditional IAM SAML federation where federated users assume pre-created IAM roles, which is not part of IAM Identity Center configuration. Enable automatic provisioning in IAM Identity Center settings: Valid step, ordered fourth, activates SCIM endpoint and access credentials on the AWS side to support automated user/group sync. Enable automatic provisioning in the external IdP: Valid step, ordered fifth, configures the external IdP to push user and group updates to IAM Identity Center via the SCIM protocol. Obtain the SAML metadata from IAM Identity Center: Valid step, ordered third, provides the external IdP with required service provider configuration to complete SAML authentication setup. Obtain the SAML metadata from the external IdP: Valid step, ordered first, provides IAM Identity Center with required IdP configuration to establish initial SAML trust. Key Concepts: 1. IAM Identity Center Identity Source Configuration: IAM Identity Center supports three identity source types: AWS Managed Identity Store, Active Directory, and external SAML 2.0 identity provider. For external IdP integration, bidirectional SAML trust must be established via exchange of SAML metadata between both parties to enable federated authentication. 2. SCIM Provisioning for IAM Identity Center: SCIM is an open standard for automating user and group provisioning and deprovisioning between identity providers and service providers. For external IdP integration, SCIM is first enabled on the IAM Identity Center side to generate access credentials, then configured on the external IdP side to initiate sync operations. 3. SAML 2.0 Federation: SAML 2.0 is an XML-based open standard for exchanging authentication and authorization data between identity providers and service providers. Exchange of SAML metadata eliminates manual configuration of endpoints and certificates, reducing configuration errors and streamlining trust setup. References: AWS IAM Identity Center User Guide: Connect to an external identity provider, https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html AWS IAM Identity Center User Guide: Automatic provisioning for external identity providers, https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html