SCS-C03 sample questions — 25 answered and explained

Security Lake shares data through subscribers. Data-access subscribers read the lake's S3 objects directly and can be notified of each new object through an SQS queue or an HTTPS subscription endpoint; query-access subscribers query the Lake Formation tables in place, for example with Athena.

Two requirements decide: the tool keeps its own copy, and it must react to new data rather than poll. A data-access subscriber gives read access to the objects, and its new-object notifications remove the need to poll. Query access fits in-place SQL, not copying, and needs scheduled queries to spot new data. A data-access subscriber that lists prefixes on a timer has the right access but polls. Security Hub CSPM aggregation carries findings, not the lake's log records.

1. Classify the consumer: it copies the data and needs a push signal for new records.
2. Match copying to the data-access subscriber type, and in-place SQL to the query-access type.
3. Check how the consumer learns of new data: subscriber notifications, not a polling timer.
4. Reject options that poll or that deliver findings instead of log records.

Exam tip: Copy-and-react consumers of Security Lake = data-access subscriber with new-object notifications; in-place SQL = query-access subscriber.

Macie publishes new and updated policy findings to Security Hub CSPM by default, but not sensitive data findings; publishing those is a Macie publication setting. In an organization, only the Macie administrator account can publish the sensitive data findings produced by automated sensitive data discovery.

Two facts decide this. The default publication covers policy findings only, so sensitive data findings need the publication setting changed. And for automated discovery run for the organization, the administrator account is the only account that can publish those findings, so the setting must be changed there, not in members. The Security Hub CSPM integration needs no action because it is enabled automatically. A custom EventBridge import works but adds code for something a setting already does.

1. Recall the default: Macie publishes policy findings, not sensitive data findings, to Security Hub CSPM.
2. Find the control: Macie's publication settings.
3. Identify which account publishes automated-discovery findings: the Macie administrator.
4. Prefer the native setting over a custom import pipeline.

Exam tip: Macie sensitive data findings reach Security Hub CSPM only after the Macie administrator turns on their publication; policy findings flow by default.

Amazon Macie discovers sensitive data in S3 in two ways: sensitive data discovery jobs that analyze the objects in a defined scope, and automated sensitive data discovery, which continuously samples objects across all buckets to build a sensitivity profile per bucket at lower cost.

Only Macie inspects object contents for personal data, which rules out Storage Lens and Config. Between the two Macie options, both find the data, but the constraints decide. A periodic job is incremental, yet every new or changed object in its scope is analyzed in full, and an explicitly selected bucket list misses new buckets. Automated discovery samples representative objects across all buckets, includes new buckets automatically and is designed for broad, ongoing coverage at lower cost. Use targeted jobs when every object must be analyzed.

1. Rule out services that cannot read object contents: Storage Lens and Config.
2. Compare the two Macie modes against the cost and new-bucket constraints.
3. Note that jobs analyze every in-scope new or changed object in full, and explicit bucket lists are fixed.
4. Choose automated discovery for ongoing, sampled, organization-wide coverage.

Exam tip: Broad, ongoing, low-cost PII visibility across many buckets = Macie automated sensitive data discovery; full jobs are for exhaustive scans.

Security Hub CSPM sends every new and updated finding to EventBridge. Event patterns can match finding attributes such as Severity.Label, so routing by severity is done with rules and targets, not code.

The deciding constraint is no custom code. Two EventBridge rules with severity-label patterns send each class of finding straight to its target (SNS for paging, SQS or a ticketing integration for the rest). A single rule with a routing Lambda function works but adds code. Polling GetFindings is code plus delay. Automation rules change fields on findings but do not notify anyone.

1. Confirm findings arrive in EventBridge in the home Region.
2. Filter on the severity label in each rule's event pattern.
3. Point the High/Critical rule at SNS and the other rule at the ticketing queue.
4. Reject options that add Lambda code or only change finding fields.

Exam tip: Route Security Hub CSPM findings by severity with EventBridge pattern matching, one rule per destination; no Lambda needed.

The human-approval gate in a Systems Manager Automation runbook is the aws:approve action: it pauses until designated approvers approve or reject, notifies them through SNS, and records their decisions.

Three requirements decide: wait for a decision, restrict who decides, record who decided. aws:pause meets only the first. A script that publishes to SNS meets only the notification. Waiting on a tag can be satisfied by anyone with tagging rights. aws:approve covers all three through Approvers, NotificationArn and its ApproverDecisions output. In Step Functions the equivalent is a callback task (waitForTaskToken); Step Functions has no built-in approval state.

