Free SCS-C03 practice questions

In Security Hub CSPM, central configuration lets the delegated administrator define configuration policies (service on/off, standards, controls, control parameters) in the home Region and associate them with the root, OUs or accounts; policies take effect in the home Region and all linked Regions, and accounts inherit the policy of their closest parent.

Different settings per OU, applied automatically when accounts move, is exactly what configuration policy inheritance provides. Local configuration can only auto-enable the default standards for new accounts in one Region, so it can neither tailor the sandbox OU nor follow OU moves. The management account cannot author configuration policies; only the delegated administrator can, from the home Region. StackSets can deploy standards, but the accounts remain self-managed and each holds its own copy of the settings. Central configuration also requires cross-Region aggregation with the home Region set first, which is why the policies are authored there.

1. Note the requirement: different standards and controls per OU, following accounts that move.
2. Recall that only configuration policies, created by the delegated administrator in the home Region, are associated with OUs and inherited.
3. Rule out local configuration: it affects only new accounts in the current Region with the default standards.
4. Rule out the management account as the author: central configuration APIs belong to the delegated administrator.

Exam tip: Per-OU Security Hub CSPM settings that follow account moves = central configuration policies, authored by the delegated administrator in the home Region.

Responder access is a preparation control: a least-privilege incident response role in every account, deployed as code (for example with CloudFormation StackSets) and assumable from a central security tooling account.

The deciding facts are timing and scope. Access that is created during the incident (an administrator assigning a permission set) repeats the three-hour delay. Access that is ready but over-broad (AdministratorAccess) turns one compromised responder into an organization-wide compromise. IAM users are ready and can be scoped, but they bring long-term credentials. The pre-deployed scoped role satisfies all three constraints and leaves a CloudTrail record of each assumption.

1. List the constraints: minutes to access, no long-term credentials, no standing administrator rights.
2. Reject any design that grants access after the incident opens.
3. Reject designs that use IAM users (long-term credentials) or AdministratorAccess (standing admin).
4. Choose a pre-deployed role with investigation reads plus targeted containment actions, trusted by the security tooling account.

Exam tip: Provision responder roles before the incident: least privilege, deployed to every account, assumed cross-account with temporary credentials.

AWS WAF associates with CloudFront distributions, Application Load Balancers, API Gateway REST API stages, AppSync GraphQL APIs, Cognito user pools, App Runner services, Verified Access instances and Amplify apps. It cannot be associated with a Network Load Balancer or an EC2 instance.

The NLB is not a WAF resource, so the workload needs a supported layer 7 insertion point in front of it. A CloudFront distribution with the NLB as its origin provides one without touching the load balancer or targets, and its web ACL must be created in the CloudFront (global) scope in us-east-1. Swapping the NLB for an ALB is the tempting near-twin: it works, but it breaks the stated constraint. A Regional web ACL cannot be associated with an NLB at all. Shield Advanced automatic application layer mitigation exists only for CloudFront and ALB protections, relies on a web ACL and has been superseded by the Anti-DDoS managed rule group since March 2026, so it adds nothing for NLB Elastic IPs.

1. Check whether the resource in the path is a supported WAF association target; an NLB is not.
2. Apply the constraint: the load balancer type and targets must stay, which rules out moving to an ALB.
3. Add a supported insertion point in front of the NLB: a CloudFront distribution using the NLB as a custom origin.
4. Create the web ACL in the CloudFront (global) scope in us-east-1 with the managed rule groups and associate it with the distribution.

Exam tip: No WAF on an NLB or instance: add a supported insertion point such as CloudFront in front of it, or change the load balancer to an ALB if that is allowed.

aws:MultiFactorAuthPresent is in the request context only when the call uses temporary credentials. Requests signed with long-term access keys omit it, and a condition operator without IfExists does not match a missing key.

The symptom is a deny that blocks console users (key present, value false) but not access keys (key absent). A plain Bool comparison needs the key to exist, so access-key traffic slips through. BoolIfExists evaluates to true when the key is missing, extending the deny to callers that cannot carry MFA. Comparing against "true" flips the policy onto MFA users; a Null condition with "false" is the opposite test (key present); aws:MultiFactorAuthAge is absent in exactly the same requests.

1. Note which callers are blocked (console sessions) and which are not (long-term access keys).
2. Recall that aws:MultiFactorAuthPresent is only populated for temporary credentials.
3. Recall that a condition on a missing key does not match unless the operator uses IfExists (or a Null test for "true").
4. Choose BoolIfExists so the deny treats an absent key as "no MFA".

Exam tip: An MFA deny must use BoolIfExists on aws:MultiFactorAuthPresent; plain Bool silently exempts long-term access keys.

S3 enforces encrypted transport through a bucket policy that explicitly denies requests where aws:SecureTransport is false. An explicit deny overrides every allow, so the control holds whatever the caller's IAM permissions are.

For an HTTP request, aws:SecureTransport evaluates to false, so a Deny conditioned on that value blocks all plaintext access and wins over any allow. Both Allow statements fail for the same reason: allows elsewhere still grant HTTP access, and an Allow cannot take that away. The s3:TlsVersion deny is the subtle trap: the key exists only for TLS requests, so on an HTTP request it is missing, the NumericLessThan condition does not match, and the deny is skipped. Use s3:TlsVersion in addition to the SecureTransport deny when a minimum version is also required.

1. The requirement must hold regardless of other policies, so the statement must be an explicit Deny.
2. For HTTP requests, aws:SecureTransport is false, so the Deny must match the value "false".
3. Check what each condition key looks like on a plaintext request: s3:TlsVersion is absent, so a condition on it alone does not match.
4. Choose the Deny on aws:SecureTransport false; add a version deny only as a second statement.

Exam tip: Enforce TLS on S3 with Deny + aws:SecureTransport false; s3:TlsVersion only raises the version for requests that already use TLS.