AWS SCS-C03: Detection

Topic snapshot

Sample questions

These original IT Mastery practice questions are aligned to this topic area. Use them for self-assessment, scope review, and deciding what to drill next.

Question 1

Topic: Detection

A security team reviews this detection note for an internet-facing application:

Source: AWS WAF metrics in CloudWatch
Metric: BlockedRequests for WebACL AppEdgeAcl
Baseline: 10-30 blocked requests per minute
Observed: 2,400 blocked requests per minute for 8 minutes
CloudTrail: no recent UpdateWebACL events
Requirement: notify the SOC within 5 minutes if this pattern recurs

What is the best next action supported by this evidence?

Options:

• A. Query CloudTrail Lake only for future WAF API changes.

• B. Create a CloudWatch alarm on the WAF BlockedRequests metric.

• C. Declare a confirmed host compromise and isolate all instances.

• D. Create an AWS Config rule for WAF configuration drift.

Best answer: B

Explanation: CloudWatch metrics and alarms are appropriate when the security signal is a measurable operational change that needs fast threshold-based or anomaly-based notification. In this case, AWS WAF is already publishing BlockedRequests, the baseline and spike are visible, and the SOC has a 5-minute notification requirement. A CloudWatch alarm can evaluate that metric and trigger a notification action when the condition recurs. The evidence does not prove that hosts are compromised, and CloudTrail already shows no recent WAF configuration change. The key takeaway is to use CloudWatch alarms for timely detection of metric changes, then investigate scope and cause separately.

• Confirmed compromise overstates the evidence; blocked requests show hostile or unwanted traffic, not successful access.
• Config drift misses the main signal; the note shows a traffic-volume spike, not a noncompliant WAF setting.
• CloudTrail-only monitoring ignores the requirement to detect recurring metric spikes within 5 minutes.

Question 2

Topic: Detection

A company uses AWS Security Lake in a delegated security account to centralize AWS security logs. The security team is onboarding a third-party SaaS security tool that must add its findings to the same data lake, and a separate third-party SIEM must analyze the combined data without receiving broad access to raw log buckets. Which approach best meets these requirements?

Options:

• A. Add the SaaS tool as a Security Lake custom source and configure the SIEM as a Security Lake subscriber.

• B. Grant the SIEM read access to each account’s CloudTrail and VPC Flow Logs S3 buckets.

• C. Stream the SaaS findings to CloudWatch Logs and create metric filters for the SIEM.

• D. Import the SaaS findings into CloudTrail Lake and share CloudTrail Lake queries with the SIEM.

Best answer: A

Explanation: AWS Security Lake is the right integration layer when third-party security tools need to contribute to or consume from an AWS security data lake. A third-party producer should integrate as a custom source, using the expected normalized format such as OCSF so the data can be stored and queried consistently with AWS security logs. A third-party analytics or SIEM tool should integrate as a subscriber, which provides scoped access to the Security Lake data instead of requiring broad permissions to many raw log buckets. This preserves centralized governance, normalization, and least-privilege access.

• Raw bucket access bypasses the Security Lake access model and increases the permission scope across multiple log locations.
• CloudWatch metric filters are useful for operational alerts, but they do not add normalized third-party findings to the security data lake.
• CloudTrail Lake queries focus on CloudTrail event investigation and are not the primary integration pattern for a Security Lake-centered third-party ecosystem.

Question 3

Topic: Detection

A company deploys the Amazon CloudWatch Agent to EC2 instances by using Systems Manager. The agent status is running, the application log file exists and is being updated, and the target CloudWatch log group already exists. No application events appear in CloudWatch Logs.

Exhibit: Agent error excerpt

AccessDeniedException: User arn:aws:sts::<account-id>:assumed-role/AppInstanceRole/i-abc123
is not authorized to perform logs:CreateLogStream on resource
arn:aws:logs:us-east-1:<account-id>:log-group:/app/prod:*

Which configuration change best resolves the missing logs?

Options:

• A. Grant CloudWatch Logs write permissions to AppInstanceRole.

• B. Enable CloudTrail data events for the EC2 instances.

• C. Enable VPC Flow Logs for the instance subnet.

• D. Add permissions to the Systems Manager service-linked role.

Best answer: A

Explanation: The error identifies an IAM authorization failure for the role assumed by the EC2 instance profile. The CloudWatch Agent sends log events to CloudWatch Logs by using the credentials available on the instance, not the human operator or the Systems Manager service-linked role. Because the log file and log group already exist and the agent is running, the next control to fix is the instance role permissions for the specific log group. A least-privilege policy should allow the required CloudWatch Logs actions, such as creating log streams and putting log events, on the intended log group resources.

The key troubleshooting pattern is to match the missing telemetry path to the identity that writes the telemetry.

• Network telemetry does not solve application log ingestion; VPC Flow Logs capture network flow metadata, not file-based application logs.
• Wrong identity boundary fails because Systems Manager can deploy the agent, but the running agent writes logs with the instance role.
• Wrong service logging fails because CloudTrail data events do not collect EC2 application log files.

Question 4

Topic: Detection