1. Identify the requirement: a gated, attributable human decision before a high-impact step.
2. Separate waiting (aws:pause) from approving by named principals (aws:approve).
3. Confirm the SNS notification and recorded decision come from aws:approve.
4. Place the approval step immediately before the isolation step.

Exam tip: Use aws:approve, not aws:pause, when a named principal must allow a high-impact Automation step and the decision must be recorded.

Automated EC2 evidence acquisition captures volatile memory from the running instance, snapshots its EBS volumes, isolates it with a security group, and stores the evidence in a separate forensics account. AWS packages this as the Automated Forensics Orchestrator for Amazon EC2 and EKS.

Two facts combine. Memory exists only while the instance runs, so any design that stops or terminates the instance before capturing it loses that evidence. Evidence kept in the workload account (an in-account bucket or retained scan snapshots) remains reachable with that account's credentials. Only the design that captures memory and disks from the running host and moves them to the forensics account meets both requirements.

1. Note that volatile memory is needed, so the instance must keep running until memory is captured.
2. Note that the evidence must leave the workload account.
3. Reject stop and terminate designs, and any design that keeps the evidence in the workload account.
4. Choose memory capture, disk snapshots, isolation by security group, and transfer to the forensics account.

Exam tip: Capture memory before you stop anything, and move evidence out of the compromised account into the forensics account.

Incident response plans are tested on a ladder: tabletop exercises (discussion only), simulations with sample findings, and game days or fault injection against real resources.

The goal is about decisions and hand-offs between people, including non-technical roles. A tabletop exercise tests exactly that, cheaply and first. Sample findings, FIS experiments and game days are the later, technical rungs of the ladder: they prove detection and recovery, not who decides what.

1. Classify the goal: decision ownership and hand-offs, not technical recovery.
2. Match people-and-process gaps to a discussion-based exercise.
3. Place sample findings, FIS and game days later on the ladder for technical proof.
4. Start with a tabletop, then move up the ladder.

Exam tip: Start validating a playbook with a tabletop exercise: it is the cheapest test of who decides, who is told and which hand-offs are missing.

GuardDuty sample findings, generated per finding type with the CreateSampleFindings API (the console generates one of every type), test EventBridge rules and finding automation end to end without real activity.

Each option tests part of the route. The tester creates real activity but needs deployed resources and covers common types only. Importing into Security Hub CSPM or using a custom action starts the test downstream of GuardDuty with events the GuardDuty rules do not match. Sample findings of the exact six types start at GuardDuty, arrive within minutes and need no resources.

1. Identify where the test must start: GuardDuty.
2. Remove methods that inject downstream (Security Hub CSPM import or custom action).
3. Remove methods that need deployed resources or cannot target specific types.
4. Generate sample findings for each matched type and trace each to the page.

Exam tip: To test finding automation from GuardDuty onward, generate sample findings of the exact types your rules match.

For S3 origins, origin access control (OAC) plus a bucket policy that allows the cloudfront.amazonaws.com service principal with an AWS:SourceArn condition naming the distribution keeps the bucket private and readable only through that distribution.

OAC makes CloudFront sign requests as the service principal, and the AWS:SourceArn condition narrows the grant to one distribution, so the bucket stays private and other distributions are refused. Without the condition, any distribution could read the bucket. The OAI option mixes the legacy identity principal with a condition only OAC requests satisfy. A website endpoint needs anonymous public access, which conflicts with Block Public Access, and Referer secrets are forgeable.

1. Keep Block Public Access on, which rules out the website endpoint design.
2. Use OAC so CloudFront signs requests as the cloudfront.amazonaws.com service principal.
3. Grant s3:GetObject to that principal with AWS:SourceArn equal to the distribution ARN.
4. Confirm direct S3 URLs are denied while the distribution serves the objects.

Exam tip: Private S3 origin = OAC plus a bucket policy for the CloudFront service principal with AWS:SourceArn set to your distribution.

CloudFront signed URLs carry the signature in each URL; signed cookies cover many objects without changing URLs. A canned policy covers one exact resource; a custom policy can use wildcards, date ranges and IP conditions. Both are verified against a trusted key group.

Two facts decide it: cookies avoid touching URLs, and only a custom policy can cover a wildcard path. Signed cookies with a custom policy for the title path authorize every segment for the chosen period. A wildcard signed URL still needs the signature on each segment request. Signed cookies with a canned policy cover a single object. OAC protects the origin, not viewer authorization.

