Free SCS-C03 practice questions

AWS Security Hub delivers organization-wide finding visibility through two mechanisms: delegated administration (a member account manages findings for every account) and cross-Region aggregation (findings from linked Regions replicate continuously into one home Region).

Designating the security tooling account as the Security Hub delegated administrator and enabling cross-Region aggregation is the native pattern for a single view of findings across many accounts and Regions, including bidirectional workflow-state updates. GuardDuty alone produces findings but aggregates nothing across the estate. Security Lake normalizes and stores data for analytics but has no triage or workflow capability. Administering Security Hub from the management account keeps daily security operations in the most privileged account and adds fragile hand-built forwarding that the service already provides.

1. From the Organizations management account, designate the security tooling account as the Security Hub delegated administrator.
2. Use central configuration from the delegated administrator to enable Security Hub across all member accounts.
3. Choose one aggregation (home) Region and link the other two Regions so findings replicate into it.
4. Triage and manage finding workflow states from the delegated administrator in the home Region.

Exam tip: A single view of findings across accounts and Regions is Security Hub with a delegated administrator plus cross-Region aggregation — never manual console reviews or the management account.

The AWS Security Incident Response Guide follows four phases: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. Preparation is the phase Task 2.1 tests hardest.

Scoped responder roles, a dedicated forensics account, and registered contacts are all controls that must exist before an incident, which is the definition of the preparation phase. Detection and analysis, containment, and post-incident activity all consume what preparation staged; trying to create responder access during them is the anti-pattern the guide warns against.

1. Recognize the four AWS IR phases and their goals.
2. Classify each listed task: responder roles, forensics account, contacts are all access/tooling staged in advance.
3. Map staging-in-advance to the preparation phase.
4. Reject the operational phases, which use rather than build these controls.

Exam tip: Anything that must already exist when the alarm fires — responder roles, forensics account, contacts, runbooks — belongs to preparation, the most heavily tested IR phase.

AWS WAF only associates with CloudFront distributions, Application Load Balancers, API Gateway REST API stages, AppSync GraphQL APIs, Cognito user pools, and App Runner services — never with EC2 instances or Network Load Balancers.

Because an NLB is not a WAF attachment point, the workload needs a supported layer 7 entry point, and putting CloudFront in front of the NLB provides exactly that so a CloudFront-scoped web ACL can filter HTTP requests. Associating WAF directly with the NLB is impossible. There is no per-EC2 or per-ENI WAF association. Shield Advanced defends against DDoS and can auto-mitigate L7 floods only when a web ACL already exists; it does not add WAF coverage or OWASP content filtering to an NLB by itself.

1. Recognize that the NLB and EC2 instances are not valid WAF attachment points.
2. Introduce a supported insertion point by placing CloudFront in front of the workload.
3. Create a web ACL in the CloudFront (global) scope in us-east-1 and add AWS Managed Rules such as the Core rule set.
4. Associate the web ACL with the distribution and lock the origin so traffic must pass through CloudFront.

Exam tip: To use AWS WAF with an NLB or bare EC2, you must add a supported layer 7 insertion point such as CloudFront — WAF never attaches to an NLB or an instance directly.

aws:MultiFactorAuthPresent is only in the request context for temporary credentials. Bool requires the key to exist to match; BoolIfExists treats an absent key as a match, which is what extends an MFA deny to long-term access keys.

Access-key requests carry no MFA context, so plain Bool finds no key and the false comparison never triggers the deny, exempting them silently. BoolIfExists treats the missing key as a match and denies them — the intended posture, since a standalone access key can never present MFA. Option b misdescribes the key as present-and-true and reaches for a string operator. Option c swaps in the age key, which is equally absent for access keys and addresses re-authentication timing, not presence. Option d is factually wrong: identity policies are evaluated for access-key callers, so no SCP is needed.

1. Recognize that aws:MultiFactorAuthPresent is populated only for temporary (STS) credentials.
2. Understand that long-term access-key requests omit the key, so plain Bool cannot evaluate to a match.
3. Replace Bool with BoolIfExists so a missing key is treated as satisfying the false comparison.
4. Keep a NotAction carve-out for the self-service MFA-enrollment actions so users can still enroll a device.

Exam tip: Enforce MFA with BoolIfExists on aws:MultiFactorAuthPresent — plain Bool leaves long-term access-key traffic unrestricted because those requests carry no MFA context.

ACM managed renewal for DNS-validated public certificates depends on the validation CNAME remaining published; deleting or failing to migrate it breaks automatic renewal.

Managed renewal re-validates domain ownership by re-reading the CNAME ACM created. A zone migration that omits the record removes ACM's ability to validate, so the certificate expires with no manual event to flag it — the classic silent outage. Option b invents a lifetime cap. Option c wrongly claims the validation method changed. Option d misdescribes both ALB behaviour and browser caching.

1. Confirm the certificate is ACM-issued and DNS-validated, not imported.
2. Check the current hosted zone for the ACM validation CNAME record.
3. Republish the exact CNAME record ACM created so ownership can be re-validated.
4. Add the DaysToExpiry CloudWatch metric or the acm-certificate-expiration-check Config rule to catch future renewal failures early.

Exam tip: DNS-validated ACM certificates auto-renew only while the validation CNAME stays published — a zone migration that drops the record causes a silent expiry.