An AWS security team reviews a noisy CloudWatch alarm built from CloudTrail AccessDenied events. The alarm pages the on-call engineer when more than 10 events occur in 5 minutes.

Evidence: Recent pages

Which next action is best supported by the evidence?

Options:

• A. Open an incident for confirmed credential compromise.

• B. Suppress all AccessDenied alerts during scheduled jobs.

• C. Raise the global threshold to more than 45 denied events.

• D. Create separate thresholds by role, resource sensitivity, and schedule.

Best answer: D

Explanation: Alert thresholds should reflect risk, business impact, and normal workload patterns instead of using one global count. The analytics role has a predictable burst of S3 denies during a known job, so those events may need lower-severity routing or a higher threshold during that schedule. The admin role has fewer events, but the target is a production payment KMS key, so even a small number may justify faster paging. Segmenting thresholds by principal, resource criticality, and expected time window reduces alert fatigue without hiding high-impact signals.

The evidence supports threshold tuning and routing changes, not a conclusion that compromise has occurred.

• Global threshold increase would reduce noise but could miss low-volume, high-impact events against sensitive resources.
• Full scheduled suppression creates a blind spot because risky activity can still occur during expected job windows.
• Confirmed compromise overstates the evidence; failed authorization events require investigation and correlation before that conclusion.

Question 5

Topic: Detection

A company uses AWS Organizations and wants a centralized detection workflow in a security tooling account. The SOC reviews this onboarding evidence:

Which next action is best supported by the evidence?

Options:

• A. Query CloudWatch Logs separately in each workload account

• B. Use GuardDuty delegated administration as the only central workflow

• C. Rely on AWS Config to import CloudWatch alarms into Security Hub

• D. Enable Security Hub organization aggregation and route CloudWatch alarms with EventBridge

Best answer: D

Explanation: Centralized detection should use the service that normalizes security findings and account/Region aggregation where possible. Security Hub can aggregate findings from integrated services such as GuardDuty, Macie, and AWS Config across an organization when configured with delegated administration and organization-level enablement. The evidence shows Security Hub is enabled only in the tooling account, so the member-account findings are not yet centrally available there. CloudWatch alarms are operational signals; they are not automatically normalized into Security Hub just because Config rules or GuardDuty are enabled. A practical workflow routes Security Hub findings and CloudWatch alarm state-change events, commonly through Amazon EventBridge, to the central ticketing, notification, or automation target.

• GuardDuty-only aggregation misses Macie, Config, and CloudWatch signals and does not provide a full centralized detection workflow.
• Config importing alarms infers behavior not shown; Config evaluations and CloudWatch alarm state changes are different signal types.
• Per-account log queries may help investigation but does not create centralized aggregation or triage.

Question 6

Topic: Detection

A company uses separate AWS accounts for production and analytics. A production S3 bucket stores regulated data and is shared with one approved analytics role through a bucket policy. Security needs to monitor object-level access, policy changes that widen access outside approved accounts, and unusual S3 access patterns. Which approach best satisfies these requirements?

Options:

• A. Use organization CloudTrail, S3 data events, IAM Access Analyzer, and GuardDuty S3 Protection.

• B. Enable S3 server access logging and review logs only during investigations.

• C. Use VPC Flow Logs for the bucket subnet and CloudWatch alarms on rejected traffic.

• D. Create CloudWatch alarms on bucket size and object count metrics.

Best answer: A

Explanation: For an account-boundary monitoring requirement, combine signals that cover the data plane, control plane, and exposure analysis. CloudTrail management events capture bucket policy and IAM-related changes. S3 data events capture object-level API activity, such as GetObject and PutObject, including the calling principal. IAM Access Analyzer identifies resource policies that grant access outside the intended account or organization boundary. GuardDuty S3 Protection adds managed threat detection for unusual S3 access behavior. No single network or storage metric provides all three required signals.

• Network-only logging misses S3 API identity context and bucket policy exposure because S3 access is not monitored by bucket subnet flow logs.
• Access logs alone can help investigations but do not continuously identify widened external access or managed threat findings.
• Storage metrics show capacity trends, not who accessed objects or whether permissions crossed the approved boundary.

Question 7

Topic: Detection

A company is building a central detection data lake for 60 AWS accounts across multiple Regions. Analysts must correlate security events while retaining the original account, Region, resource identifier, principal, and event timestamp for each event. Which aggregation approach best satisfies this requirement?

Options:

• A. Export only Security Hub summary findings to a central bucket

• B. Create CloudWatch metric filters and aggregate alarms in one account

• C. Enable AWS Security Lake organization-wide with a delegated administrator

• D. Forward events to a central EventBridge bus as simplified custom events

Best answer: C

Explanation: When aggregation supports investigation, the central store must preserve original event context, not just counts or summaries. AWS Security Lake is designed for organization-wide security data aggregation and normalization, including AWS log sources and findings, while retaining source metadata such as account, Region, resource, principal-related fields, and timestamps. This lets analysts correlate activity centrally without losing where and when an event actually occurred. Aggregating only metrics, simplified custom events, or summary findings can reduce fidelity and make scope validation harder. The key is to centralize security telemetry without flattening away the event’s original identity and source context.