1. Note that URLs cannot change, which points to signed cookies over signed URLs.
2. Note that one grant must cover many files, which needs a custom policy with a wildcard path.
3. Create a trusted key group with the public key and set it on the cache behavior.
4. After authenticating a subscriber, the application sets the signed cookies with an expiry of a few hours.

Exam tip: Many files and no URL changes = signed cookies with a custom (wildcard) policy; canned policies cover one exact object.

AWS managed rule groups split into baseline groups (Core rule set, Admin protection, Known bad inputs), use-case groups (SQL database, Linux, POSIX and Windows operating system, PHP and WordPress application) and IP reputation groups; you add the ones that match the application stack.

The application is PHP on Amazon Linux with a MySQL database, so the matching set is Core rule set + Known bad inputs + SQL database + Linux operating system + PHP application. SQL injection is covered by the SQL database group, not by the Core rule set, so dropping it for Bot Control leaves a gap. The Windows group and the WordPress group target platforms the application does not use and only consume web ACL capacity units.

1. List the threats: common exploits, known bad inputs, SQL injection, stack-specific attacks.
2. Map common exploits and known bad inputs to the Core rule set and Known bad inputs groups.
3. Map SQL injection to the SQL database group, which the Core rule set does not replace.
4. Add only the OS and application groups that match the stack: Linux and PHP.

Exam tip: Choose AWS managed rule groups by stack: Core and Known bad inputs as baseline, SQL database for SQLi, plus the matching OS and application groups.

WAF evaluates rules in ascending priority number and stops at the first terminating action (Allow, Block, and CAPTCHA/Challenge when they end the request); Count is non-terminating.

The corporate IP-set Allow rule has the lowest priority number and matches, and Allow is terminating, so the request is allowed and the Core rule set never sees the payload. Managed groups are not evaluated ahead of custom rules, Block does not override an earlier Allow, and a rule that was never reached records nothing.

1. Order the rules by ascending priority number.
2. Find the first rule that matches the request: the corporate IP-set Allow.
3. Recall that Allow terminates evaluation, so later rules do not run.
4. To keep inspecting trusted traffic, narrow the Allow rule or place it after the managed groups.

Exam tip: The first terminating action wins: a broad early Allow silently skips every managed rule after it.

Role chaining (using an assumed role's temporary credentials to assume another role) limits the new session to 1 hour. A chained AssumeRole that requests more than 3600 seconds fails with a validation error; it is not silently shortened.

The pattern (fails at 14400, succeeds at 3600, caller is a role session) is the role-chaining limit. A role's maximum session duration applies whether the role is assumed from the API or the console; session policies affect permissions only; and there is no "cannot outlive the parent" rule. A longer session needs a first-hop AssumeRole from non-role credentials.

1. Identify that RoleB is assumed with another role's temporary credentials (a chain).
2. Recall that a chained session is limited to 1 hour.
3. Recall that a chained request above 3600 seconds fails rather than being shortened.
4. Request 3600 seconds or less, or assume RoleB on the first hop if a longer session is needed.

Exam tip: Chained AssumeRole calls must request 3600 seconds or less; only a first-hop AssumeRole can use the role's full maximum session duration.

IAM Identity Center is the workforce answer for multi-account access: an external IdP authenticates users over SAML 2.0, SCIM provisions users and groups automatically, and permission sets become roles in each assigned account.

Two requirements decide: automatic reflection of user and group changes (SCIM) and least administration across 45 accounts (Identity Center rather than per-account SAML). Identity Center without SCIM still needs manual user and group creation. Per-account IAM SAML federation works but multiplies configuration. Cognito targets application end users, not the workforce.

1. List the requirements: SSO across 45 accounts, automatic joiner/mover/leaver handling, least administration.
2. Pick IAM Identity Center for multi-account workforce access.
3. Add SCIM so users and group memberships sync from Okta.
4. Assign Okta groups to permission sets across the accounts.

Exam tip: Identity Center + external IdP: SAML for sign-in, SCIM for provisioning; without SCIM, user and group changes are manual.

A Cognito user pool authenticates users and issues JWTs; an identity pool exchanges a user pool ID token for temporary AWS credentials from an IAM role. Per-user scoping uses the policy variable ${cognito-identity.amazonaws.com:sub}, which is the caller's identity ID.

Two facts combine: only an identity pool turns a sign-in into AWS credentials, and only the cognito-identity.amazonaws.com:sub variable separates users who share a role. Guest access gives credentials but not a user-bound identity; aws:username does not exist for role sessions; and S3 does not accept a Cognito JWT as a credential.

1. Separate authentication (user pool) from AWS credentials (identity pool).
2. Use authenticated identities so each signed-in user gets their own identity ID.
3. Scope the role policy with ${cognito-identity.amazonaws.com:sub}.
4. Reject variables that only exist for IAM users.

Exam tip: User pool to sign in, identity pool to get credentials, and ${cognito-identity.amazonaws.com:sub} to give each user their own prefix.

IAM Roles Anywhere lets workloads outside AWS use X.509 certificates from a CA registered as a trust anchor to obtain temporary credentials for an IAM role selected through a profile.

The constraints are: outside AWS, existing private-CA certificates, no long-term keys, a role per application. Roles Anywhere meets all four. OIDC federation uses tokens, not certificates. Systems Manager hybrid activation gives the agent a single service role for its own use. IAM user signing certificates are long-term credentials.

1. Note the workload runs outside AWS and already has X.509 certificates.
2. Rule out anything that stores long-term credentials.
3. Register the CA as a Roles Anywhere trust anchor and create a profile per role.
4. Use the credential helper to exchange the certificate for role credentials.

Exam tip: Workloads outside AWS with X.509 certificates use IAM Roles Anywhere: CA as trust anchor, certificate exchanged for temporary role credentials.

AssumeRole is authorized on two sides: the caller's policies must allow sts:AssumeRole on the role ARN (with no SCP or boundary deny), and the role's trust policy must name the caller (or its account) with every condition met.

The stem clears the caller side, so the failure is on the role side: the trust policy does not trust this principal. iam:PassRole is for handing roles to services; an empty permissions policy does not block assumption; and Organizations membership is not required for cross-account roles.

1. Treat AssumeRole AccessDenied as a two-sided check.
2. Clear the caller side: identity policy, SCPs, permissions boundaries.
3. Check the role side: the trust policy Principal and its conditions.
4. Confirm in CloudTrail which role and caller the failed event names.

Exam tip: AssumeRole needs both an allow for the caller and a trust policy that names the caller; when the caller side is clean, check the trust policy.

API Gateway enforces mutual TLS on the custom domain name. The default execute-api endpoint does not enforce it, so it must be disabled for mTLS to be the only way in.

Calls through the custom domain already fail without a certificate, so mTLS is working there. The penetration test therefore used another entry point: the default execute-api endpoint, which ignores the custom domain's mTLS settings until you disable it (disableExecuteApiEndpoint). An incomplete truststore and a missing revocation check both fail closed or have no effect on certificate-less clients, and a resource policy cannot override the TLS handshake.

1. Note that the custom domain correctly rejects calls without a certificate.
2. Ask which other path reaches the same API: the default execute-api endpoint.
3. Recall that mTLS is configured per custom domain and is not applied to the default endpoint.
4. Fix by disabling the default endpoint so all traffic must use the mTLS custom domain.

Exam tip: API Gateway mTLS lives on the custom domain; disable the default execute-api endpoint or it stays a bypass.

Traffic that crosses AWS Regions on the AWS global network, including inter-Region VPC peering and Transit Gateway peering, is encrypted by AWS automatically.

AWS encrypts data at the physical layer before it leaves AWS secured facilities for another Region, and documents inter-Region VPC peering traffic as encrypted. That satisfies a requirement about the hop between Regions without a VPN or Transit Gateway. Nitro encryption is a separate, instance-level feature and is not what protects the inter-Region link. Application-level TLS is still the way to protect data end to end inside each Region.

1. Identify the scope of the question: the hop between Regions, not the whole path.
2. Recall that AWS encrypts traffic crossing Regions on its global network, including inter-Region peering.
3. Reject options that add a VPN or Transit Gateway for a hop that is already encrypted.
4. Separate Nitro instance-to-instance encryption from backbone encryption.

Exam tip: Inter-Region traffic on the AWS backbone is encrypted by AWS; use TLS when you need end-to-end protection.

Before raising a TLS minimum, inventory the clients that would break from the load balancer's own logs: ALB access logs (and connection logs) record the negotiated TLS protocol and cipher per client.

The access log fields ssl_protocol and ssl_cipher, together with the client IP, show which clients still negotiate TLS 1.0 or 1.1 before anything is changed. ALB connection logs also record the TLS protocol per connection, including failed handshakes, which helps after a change. Flow logs have no TLS fields, the CloudWatch metric only counts failures with no per-client detail, and CloudTrail records only management API calls for Elastic Load Balancing, not connections.

1. The team needs per-client TLS versions from current traffic, before the change.
2. Find a source that records the negotiated protocol per client: the ALB's access logs.
3. Reject sources that only count failures or that do not see TLS at all.
4. Query the ssl_protocol field for TLSv1 and TLSv1.1 to list the clients to fix first.

Exam tip: Before raising an ALB TLS minimum, query access logs for ssl_protocol to see who would break.

With several certificates on one listener, an ALB selects the certificate by the SNI hostname the client sends; clients without SNI receive the listener's default certificate.

The clue is that the failing clients receive a valid certificate for a different name. Certificate selection is driven by SNI, and legacy libraries and probes that omit SNI get the default certificate. A TLS 1.3-only policy would break the handshake outright, a private CA would raise a trust error on the right certificate, and listener rules act after the handshake.

1. Note the exact symptom: the right site, the wrong certificate, a name mismatch.
2. Ask what decides which certificate an ALB presents: the SNI hostname in the ClientHello.
3. Notice that only old clients fail; old libraries and probes often omit SNI.
4. Fix the clients to send SNI, or make the default certificate cover the names they call.

Exam tip: Wrong certificate from a multi-certificate ALB = the client sent no SNI and got the default certificate.

Denying organizations:LeaveOrganization in an SCP on the root or OUs keeps compromised member accounts inside their guardrails.

LeaveOrganization is called by a principal in the member account, so the control must constrain member-account principals: an SCP attached where it is inherited by those accounts. The RCP version uses the wrong policy type for a service RCPs do not support, the management-account attachment has no effect, and declarative policies have no membership setting.

1. Identify who makes the call: a principal in the member account.
2. Pick the policy type that constrains member-account principals: an SCP.
3. Attach it where member accounts inherit it (root or OUs), not to the management account.

Exam tip: Deny organizations:LeaveOrganization with an SCP on the root or OUs.

An RCP perimeter with aws:PrincipalOrgID caps access to member-account resources for every caller, so a mis-shared resource policy cannot expose data outside the organization.

Two facts decide this. First, the policy type: only an RCP is evaluated against callers from outside the organization; an SCP constrains only the organization's own principals. Second, the condition key: the perimeter must test the caller (aws:PrincipalOrgID), not the resource (aws:ResourceOrgID, which is always your organization for your own resources). The aws:PrincipalIsAWSService exception is the documented way to keep AWS services working.

1. Identify who must be stopped: callers outside the organization.
2. Choose the policy type evaluated for those callers: an RCP, not an SCP.
3. Test the caller with aws:PrincipalOrgID; aws:ResourceOrgID describes the resource.
4. Keep the AWS service principal exception so service-to-service access keeps working.

Exam tip: Resource perimeter = RCP denying unless aws:PrincipalOrgID matches; SCPs cannot reach external callers.

Control Tower controls are preventive (SCPs or RCPs), detective (AWS Config rules) or proactive (CloudFormation hooks evaluated during provisioning).

Match each behaviour to its mechanism. Blocking an API action for member accounts is preventive, implemented as an SCP (some newer preventive controls use RCPs or declarative policies). Flagging resources that already exist is detective, implemented as an AWS Config rule. Rejecting a noncompliant resource in a CloudFormation stack before it is created is proactive, implemented as a CloudFormation hook. The other orderings swap two mechanisms.

1. Classify each control: block an action, flag existing state, or check a template before creation.
2. Map block to an SCP, flag to an AWS Config rule, and pre-creation check to a CloudFormation hook.
3. Read the order in the stem and pick the matching sequence.

Exam tip: Preventive = SCP/RCP, detective = Config rule, proactive = CloudFormation hook.

Control Tower Account Factory vends new accounts that are enrolled from the start, in the chosen OU, with the baseline and controls applied.

Account Factory, which is built into Control Tower, creates accounts already governed in the chosen OU. Enrolling an account created in Organizations works but adds the follow-up step the stem excludes. AFT meets the governance requirement too, but it is a Terraform pipeline the team would have to deploy and run, so it loses on operational overhead. Customizations for Control Tower does not create accounts at all.

1. Note the constraints: governed as it is created, no follow-up step, least overhead.
2. Rule out the two-step create-then-enroll path.
3. Compare the two vending options: built-in Account Factory versus the AFT pipeline.
4. Rule out Customizations for Control Tower, which customizes accounts but does not create them.

Exam tip: New governed accounts come from Account Factory; existing accounts are enrolled.