• Metric-only aggregation loses event-level fields such as principal and resource, so it cannot support detailed investigation.
• Simplified custom events can omit or overwrite source context unless the full original payload is deliberately preserved.
• Summary findings only help triage but do not provide the complete original telemetry needed for correlation and scope validation.

Question 8

Topic: Detection

A company uses one shared SNS topic for all monitoring notifications. The security team reports alert fatigue.

Evidence summary for the last 24 hours:

Which monitoring design change best separates noisy operational events from actionable security events?

Options:

• A. Send all findings to Security Hub and page on every imported finding

• B. Route events by source, severity, account, and tags using EventBridge rules

• C. Treat all Config NOT_APPLICABLE evaluations as security incidents

• D. Disable CloudWatch alarms that generated the highest event volume

Best answer: B

Explanation: The evidence shows mixed operational telemetry and security findings flowing through the same notification path. A better monitoring design should classify and route events before notification. CloudWatch performance alarms can go to operations channels, while GuardDuty and Security Hub findings can be routed to security responders based on source, severity, production account, resource tags, or other context. EventBridge is commonly used to apply these routing rules and send events to the right targets, such as SNS topics, ticketing systems, or automation workflows. The key is not to suppress all noisy sources blindly, but to separate event classes and prioritize actionable security signals.

• Paging every finding increases noise because imported findings can include low-priority or non-actionable events.
• Disabling noisy alarms may hide operational problems instead of classifying them correctly.
• Escalating Config noise overstates the evidence because expected NOT_APPLICABLE results in test accounts are not confirmed incidents.

Question 9

Topic: Detection

A company runs a multi-account AWS workload that processes PII through CloudFront, AWS WAF, an Application Load Balancer, Amazon ECS, and Amazon S3. Security must detect credential misuse, web attacks, and possible data exfiltration, then reconstruct incidents for at least 1 year. Application teams must not be able to delete or alter investigation evidence. Which monitoring requirement set is the best security decision?

Options:

• A. Store CloudTrail management events in each account where application administrators manage retention

• B. Enable GuardDuty and Security Hub findings only, without retaining the source logs

• C. Collect CloudWatch metrics and application error logs in each workload account for 30 days

• D. Centralize CloudTrail, WAF, ALB, VPC Flow Logs, DNS logs, and app auth logs with protected 1-year retention

Best answer: D

Explanation: A monitoring requirement set should support both fast detection and later reconstruction. For this workload, the useful evidence spans multiple layers: CloudTrail management and relevant S3 data events for API and object access, AWS WAF and ALB logs for web activity, VPC Flow Logs and Route 53 Resolver query logs for network and DNS behavior, and application authentication logs for user context. Centralizing these logs in a security-owned account or log lake with protected retention helps preserve evidence from workload administrators and supports correlation across accounts for at least 1 year. Detection services such as GuardDuty and Security Hub are valuable, but their findings should be backed by retained source telemetry.

• Metrics-only monitoring misses key investigation evidence such as API calls, object access, DNS queries, and web request details.
• Findings-only collection can speed triage but does not preserve enough raw telemetry to validate scope and impact later.
• Local administrator retention fails the evidence-preservation constraint because workload teams could alter or delete logs.

Question 10

Topic: Detection

A company runs internet-facing workloads in multiple AWS accounts. The security operations team needs centralized alerts for actionable events: failed endpoint health checks, high-severity AWS security findings, and AWS service events that could affect the workloads. The solution should minimize custom polling code. Which approach best meets these requirements?

Options:

• A. Query VPC Flow Logs hourly with Athena for denied connections.

• B. Use AWS Config conformance packs with automatic remediation.

• C. Route CloudWatch health alarms, Security Hub findings, and AWS Health events with EventBridge.

• D. Create CloudTrail metric filters for all API errors.

Best answer: C

Explanation: A meaningful monitoring strategy should use the AWS signal source that matches each risk. Endpoint health checks can publish metrics and alarm state changes through Amazon CloudWatch. AWS Security Hub can centrally aggregate and normalize findings from services such as GuardDuty, Inspector, and Macie, then filter on severity. AWS Health events can be sent through Amazon EventBridge when an AWS service issue might affect an account or workload. EventBridge can route these events to AWS User Notifications, SNS, or an incident workflow. Log queries and compliance checks can support investigation, but they are not the primary controls for real-time health, service-impact, and security-finding alerts.

• Flow log querying can help investigate network activity, but it misses AWS Health events and native security findings.
• CloudTrail API errors show control-plane activity, not endpoint health or service-impact events.
• Config remediation is useful for compliance drift, but it does not provide the required workload health and finding alert strategy.

Continue with full practice

Use the AWS SCS-C03 Practice Test page for the full IT Mastery practice bank, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try AWS SCS-C03 on Web View AWS SCS-C03 Practice Test

Related focused pages

• Free AWS SCS-C03 Full-Length Practice Exam
• Incident Response
• Infrastructure Security
• Identity and Access Management
• Data Protection
• Security Foundations and Governance

Practice next step

Use the practice page above for mixed-topic practice, timed mocks, explanations, and app access.