How should I use these Security Logging and Monitoring practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Security Logging and Monitoring questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Security Logging and Monitoring domain.

SCS-C02 · topic practice

Security Logging and Monitoring practice questions

Practise AWS Certified Security Specialty SCS-C02 Security Logging and Monitoring practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

20 questionsDomain: Security Logging and Monitoring

Practice 10 questions Browse domain →

What the exam tests

What to know about Security Logging and Monitoring

Security Logging and Monitoring questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Security Logging and Monitoring exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Security Logging and Monitoring questions

20 questions · select your answer, then reveal the explanation

Question 1mediummultiple choice

Read the full Security Logging and Monitoring explanation →

A company uses AWS CloudTrail to log management events in all regions. The security team notices that some API calls made by an IAM user are not appearing in the CloudTrail event history. What is the most likely reason?

Trap 1: The user used the AWS Management Console, not the CLI

CloudTrail logs management events regardless of the client used to issue the API call; the AWS Management Console, CLI, SDKs, and other tools all generate the same underlying API requests that CloudTrail captures. Therefore, using the console rather than the CLI would still produce CloudTrail events, and the request source cannot change the 90-day retention limit of event history. The user's inability to find old events is a retention issue, not an ingestion or access-method issue.

Trap 2: The trail is configured for a single region only

A trail configured for a single region only records management events for that region, but CloudTrail's 'Event history' page is a separate account-level feature that displays events for all regions unless filtered. Even with a single-region trail, you can still view up to 90 days of event history, because the 90-day retention is fixed and independent of the trail's region scope. Thus, the regional configuration would affect what events are delivered to an S3 bucket, but it does not explain the absence of events older than 90 days.

Trap 3: The API calls were read-only and excluded by default

CloudTrail management event logging includes both read and write operations by default; the optional 'read-only' filter is used to classify events after capture, not to exclude read-only calls from logging. The CloudTrail event history page records read-only management events such as Describe* and List* calls as part of its default configuration, so these API calls are present in event history. Therefore, read-only calls cannot be the reason that events older than 90 days are missing.

Study all Security Logging and Monitoring common traps →

A
The user used the AWS Management Console, not the CLI
Why wrong: CloudTrail logs management events regardless of the client used to issue the API call; the AWS Management Console, CLI, SDKs, and other tools all generate the same underlying API requests that CloudTrail captures. Therefore, using the console rather than the CLI would still produce CloudTrail events, and the request source cannot change the 90-day retention limit of event history. The user's inability to find old events is a retention issue, not an ingestion or access-method issue.
B
The trail is configured for a single region only
Why wrong: A trail configured for a single region only records management events for that region, but CloudTrail's 'Event history' page is a separate account-level feature that displays events for all regions unless filtered. Even with a single-region trail, you can still view up to 90 days of event history, because the 90-day retention is fixed and independent of the trail's region scope. Thus, the regional configuration would affect what events are delivered to an S3 bucket, but it does not explain the absence of events older than 90 days.
C
The API calls were read-only and excluded by default
Why wrong: CloudTrail management event logging includes both read and write operations by default; the optional 'read-only' filter is used to classify events after capture, not to exclude read-only calls from logging. The CloudTrail event history page records read-only management events such as Describe* and List* calls as part of its default configuration, so these API calls are present in event history. Therefore, read-only calls cannot be the reason that events older than 90 days are missing.
D
CloudTrail event history only retains events for 90 days; older events are not visible
CloudTrail event history is a built-in feature that provides a view of the last 90 days of account activity, and this retention period is not configurable. Once an event is older than 90 days, it is no longer visible in event history, and the only way to retain it is to configure a trail that delivers CloudTrail log files to Amazon S3 (and optionally CloudWatch Logs) with a suitable lifecycle policy. This 90-day limit applies uniformly to all management events, regardless of the client, region scope, or whether the calls are read-only or write-only.

Full breakdown with real-world context →

Question 2hardmultiple choice

Read the full Security Logging and Monitoring explanation →

A company requires real-time analysis of AWS CloudTrail logs to detect unauthorized API calls. The logs are stored in Amazon S3. Which architecture minimizes latency and cost?

Trap 1: Use AWS Glue to crawl S3 and load into Amazon Redshift for analysis

AWS Glue Crawlers discover schemas and AWS Glue ETL jobs process data in discrete, scheduled batches; they do not provide continuous event streaming. Loading into Amazon Redshift via COPY or Glue jobs likewise runs as a recurring batch load, adding latency that is incompatible with real-time analysis. This pipeline is appropriate for periodic data warehouse refreshes, not for a low-latency operational analytics feed.

Trap 2: Query CloudTrail logs directly using Amazon Athena

Amazon Athena executes interactive SQL directly against files in Amazon S3, but each query starts cold over the objects already present and returns results after the scan completes. Athena has no push delivery, no automatic continuous query engine, and no built-in mechanism to re-run on new data without an external scheduler. Consequently it can provide fast ad-hoc analysis, but not the ongoing real-time stream analysis needed here.

Trap 3: Configure S3 event notifications to invoke an AWS Lambda function…

Amazon S3 event notifications are asynchronous object-create events; CloudTrail log files are delivered to S3 in batched, aggregated files, so events arrive in chunks rather than as a real-time stream. Notifications can also be delayed or delivered at least once, and an invoker Lambda writing to Amazon OpenSearch Service may be throttled under high log volume. This design has no streaming semantics and cannot guarantee near-real-time visibility, unlike a CloudWatch Logs subscription feeding Firehose.

Study all Security Logging and Monitoring common traps →

A
Use AWS Glue to crawl S3 and load into Amazon Redshift for analysis
Why wrong: AWS Glue Crawlers discover schemas and AWS Glue ETL jobs process data in discrete, scheduled batches; they do not provide continuous event streaming. Loading into Amazon Redshift via COPY or Glue jobs likewise runs as a recurring batch load, adding latency that is incompatible with real-time analysis. This pipeline is appropriate for periodic data warehouse refreshes, not for a low-latency operational analytics feed.
B
Send CloudTrail logs to Amazon CloudWatch Logs, then use a subscription filter to Amazon Kinesis Data Firehose delivering to Amazon OpenSearch Service
CloudTrail can be configured to deliver events to Amazon CloudWatch Logs within minutes, and a subscription filter can immediately forward matching events to Amazon Kinesis Data Firehose. Firehose then buffers and delivers a continuous stream to Amazon OpenSearch Service, which indexes documents as they arrive for near-real-time search and visualization with OpenSearch Dashboards/Kibana. This managed pipeline gives the low-latency ingestion and querying the requirement asks for.
C
Query CloudTrail logs directly using Amazon Athena
Why wrong: Amazon Athena executes interactive SQL directly against files in Amazon S3, but each query starts cold over the objects already present and returns results after the scan completes. Athena has no push delivery, no automatic continuous query engine, and no built-in mechanism to re-run on new data without an external scheduler. Consequently it can provide fast ad-hoc analysis, but not the ongoing real-time stream analysis needed here.
D
Configure S3 event notifications to invoke an AWS Lambda function that writes to Amazon OpenSearch Service
Why wrong: Amazon S3 event notifications are asynchronous object-create events; CloudTrail log files are delivered to S3 in batched, aggregated files, so events arrive in chunks rather than as a real-time stream. Notifications can also be delayed or delivered at least once, and an invoker Lambda writing to Amazon OpenSearch Service may be throttled under high log volume. This design has no streaming semantics and cannot guarantee near-real-time visibility, unlike a CloudWatch Logs subscription feeding Firehose.

Full breakdown with real-world context →

Question 3easymultiple choice

Read the full Security Logging and Monitoring explanation →

A security engineer needs to be alerted when an IAM user attempts to modify an S3 bucket policy. Which method is the MOST efficient?

Trap 1: Enable VPC Flow Logs and analyze for S3 API traffic

VPC Flow Logs capture IP traffic metadata—source and destination addresses, ports, and protocols—at the network interface level. They do not contain the S3 API operation name (such as PutBucketPolicy) or the request body, so you cannot identify which management action occurred. Even with a VPC endpoint, flow logs would only show TLS connections to S3, not the API calls themselves.

Trap 2: Configure an AWS Config rule to detect changes and invoke a Lambda…

AWS Config records and evaluates resource configuration changes, not individual IAM or API calls. A Config rule with Lambda remediation could react to a bucket policy becoming noncompliant, but it runs on a periodic or configuration-change basis and is not designed for immediate per-event alerting. The requirement is to alert on the PutBucketPolicy call itself, which only a CloudTrail/EventBridge pattern can match.

Trap 3: Enable S3 server access logs and parse them for PutBucketPolicy…

S3 server access logs record object-level requests such as GET, PUT, and DELETE on bucket objects; they do not include management-plane API calls like PutBucketPolicy. These logs are delivered in batches to a destination bucket, making them suitable for access auditing rather than immediate alerting. The requested action affects the bucket's configuration, so it appears only in CloudTrail, not in server access logs.

Study all Security Logging and Monitoring common traps →

A
Enable VPC Flow Logs and analyze for S3 API traffic
Why wrong: VPC Flow Logs capture IP traffic metadata—source and destination addresses, ports, and protocols—at the network interface level. They do not contain the S3 API operation name (such as PutBucketPolicy) or the request body, so you cannot identify which management action occurred. Even with a VPC endpoint, flow logs would only show TLS connections to S3, not the API calls themselves.
B
Configure an AWS Config rule to detect changes and invoke a Lambda function
Why wrong: AWS Config records and evaluates resource configuration changes, not individual IAM or API calls. A Config rule with Lambda remediation could react to a bucket policy becoming noncompliant, but it runs on a periodic or configuration-change basis and is not designed for immediate per-event alerting. The requirement is to alert on the PutBucketPolicy call itself, which only a CloudTrail/EventBridge pattern can match.
C
Create an Amazon CloudWatch Events rule that matches the PutBucketPolicy API call and triggers an SNS notification
Create an Amazon CloudWatch Events (now Amazon EventBridge) rule with an event pattern matching the `detail-type` of `AWS API Call via CloudTrail`, the `eventSource` as `s3.amazonaws.com`, and `eventName` as `PutBucketPolicy`. When CloudTrail logs that IAM API call, the rule triggers an SNS topic to notify the security engineer in near real time. This is the native AWS approach for reacting to control-plane actions.
D
Enable S3 server access logs and parse them for PutBucketPolicy entries
Why wrong: S3 server access logs record object-level requests such as GET, PUT, and DELETE on bucket objects; they do not include management-plane API calls like PutBucketPolicy. These logs are delivered in batches to a destination bucket, making them suitable for access auditing rather than immediate alerting. The requested action affects the bucket's configuration, so it appears only in CloudTrail, not in server access logs.

Full breakdown with real-world context →

Question 4mediummultiple choice

Read the full Security Logging and Monitoring explanation →

A company uses Amazon GuardDuty and wants to suppress low-severity findings that are known false positives. What is the recommended approach?

Trap 1: Configure a CloudWatch Events rule to ignore the findings

CloudWatch Events (now Amazon EventBridge) can route GuardDuty findings to downstream targets like Lambda functions or SNS topics, but an event rule merely reacts to findings; it does not modify GuardDuty's internal state or remove them from the console. The finding remains active and visible in GuardDuty, whether or not the rule chooses to act on it, because the rule is a consumer of the finding stream, not a control on the detector. Thus, configuring a rule to 'ignore' findings has no effect on the GuardDuty console listing.

Trap 2: Manually delete the findings from the GuardDuty console

GuardDuty findings are immutable records of security-relevant activity; the service provides no delete operation in either the console or the API. You can archive findings, which moves them out of the active list, but archiving does not delete the finding and does not prevent the same finding type from recurring. Manual deletion is simply not possible, so the only effective suppression mechanism is a filter with conditions that exclude the false-positive pattern.

Trap 3: Disable the GuardDuty detector for the affected accounts

Disabling the GuardDuty detector is a region-level switch that stops all threat detection and halts generation of every finding type for that account, not just the low-severity item you want to suppress. This also suspends access to the findings list (or stops updates to existing findings) and disables downstream integrations such as EventBridge and Security Hub, so real high-severity threats would go unnoticed. Suppressing a single false positive should never require giving up all visibility into that account, which is why filters are the correct approach.

Study all Security Logging and Monitoring common traps →

A
Configure a CloudWatch Events rule to ignore the findings
Why wrong: CloudWatch Events (now Amazon EventBridge) can route GuardDuty findings to downstream targets like Lambda functions or SNS topics, but an event rule merely reacts to findings; it does not modify GuardDuty's internal state or remove them from the console. The finding remains active and visible in GuardDuty, whether or not the rule chooses to act on it, because the rule is a consumer of the finding stream, not a control on the detector. Thus, configuring a rule to 'ignore' findings has no effect on the GuardDuty console listing.
B
Manually delete the findings from the GuardDuty console
Why wrong: GuardDuty findings are immutable records of security-relevant activity; the service provides no delete operation in either the console or the API. You can archive findings, which moves them out of the active list, but archiving does not delete the finding and does not prevent the same finding type from recurring. Manual deletion is simply not possible, so the only effective suppression mechanism is a filter with conditions that exclude the false-positive pattern.
C
Disable the GuardDuty detector for the affected accounts
Why wrong: Disabling the GuardDuty detector is a region-level switch that stops all threat detection and halts generation of every finding type for that account, not just the low-severity item you want to suppress. This also suspends access to the findings list (or stops updates to existing findings) and disables downstream integrations such as EventBridge and Security Hub, so real high-severity threats would go unnoticed. Suppressing a single false positive should never require giving up all visibility into that account, which is why filters are the correct approach.
D
Create a GuardDuty filter to suppress the findings
GuardDuty filters let you define conditions on finding attributes like severity, type, or resource tags, and when you enable the 'suppress' option, findings matching the filter are automatically hidden from the console's active findings list. Unlike archiving or deletion, this is a non-destructive suppression: the underlying findings remain in your history and are still accessible via the API, so audit trails stay intact. This is the intended mechanism for handling known false positives, and filters can be shared or applied via AWS Organizations to suppress consistently across accounts.

Full breakdown with real-world context →

Question 5hardmultiple choice

Read the full Security Logging and Monitoring explanation →

A company stores sensitive data in Amazon S3 and wants to detect and alert on any public read access to objects. Which combination of services provides the most comprehensive solution?

Trap 1: Enable VPC Flow Logs and analyze for S3 traffic

VPC Flow Logs capture IP-level traffic metadata such as source/destination addresses, ports, and protocol, but they do not record S3 API actions like GetObject, nor the S3 bucket name, object key, or requester identity. For traffic through a gateway endpoint, flow logs only show traffic to the S3 service prefix and cannot differentiate between public and private or identify whether an object was actually read. Therefore, analyzing flow logs cannot detect specific unauthorized reads of sensitive S3 data.

Trap 2: Use AWS Config rules to check for public bucket policies and alert…

AWS Config rules evaluate the configuration of S3 buckets, such as whether bucket policies or ACLs grant public access, but they do not monitor or log individual object access events. A rule can alert you to a misconfigured public policy, but it cannot tell you whether an actual GET request was made by an anonymous user or which object was accessed. Thus, this approach fails to detect ongoing public reads or provide an audit trail of data exposure.

Trap 3: Enable S3 event notifications for all object-level events and send…

S3 event notifications support only specific object-level event types such as ObjectCreated, ObjectRemoved, and ObjectRestore, but they do not generate events for GET/read operations. Even if you enable all available event types, the notification payload does not include the requester's identity and cannot distinguish public from private access. Consequently, event notifications cannot detect or alert on anonymous reads of sensitive objects.

Study all Security Logging and Monitoring common traps →

A
Enable VPC Flow Logs and analyze for S3 traffic
Why wrong: VPC Flow Logs capture IP-level traffic metadata such as source/destination addresses, ports, and protocol, but they do not record S3 API actions like GetObject, nor the S3 bucket name, object key, or requester identity. For traffic through a gateway endpoint, flow logs only show traffic to the S3 service prefix and cannot differentiate between public and private or identify whether an object was actually read. Therefore, analyzing flow logs cannot detect specific unauthorized reads of sensitive S3 data.
B
Use AWS Config rules to check for public bucket policies and alert via SNS
Why wrong: AWS Config rules evaluate the configuration of S3 buckets, such as whether bucket policies or ACLs grant public access, but they do not monitor or log individual object access events. A rule can alert you to a misconfigured public policy, but it cannot tell you whether an actual GET request was made by an anonymous user or which object was accessed. Thus, this approach fails to detect ongoing public reads or provide an audit trail of data exposure.
C
Enable S3 server access logging and use Amazon Athena to query logs, with CloudWatch Events to alert on specific patterns
S3 server access logging produces detailed log records containing the requester, bucket name, object key, action string (e.g., REST.GET.OBJECT), and response status for each API call. Querying these logs with Amazon Athena lets you filter for the 'Anonymous' requester and identify specific objects being read publicly. A scheduled Athena query orchestrated via CloudWatch Events (now Amazon EventBridge) can publish findings to SNS or Lambda, enabling alerting on suspicious read patterns.
D
Enable S3 event notifications for all object-level events and send to Amazon SNS
Why wrong: S3 event notifications support only specific object-level event types such as ObjectCreated, ObjectRemoved, and ObjectRestore, but they do not generate events for GET/read operations. Even if you enable all available event types, the notification payload does not include the requester's identity and cannot distinguish public from private access. Consequently, event notifications cannot detect or alert on anonymous reads of sensitive objects.

Full breakdown with real-world context →

Question 6easymultiple choice

Read the full Security Logging and Monitoring explanation →

A security engineer needs to centrally collect and analyze AWS CloudTrail logs from multiple accounts. Which service is designed for this purpose?

Trap 1: Configure each account to send logs to a central S3 bucket

While you can technically configure every member account to run its own CloudTrail trail and write to the same central S3 bucket, this requires manually distributing bucket policies, creating a trail in each account, and reconciling overlapping permissions. It is brittle because you must monitor each account separately for trail health, and it does not natively capture new accounts that join the organization unless you update them individually. AWS's designed approach for multi-account CloudTrail is an organization trail, not ad-hoc per-account delivery to a common bucket.

Trap 2: Enable Amazon GuardDuty in each account and aggregate findings

Amazon GuardDuty is a threat detection service that consumes CloudTrail management events, VPC Flow Logs, and DNS logs to generate security findings; it does not collect or archive raw CloudTrail log files. It can aggregate findings into a central account using GuardDuty administrator/member relationships, but that gives you findings, not the underlying API logs you need for full audit analysis. For central collection and analysis of CloudTrail logs, you need a delivery mechanism like S3 or CloudWatch Logs, not GuardDuty.

Trap 3: Use Amazon CloudWatch Logs to stream logs from each account to a…

CloudTrail can stream events to CloudWatch Logs in each account, and those log groups can be cross-account subscribed to a central account, but this pipeline introduces added latency, log-group limits, and metric-filter overhead. CloudWatch Logs is suited for real-time alarms and operational monitoring, not for durable, reviewable long-term audit archives, and using it as the primary transport misses the single-trail simplicity of an organization trail. An organization trail can optionally deliver to CloudWatch Logs in the management account while also archiving raw JSON in S3.

Study all Security Logging and Monitoring common traps →

A
Configure each account to send logs to a central S3 bucket
Why wrong: While you can technically configure every member account to run its own CloudTrail trail and write to the same central S3 bucket, this requires manually distributing bucket policies, creating a trail in each account, and reconciling overlapping permissions. It is brittle because you must monitor each account separately for trail health, and it does not natively capture new accounts that join the organization unless you update them individually. AWS's designed approach for multi-account CloudTrail is an organization trail, not ad-hoc per-account delivery to a common bucket.
B
Enable Amazon GuardDuty in each account and aggregate findings
Why wrong: Amazon GuardDuty is a threat detection service that consumes CloudTrail management events, VPC Flow Logs, and DNS logs to generate security findings; it does not collect or archive raw CloudTrail log files. It can aggregate findings into a central account using GuardDuty administrator/member relationships, but that gives you findings, not the underlying API logs you need for full audit analysis. For central collection and analysis of CloudTrail logs, you need a delivery mechanism like S3 or CloudWatch Logs, not GuardDuty.
C
Use Amazon CloudWatch Logs to stream logs from each account to a central account
Why wrong: CloudTrail can stream events to CloudWatch Logs in each account, and those log groups can be cross-account subscribed to a central account, but this pipeline introduces added latency, log-group limits, and metric-filter overhead. CloudWatch Logs is suited for real-time alarms and operational monitoring, not for durable, reviewable long-term audit archives, and using it as the primary transport misses the single-trail simplicity of an organization trail. An organization trail can optionally deliver to CloudWatch Logs in the management account while also archiving raw JSON in S3.
D
Use AWS Organizations to create a CloudTrail trail that applies to all accounts
Using AWS Organizations, you can create an organization trail from the management account that automatically logs CloudTrail management events for every account in the organization, including future accounts, with no per-account configuration. The trail delivers log files to a single designated S3 bucket in the management account, enabling centralized collection and analysis through Athena, QuickSight, or other tools. This is the native, designed method for centralizing CloudTrail logs across multiple accounts.

Full breakdown with real-world context →

Question 7mediummultiple choice

Read the full Security Logging and Monitoring explanation →

A company uses AWS CloudTrail and wants to ensure that any modification to the trail itself is detected immediately. What should be done?

Trap 1: Configure Amazon GuardDuty to monitor for trail modifications

Amazon GuardDuty consumes CloudTrail management and S3 data events to detect threats like credential exfiltration or malicious API activity, but it does not inspect or alert on the configuration state of the CloudTrail service itself. An attacker who disables a trail via StopLogging would not generate a GuardDuty finding, because GuardDuty treats CloudTrail's own control-plane calls as data rather than as a signal to act on. Consequently, this approach leaves the trail modification unnoticed.

Trap 2: Enable CloudTrail Insights to detect unusual activity

CloudTrail Insights uses machine learning to detect anomalous write API activity by establishing baseline patterns of your account's normal behavior, not to react to administrative configuration changes. A single StopLogging or UpdateTrail call is an expected, low-volume management event that would not be flagged as an anomaly, and Insights must be enabled on the trail itself, so if the trail is stopped, insight monitoring also stops. Thus, it fails to provide the immediate, deterministic alert required for trail integrity.

Trap 3: Enable S3 event notifications on the trail's S3 bucket

S3 event notifications on the trail's bucket are configured for s3:ObjectCreated and similar object-level events, so they only fire when new log files are delivered, not when a trail's configuration is altered. If an attacker calls StopLogging or UpdateTrail, no new object lands in the bucket, so no notification is sent; moreover, such calls are control-plane operations outside S3's data path. This approach also generates substantial noise from normal log delivery and can be bypassed simply by redirecting the trail to another bucket.

Study all Security Logging and Monitoring common traps →

A
Configure Amazon GuardDuty to monitor for trail modifications
Why wrong: Amazon GuardDuty consumes CloudTrail management and S3 data events to detect threats like credential exfiltration or malicious API activity, but it does not inspect or alert on the configuration state of the CloudTrail service itself. An attacker who disables a trail via StopLogging would not generate a GuardDuty finding, because GuardDuty treats CloudTrail's own control-plane calls as data rather than as a signal to act on. Consequently, this approach leaves the trail modification unnoticed.
B
Enable CloudTrail Insights to detect unusual activity
Why wrong: CloudTrail Insights uses machine learning to detect anomalous write API activity by establishing baseline patterns of your account's normal behavior, not to react to administrative configuration changes. A single StopLogging or UpdateTrail call is an expected, low-volume management event that would not be flagged as an anomaly, and Insights must be enabled on the trail itself, so if the trail is stopped, insight monitoring also stops. Thus, it fails to provide the immediate, deterministic alert required for trail integrity.
C
Create a CloudWatch Events rule that matches the StopLogging or UpdateTrail API calls and sends an alert
The correct solution is a CloudWatch Events rule (now Amazon EventBridge) that matches the management events CloudTrail emits for the StopLogging, UpdateTrail, or DeleteTrail API calls, using an event pattern with source 'aws.cloudtrail' and eventName in the list. When such a call occurs, the rule triggers an SNS topic or Lambda function to notify security teams in near real-time. This works because CloudTrail delivers every management event to CloudWatch Events as a default integration, including the very call that disables logging.
D
Enable S3 event notifications on the trail's S3 bucket
Why wrong: S3 event notifications on the trail's bucket are configured for s3:ObjectCreated and similar object-level events, so they only fire when new log files are delivered, not when a trail's configuration is altered. If an attacker calls StopLogging or UpdateTrail, no new object lands in the bucket, so no notification is sent; moreover, such calls are control-plane operations outside S3's data path. This approach also generates substantial noise from normal log delivery and can be bypassed simply by redirecting the trail to another bucket.

Full breakdown with real-world context →

Question 8hardmulti select

Read the full Security Logging and Monitoring explanation →

A company wants to use AWS CloudTrail to monitor data events for all S3 buckets. Which THREE steps are necessary? (Choose THREE.)

Trap 1: Create a CloudWatch Events rule to forward data events

A CloudWatch Events rule (now Amazon EventBridge) is used to route matching events to targets for automation or fan-out, not to enable logging of data events. CloudTrail writes data events directly from the S3 bucket to the configured S3 destination as part of the trail, so no additional forwarding rule is required. Adding such a rule would only create unnecessary complexity and potential duplicate processing.

Trap 2: Enable CloudTrail Insights to detect unusual data access

CloudTrail Insights is an optional, paid feature that uses machine learning to identify anomalous API activity and deviations in normal access patterns, such as unusual S3 GetObject bursts. Enabling it does not affect whether data events themselves are logged; it simply provides an additional layer of detection. For basic monitoring of data events, you do not need to enable Insights.

Study all Security Logging and Monitoring common traps →

A
Specify an S3 bucket to store the log files
CloudTrail delivers all log records, including the enabled S3 data events, to the S3 bucket you specify when creating the trail. This bucket is the required durable destination for log file storage, and without it, event history is limited to 90 days and cannot be exported or integrated with other analytics tools.
B
Create a new CloudTrail trail
A trail is the core CloudTrail resource that defines where events are delivered and which event types (management, data, or insights) are captured. You must create a new trail to persist S3 data events beyond the default 90-day event history, which does not include object-level operations. The trail can be applied to all regions or a single region as needed.
C
Create a CloudWatch Events rule to forward data events
Why wrong: A CloudWatch Events rule (now Amazon EventBridge) is used to route matching events to targets for automation or fan-out, not to enable logging of data events. CloudTrail writes data events directly from the S3 bucket to the configured S3 destination as part of the trail, so no additional forwarding rule is required. Adding such a rule would only create unnecessary complexity and potential duplicate processing.
D
Enable CloudTrail Insights to detect unusual data access
Why wrong: CloudTrail Insights is an optional, paid feature that uses machine learning to identify anomalous API activity and deviations in normal access patterns, such as unusual S3 GetObject bursts. Enabling it does not affect whether data events themselves are logged; it simply provides an additional layer of detection. For basic monitoring of data events, you do not need to enable Insights.
E
Enable data events for all S3 buckets in the trail configuration
Even after creating a trail and specifying a destination bucket, you must explicitly select 'S3 bucket' as a data event source and choose 'All S3 buckets' (or individual buckets) in the trail's data events configuration. This step activates capture of object-level events like GetObject, PutObject, and DeleteObject; without it, only management events are recorded. This configuration is essential to meet the requirement to monitor S3 data events.

Full breakdown with real-world context →

Question 9hardmultiple choice

Read the full Security Logging and Monitoring explanation →

Refer to the exhibit. A security engineer reviews a CloudTrail log entry. What is the MOST concerning security issue?

Exhibit

Refer to the exhibit.

```
{
  "Records": [
    {
      "eventVersion": "1.08",
      "userIdentity": {
        "type": "Root",
        "arn": "arn:aws:iam::123456789012:root",
        "accountId": "123456789012"
      },
      "eventTime": "2023-09-01T12:34:56Z",
      "eventSource": "ec2.amazonaws.com",
      "eventName": "AuthorizeSecurityGroupIngress",
      "sourceIPAddress": "203.0.113.5",
      "userAgent": "console.amazonaws.com",
      "requestParameters": {
        "groupId": "sg-12345678",
        "ipPermissions": {
          "items": [
            {
              "ipProtocol": "tcp",
              "fromPort": 22,
              "toPort": 22,
              "ipRanges": [
                {
                  "cidrIp": "0.0.0.0/0"
                }
              ]
            }
          ]
        }
      },
      "responseElements": null
    }
  ]
}
```

Trap 1: The security group rule allows SSH from 0.0.0.0/0

The security group rule permitting SSH from 0.0.0.0/0 is a legitimate network exposure that broadens the attack surface for unauthorized access, but it is an infrastructure misconfiguration separate from this CloudTrail event. While it should be remediated by restricting inbound SSH to trusted CIDRs, it does not directly explain why a CloudTrail log entry should be flagged as a security incident. The more immediate and severe concern in this log is the use of the AWS account root user, because AWS best practices mandate eliminating routine root user access entirely.

Trap 2: The API call failed as indicated by null response elements

Null responseElements in a CloudTrail event can simply indicate that the API call returned no output or that an error such as AccessDenied occurred; it is not a definitive sign of a failed call. Even when a call fails, CloudTrail still logs the event, so the mere presence of null responseElements does not identify a security risk. The root user identity in the event, however, is an explicit and actionable security finding, whereas responseElements alone would not tell you whether the account has been compromised or whether IAM governance has failed.

Trap 3: The request came from an external IP address

Seeing an external IP address as the source of an API request is normal because AWS APIs are typically accessed over the internet, unless a VPC endpoint or AWS PrivateLink is used for private connectivity. A single external IP does not indicate whether the caller is an authorized administrator or an attacker, so it is not a meaningful security finding without additional context such as geographic anomalies, historical behavior, or matching threat intelligence. This makes the external IP less critical than the fact that the request was made by the root user, which is an identity-based security violation that directly indicates risk.

Study all Security Logging and Monitoring common traps →

A
The security group rule allows SSH from 0.0.0.0/0
Why wrong: The security group rule permitting SSH from 0.0.0.0/0 is a legitimate network exposure that broadens the attack surface for unauthorized access, but it is an infrastructure misconfiguration separate from this CloudTrail event. While it should be remediated by restricting inbound SSH to trusted CIDRs, it does not directly explain why a CloudTrail log entry should be flagged as a security incident. The more immediate and severe concern in this log is the use of the AWS account root user, because AWS best practices mandate eliminating routine root user access entirely.
B
The root user is performing actions
The root user performing actions is the correct security concern because AWS account root user credentials are the most privileged and are intended only for a limited set of account-level tasks, such as changing support plans or closing the account. CloudTrail records this event with userIdentity.type = "Root", and any API call made by the root user during routine operations is a direct violation of IAM best practices and a strong signal of a compromised or poorly governed account. Root user activity bypasses fine-grained IAM permissions, may not have MFA enabled, and cannot be scoped down, making it the primary risk that must be investigated immediately.
C
The API call failed as indicated by null response elements
Why wrong: Null responseElements in a CloudTrail event can simply indicate that the API call returned no output or that an error such as AccessDenied occurred; it is not a definitive sign of a failed call. Even when a call fails, CloudTrail still logs the event, so the mere presence of null responseElements does not identify a security risk. The root user identity in the event, however, is an explicit and actionable security finding, whereas responseElements alone would not tell you whether the account has been compromised or whether IAM governance has failed.
D
The request came from an external IP address
Why wrong: Seeing an external IP address as the source of an API request is normal because AWS APIs are typically accessed over the internet, unless a VPC endpoint or AWS PrivateLink is used for private connectivity. A single external IP does not indicate whether the caller is an authorized administrator or an attacker, so it is not a meaningful security finding without additional context such as geographic anomalies, historical behavior, or matching threat intelligence. This makes the external IP less critical than the fact that the request was made by the root user, which is an identity-based security violation that directly indicates risk.

Full breakdown with real-world context →

Question 10mediummultiple choice

Read the full Security Logging and Monitoring explanation →

Refer to the exhibit. A security engineer reviews the CloudTrail trail configuration. What is a security concern?

Exhibit

Refer to the exhibit.

```
{
  "configuration": {
    "name": "my-trail",
    "s3BucketName": "my-cloudtrail-logs",
    "includeGlobalServiceEvents": true,
    "isMultiRegionTrail": true,
    "enableLogFileValidation": true,
    "cloudWatchLogsLogGroupArn": "arn:aws:logs:us-east-1:123456789012:log-group:aws-cloudtrail-logs:*",
    "cloudWatchLogsRoleArn": "arn:aws:iam::123456789012:role/CloudTrail_CloudWatchLogs_Role",
    "kmsKeyId": null
  }
}
```

Trap 1: The trail is not multi-region

The exhibit shows the trail is configured with `isMultiRegionTrail: true`, so this option is incorrect. A multi-region trail records API events from every AWS region into the same S3 bucket, while a single-region trail only captures events for the region where the trail was created. Because this trail is already multi-region, the lack of multi-region coverage is not a valid security finding.

Trap 2: Log file validation is not enabled

The claim that log file validation is not enabled is wrong because the trail configuration includes `enableLogFileValidation: true`. When log file validation is enabled, CloudTrail periodically creates digest files that contain hashes of the delivered log files and signs them with a private key, allowing you to detect if a log was altered or deleted after delivery. Since this trail already has validation enabled, it is not a security deficiency in this scenario.

Trap 3: CloudWatch Logs integration is missing

CloudWatch Logs integration is present because the exhibit shows `cloudWatchLogsLogGroupArn` configured, so this option is incorrect. The trail is streaming events to a CloudWatch Logs group, which enables real-time alarms, metric filters, and querying of API activity. If the ARN were absent or the IAM role were misconfigured, this would be a valid concern, but the configuration clearly indicates the integration exists.

Study all Security Logging and Monitoring common traps →

A
The trail is not multi-region
Why wrong: The exhibit shows the trail is configured with `isMultiRegionTrail: true`, so this option is incorrect. A multi-region trail records API events from every AWS region into the same S3 bucket, while a single-region trail only captures events for the region where the trail was created. Because this trail is already multi-region, the lack of multi-region coverage is not a valid security finding.
B
The logs are not encrypted with a customer-managed KMS key
The real security gap is that `kmsKeyId` is null, meaning the CloudTrail log files are encrypted with S3-managed keys (SSE-S3) rather than a customer-managed AWS KMS key. With SSE-S3, AWS handles all key management, so the security team cannot control key rotation, define key policies, or revoke access for investigative or compliance purposes. Configuring a KMS key enables envelope encryption, provides a separate audit trail for KMS decrypt operations, and is the more secure option for CloudTrail log protection.
C
Log file validation is not enabled
Why wrong: The claim that log file validation is not enabled is wrong because the trail configuration includes `enableLogFileValidation: true`. When log file validation is enabled, CloudTrail periodically creates digest files that contain hashes of the delivered log files and signs them with a private key, allowing you to detect if a log was altered or deleted after delivery. Since this trail already has validation enabled, it is not a security deficiency in this scenario.
D
CloudWatch Logs integration is missing
Why wrong: CloudWatch Logs integration is present because the exhibit shows `cloudWatchLogsLogGroupArn` configured, so this option is incorrect. The trail is streaming events to a CloudWatch Logs group, which enables real-time alarms, metric filters, and querying of API activity. If the ARN were absent or the IAM role were misconfigured, this would be a valid concern, but the configuration clearly indicates the integration exists.

Full breakdown with real-world context →

Question 11easymultiple choice

Read the full Security Logging and Monitoring explanation →

A security engineer wants to receive real-time notifications when an AWS API call is made to delete an S3 bucket. Which service should be used to capture and forward these events to an Amazon SNS topic?

Trap 1: AWS Trusted Advisor

AWS Trusted Advisor is incorrect because it is a best-practice assessment service that periodically checks your AWS environment against categories like cost optimization, security, fault tolerance, and service limits. It runs checks on a recurring schedule, not in real time, and it does not process or stream individual API calls such as DeleteBucket. Trusted Advisor surfaces recommendations in the console and can send weekly notifications, but it cannot be configured with an event filter to immediately alert you when a specific API call occurs. Therefore it lacks the real-time event-driven capability required here.

Trap 2: Amazon GuardDuty

Amazon GuardDuty is incorrect because it is a threat detection service that continuously analyzes VPC Flow Logs, DNS logs, and CloudTrail management events using machine learning and threat intelligence to identify suspicious behavior. While GuardDuty can produce findings and send those findings to SNS for notification, it does not directly forward raw API call events like DeleteBucket in real time; its purpose is to detect anomalies and known threats, not to provide a generic real-time event stream of every API action. The finding generation process itself introduces delays and is tailored to security threats rather than operational events, so it does not meet the requirement for direct, immediate API call notifications.

Trap 3: AWS Config

AWS Config is incorrect because it is a configuration management and compliance service that records changes to resource configurations and evaluates them against rules you define. It tracks the state of resources over time and can deliver configuration history and snapshot updates to SNS, but it does not provide real-time notifications for individual API calls like DeleteBucket. Config focuses on what a resource looks like after a change, not the API action that triggered the change, and its notifications are tied to configuration item changes, which occur asynchronously and are not the same as CloudTrail's event-level API alerts. Hence, it is not a suitable mechanism for real-time API call notification.

Study all Security Logging and Monitoring common traps →

A
AWS CloudTrail with CloudWatch Events
AWS CloudTrail with CloudWatch Events is the correct choice because CloudTrail records all AWS API calls as events, and CloudWatch Events (now Amazon EventBridge) can evaluate those events in near real time using an event pattern that matches specific actions like S3 DeleteBucket. When the pattern matches, it immediately triggers an SNS topic to send notifications. This architecture gives you direct, low-latency alerting on API activity, which is exactly what the security engineer needs. Unlike the other options, it is purpose-built for reacting to individual API calls as they happen.
B
AWS Trusted Advisor
Why wrong: AWS Trusted Advisor is incorrect because it is a best-practice assessment service that periodically checks your AWS environment against categories like cost optimization, security, fault tolerance, and service limits. It runs checks on a recurring schedule, not in real time, and it does not process or stream individual API calls such as DeleteBucket. Trusted Advisor surfaces recommendations in the console and can send weekly notifications, but it cannot be configured with an event filter to immediately alert you when a specific API call occurs. Therefore it lacks the real-time event-driven capability required here.
C
Amazon GuardDuty
Why wrong: Amazon GuardDuty is incorrect because it is a threat detection service that continuously analyzes VPC Flow Logs, DNS logs, and CloudTrail management events using machine learning and threat intelligence to identify suspicious behavior. While GuardDuty can produce findings and send those findings to SNS for notification, it does not directly forward raw API call events like DeleteBucket in real time; its purpose is to detect anomalies and known threats, not to provide a generic real-time event stream of every API action. The finding generation process itself introduces delays and is tailored to security threats rather than operational events, so it does not meet the requirement for direct, immediate API call notifications.
D
AWS Config
Why wrong: AWS Config is incorrect because it is a configuration management and compliance service that records changes to resource configurations and evaluates them against rules you define. It tracks the state of resources over time and can deliver configuration history and snapshot updates to SNS, but it does not provide real-time notifications for individual API calls like DeleteBucket. Config focuses on what a resource looks like after a change, not the API action that triggered the change, and its notifications are tied to configuration item changes, which occur asynchronously and are not the same as CloudTrail's event-level API alerts. Hence, it is not a suitable mechanism for real-time API call notification.

Full breakdown with real-world context →

Question 12easymulti select

Read the full Security Logging and Monitoring explanation →

A security engineer is designing a monitoring solution for a multi-account AWS environment using AWS Organizations. The solution must provide a centralized view of all API activities and send alerts for suspicious events. Which TWO services together can achieve this? (Choose TWO.)

Trap 1: Amazon GuardDuty

Amazon GuardDuty is a threat detection service that analyzes VPC Flow Logs, DNS query logs, and AWS CloudTrail management events to identify malicious activity and compromised credentials. It does not itself capture or retain an authoritative record of every API call; instead it consumes CloudTrail events as a source, so it cannot serve as the centralized API activity log for auditing or compliance. Its output is a prioritized list of findings, not a complete queryable history of API actions.

Trap 2: AWS Lambda

AWS Lambda is a serverless compute service that runs code in response to events; it can process or transform log records, but it has no native capability to capture AWS API activity. Without a separate service such as CloudTrail to generate the events, Lambda has nothing to ingest, and it does not provide persistent storage, search, or an audit trail on its own. Using Lambda would require you to build custom ingestion, storage, and alerting logic, making it an implementation component rather than a centralized monitoring service.

Trap 3: AWS Config

AWS Config records the configuration state and changes of AWS resources over time, evaluating them against desired policies such as whether an S3 bucket is publicly accessible, but it does not capture the individual API calls or the identity that made them. While Config can reference CloudTrail events to understand what changed a resource, it is not an API activity log and its primary purpose is configuration compliance, not monitoring every action. Therefore, it cannot substitute for CloudTrail when you need a complete record of API activity across accounts.

Study all Security Logging and Monitoring common traps →

A
Amazon GuardDuty
Why wrong: Amazon GuardDuty is a threat detection service that analyzes VPC Flow Logs, DNS query logs, and AWS CloudTrail management events to identify malicious activity and compromised credentials. It does not itself capture or retain an authoritative record of every API call; instead it consumes CloudTrail events as a source, so it cannot serve as the centralized API activity log for auditing or compliance. Its output is a prioritized list of findings, not a complete queryable history of API actions.
B
AWS Lambda
Why wrong: AWS Lambda is a serverless compute service that runs code in response to events; it can process or transform log records, but it has no native capability to capture AWS API activity. Without a separate service such as CloudTrail to generate the events, Lambda has nothing to ingest, and it does not provide persistent storage, search, or an audit trail on its own. Using Lambda would require you to build custom ingestion, storage, and alerting logic, making it an implementation component rather than a centralized monitoring service.
C
AWS CloudTrail
AWS CloudTrail records management events (and optionally data events) for every API call made in an AWS account, capturing the identity, source IP, time, request parameters, and response elements. When enabled for an AWS Organization, you can create an organization trail that logs events for all accounts and delivers them to a single Amazon S3 bucket, enabling centralized auditing. This makes CloudTrail the definitive source of API activity for security monitoring, compliance, and forensic investigation.
D
Amazon CloudWatch Logs
Amazon CloudWatch Logs can aggregate CloudTrail logs by receiving them from an S3 bucket via a CloudWatch Logs subscription, and then use metric filters to detect patterns such as unauthorized API calls or IAM policy changes, triggering CloudWatch Alarms. It provides centralized storage, search, and monitoring across accounts when configured in a central logging account. However, CloudWatch Logs is the destination and analysis layer; it is not the source of API call records and depends on CloudTrail or other log producers to supply the data.
E
AWS Config
Why wrong: AWS Config records the configuration state and changes of AWS resources over time, evaluating them against desired policies such as whether an S3 bucket is publicly accessible, but it does not capture the individual API calls or the identity that made them. While Config can reference CloudTrail events to understand what changed a resource, it is not an API activity log and its primary purpose is configuration compliance, not monitoring every action. Therefore, it cannot substitute for CloudTrail when you need a complete record of API activity across accounts.

Full breakdown with real-world context →

Question 13hardmulti select

Review the full subnetting walkthrough →

A company runs a critical application on an Auto Scaling group of EC2 instances behind an Application Load Balancer. The security team enabled VPC Flow Logs, CloudTrail, and CloudWatch Logs for the application tier. Recently, they noticed that some EC2 instances are being terminated unexpectedly by an unknown IAM user. The CloudTrail logs show the TerminateInstances API call, but the source IP address is from within the VPC CIDR range. The security team suspects the action is coming from an EC2 instance that has been compromised. They need to identify the specific compromised instance and the IAM role it used. Which combination of steps will provide the necessary information? (Choose TWO.)

Trap 1: Use AWS Config to find all EC2 instances that were terminated…

AWS Config only records the configuration history of resources, so it can show that certain instances transitioned to a terminated state, but it does not log who initiated the termination or from which IP. CloudTrail's TerminateInstances event contains the target instance IDs but not the source instance’s ID; the source is defined by the IAM principal, not by the instance being terminated. Therefore, using the termination event’s instance ID to identify the compromised source is logically incorrect and will lead to the wrong instance.

Trap 2: Check the CloudWatch Logs for the Auto Scaling group to find any…

CloudWatch Logs for an Auto Scaling group capture scaling activities like instance launches and terminations, but they do not contain the API request details or the IAM identity that called TerminateInstances. Correlating these logs with CloudTrail would still require additional manual investigation, as the CloudTrail event would already provide the authoritative actor and source IP. Manually checking every instance’s IAM role is an unscalable, error-prone process that could miss the compromised instance entirely and does not leverage the forensics data available in VPC Flow Logs.

Study all Security Logging and Monitoring common traps →

A
Review the VPC Flow Logs for any traffic to the EC2 API endpoint. Look for the source IP that made the API call. Then use that IP to find the instance in the EC2 console. Check the IAM role attached to that instance.
VPC Flow Logs capture the network traffic between EC2 instances and the EC2 API endpoint, recording the source private IP and destination IP for each connection. By filtering Flow Logs for the API endpoint’s IP address on port 443 around the time of the termination event, you can identify the source IP and then match that IP to a specific ENI and EC2 instance in the console. Once the instance is identified, you can inspect its attached IAM role to see which credentials were used for the unauthorized call.
B
Examine the CloudTrail event for TerminateInstances and note the 'userIdentity' field to identify the IAM role. Then use the 'sourceIPAddress' field to find the instance's private IP. Cross-reference with VPC Flow Logs to find the network interface with that IP at the time of the event.
CloudTrail's TerminateInstances event stores a `userIdentity` object that reveals the IAM role assumed by the source, and a `sourceIPAddress` field that typically contains the private IP of the calling instance or the public IP of a NAT gateway. Using the timestamp and that source IP, you can query VPC Flow Logs to find the network interface that owned the IP at that exact moment, thereby isolating the specific EC2 instance. This method is precise because it directly correlates the CloudTrail actor identity with the ENI-level network flow data.
C
Use AWS Config to find all EC2 instances that were terminated around that time. Then check the CloudTrail event for the IAM role. Finally, use the instance ID from the termination event to identify the source.
Why wrong: AWS Config only records the configuration history of resources, so it can show that certain instances transitioned to a terminated state, but it does not log who initiated the termination or from which IP. CloudTrail's TerminateInstances event contains the target instance IDs but not the source instance’s ID; the source is defined by the IAM principal, not by the instance being terminated. Therefore, using the termination event’s instance ID to identify the compromised source is logically incorrect and will lead to the wrong instance.
D
Check the CloudWatch Logs for the Auto Scaling group to find any error messages around the termination time. Correlate with the CloudTrail event to identify the IAM role. Then use the EC2 console to list all instances and check their IAM roles manually.
Why wrong: CloudWatch Logs for an Auto Scaling group capture scaling activities like instance launches and terminations, but they do not contain the API request details or the IAM identity that called TerminateInstances. Correlating these logs with CloudTrail would still require additional manual investigation, as the CloudTrail event would already provide the authoritative actor and source IP. Manually checking every instance’s IAM role is an unscalable, error-prone process that could miss the compromised instance entirely and does not leverage the forensics data available in VPC Flow Logs.

Full breakdown with real-world context →

Question 14easymultiple choice

Read the full Security Logging and Monitoring explanation →

A security engineer needs to ensure that all API calls made in an AWS account are captured and retained for auditing purposes. The engineer must be able to query the logs for specific user activity over the past 90 days. Which AWS service should the engineer use to meet these requirements?

Trap 1: Amazon VPC Flow Logs

Amazon VPC Flow Logs capture metadata about network traffic at the elastic network interface level—source and destination IPs, ports, protocols, packets, and bytes—for both accepted and rejected flows. They operate at the network layer and do not include the API action name, caller identity, request parameters, or response details. As a result, VPC Flow Logs cannot be used to audit who or what performed API calls to AWS.

Trap 2: Amazon CloudWatch Logs

Amazon CloudWatch Logs is a centralized log store and monitoring service for application, service, and AWS log sources; it does not itself detect or record API calls. It can receive CloudTrail events only when CloudTrail is configured to deliver them, and it can then create metric filters or alarms. Without CloudTrail as the source, CloudWatch Logs has no intrinsic capability to capture API activity, so it is not the service that ensures all API calls are recorded.

Trap 3: AWS Config

AWS Config continuously records and assesses resource configuration changes and relationships, maintaining a timeline of what a resource looked like at each point in time. It applies rules to evaluate compliance, but it does not capture the API request or response data, the IAM principal who performed an action, or the exact API call. Its configuration history reflects the results of changes, not an auditable log of every API call made.

Study all Security Logging and Monitoring common traps →

A
AWS CloudTrail
AWS CloudTrail is the native API auditing service: it records user activity and API calls across the account as CloudTrail events, capturing the identity, source IP, timestamp, request parameters, and response elements. These events can be delivered to Amazon S3 for long-term retention and queried with Athena, or sent to CloudWatch Logs for alerting. To fully meet an "all API calls" requirement, both management and data events must be enabled across all regions.
B
Amazon VPC Flow Logs
Why wrong: Amazon VPC Flow Logs capture metadata about network traffic at the elastic network interface level—source and destination IPs, ports, protocols, packets, and bytes—for both accepted and rejected flows. They operate at the network layer and do not include the API action name, caller identity, request parameters, or response details. As a result, VPC Flow Logs cannot be used to audit who or what performed API calls to AWS.
C
Amazon CloudWatch Logs
Why wrong: Amazon CloudWatch Logs is a centralized log store and monitoring service for application, service, and AWS log sources; it does not itself detect or record API calls. It can receive CloudTrail events only when CloudTrail is configured to deliver them, and it can then create metric filters or alarms. Without CloudTrail as the source, CloudWatch Logs has no intrinsic capability to capture API activity, so it is not the service that ensures all API calls are recorded.
D
AWS Config
Why wrong: AWS Config continuously records and assesses resource configuration changes and relationships, maintaining a timeline of what a resource looked like at each point in time. It applies rules to evaluate compliance, but it does not capture the API request or response data, the IAM principal who performed an action, or the exact API call. Its configuration history reflects the results of changes, not an auditable log of every API call made.

Full breakdown with real-world context →

Question 15mediumdrag order

Read the full Security Logging and Monitoring explanation →

Drag and drop the steps to set up AWS Shield Advanced with automatic application layer DDoS mitigation in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Step 1: Add protection to AWS resources

This sequence is invalid because Shield Advanced is an opt-in, paid AWS service that must be subscribed to before the Add protection API will accept any resource. If you attempt to protect a resource first, the console/API has no active subscription context and returns an error, meaning the remaining configuration steps cannot be performed. Subscription is the prerequisite that enables all subsequent Shield Advanced capabilities.

Trap 2: Step 1: Subscribe to AWS Shield Advanced

This ordering is flawed because the WAF mitigation rule is created to act on the specific resources you want Shield Advanced to protect, but no protections have been added yet. The rule's name, scope, and association depend on the ARN of the protected resource; without a protected resource, the rule cannot be attached or deployed. Adding protection first ensures the rule has a concrete target when it is integrated.

Trap 3: Step 1: Subscribe to AWS Shield Advanced

Health-based detection is an advanced mitigation enhancement that should only be enabled after the WAF mitigation rule exists, because it uses health-check data to decide when to activate that rule. If you enable it before the rule is created, the health checks have no mitigation policy to trigger, so the detection is inert. Thus the WAF integration step must precede the health-based detection step in the setup.

Study all Security Logging and Monitoring common traps →

A
Step 1: Subscribe to AWS Shield Advanced. Step 2: Add protection to AWS resources. Step 3: Integrate with AWS WAF and create a mitigation rule. Step 4: Enable health-based detection.
This is the correct order because you must first subscribe to Shield Advanced to access its features, then specify the resources to protect before configuring WAF rules, then create the mitigation rule, and finally enable health-based detection to enhance automatic mitigation.
B
Step 1: Add protection to AWS resources. Step 2: Subscribe to AWS Shield Advanced. Step 3: Integrate with AWS WAF and create a mitigation rule. Step 4: Enable health-based detection.
Why wrong: This sequence is invalid because Shield Advanced is an opt-in, paid AWS service that must be subscribed to before the Add protection API will accept any resource. If you attempt to protect a resource first, the console/API has no active subscription context and returns an error, meaning the remaining configuration steps cannot be performed. Subscription is the prerequisite that enables all subsequent Shield Advanced capabilities.
C
Step 1: Subscribe to AWS Shield Advanced. Step 2: Integrate with AWS WAF and create a mitigation rule. Step 3: Add protection to AWS resources. Step 4: Enable health-based detection.
Why wrong: This ordering is flawed because the WAF mitigation rule is created to act on the specific resources you want Shield Advanced to protect, but no protections have been added yet. The rule's name, scope, and association depend on the ARN of the protected resource; without a protected resource, the rule cannot be attached or deployed. Adding protection first ensures the rule has a concrete target when it is integrated.
D
Step 1: Subscribe to AWS Shield Advanced. Step 2: Add protection to AWS resources. Step 3: Enable health-based detection. Step 4: Integrate with AWS WAF and create a mitigation rule.
Why wrong: Health-based detection is an advanced mitigation enhancement that should only be enabled after the WAF mitigation rule exists, because it uses health-check data to decide when to activate that rule. If you enable it before the rule is created, the health checks have no mitigation policy to trigger, so the detection is inert. Thus the WAF integration step must precede the health-based detection step in the setup.

Full breakdown with real-world context →

Question 16mediumdrag order

Read the full Security Logging and Monitoring explanation →

Drag and drop the steps to respond to a suspected AWS IAM credential compromise in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Review CloudTrail logs, then rotate IAM user access keys, then…

Reviewing CloudTrail logs before rotating the access key leaves the compromised long-term credential active, allowing an attacker to keep issuing actions while you are analyzing past events. Immediate rotation deletes or invalidates the exposed access key and is the first containment step; the log review then provides scope on the historical activity without risking continued misuse or newly generated events.

Trap 2: Disable the IAM user, then rotate IAM user access keys, then review…

Disabling the IAM user first stops sign-in and deactivates the user's access keys, but it does not invalidate already-issued temporary security credentials from AWS STS, which remain usable until expiration and can persist as a backdoor. Rotating the user's access keys should happen before disabling the user; after disabling, you also lose the ability to perform API actions as that user during investigation, which complicates further cleanup.

Trap 3: Notify stakeholders, then rotate IAM user access keys, then review…

Notifying stakeholders before any containment allows the attacker to continue operating while internal panic spreads, and the notification will lack verified scope, making it inaccurate and potentially harmful. Containment and log analysis should establish what was exposed and what steps were taken; only then can a clear, evidence-based notification be sent to stakeholders.

Study all Security Logging and Monitoring common traps →

A
Rotate IAM user access keys, then review CloudTrail logs, then disable the IAM user, then revoke temporary credentials, then notify stakeholders.
This is the correct order because immediate rotation prevents further use of compromised credentials, log review provides scope, disabling the user ensures no new access, revoking temp credentials covers all access types, and notification ensures awareness.
B
Review CloudTrail logs, then rotate IAM user access keys, then disable the IAM user, then revoke temporary credentials, then notify stakeholders.
Why wrong: Reviewing CloudTrail logs before rotating the access key leaves the compromised long-term credential active, allowing an attacker to keep issuing actions while you are analyzing past events. Immediate rotation deletes or invalidates the exposed access key and is the first containment step; the log review then provides scope on the historical activity without risking continued misuse or newly generated events.
C
Disable the IAM user, then rotate IAM user access keys, then review CloudTrail logs, then revoke temporary credentials, then notify stakeholders.
Why wrong: Disabling the IAM user first stops sign-in and deactivates the user's access keys, but it does not invalidate already-issued temporary security credentials from AWS STS, which remain usable until expiration and can persist as a backdoor. Rotating the user's access keys should happen before disabling the user; after disabling, you also lose the ability to perform API actions as that user during investigation, which complicates further cleanup.
D
Notify stakeholders, then rotate IAM user access keys, then review CloudTrail logs, then disable the IAM user, then revoke temporary credentials.
Why wrong: Notifying stakeholders before any containment allows the attacker to continue operating while internal panic spreads, and the notification will lack verified scope, making it inaccurate and potentially harmful. Containment and log analysis should establish what was exposed and what steps were taken; only then can a clear, evidence-based notification be sent to stakeholders.

Full breakdown with real-world context →

Question 17mediummultiple choice

Read the full Security Logging and Monitoring explanation →

A company uses AWS Organizations with multiple accounts. The security team wants to centralize security logs (CloudTrail, VPC Flow Logs, AWS Config) from all accounts into a single S3 bucket for analysis. What is the MOST secure way to set up this centralized logging?

Trap 1: Create a dedicated S3 bucket in the management account, enable S3…

Placing the centralized S3 bucket in the management account expands the attack surface of the root account and conflates administrative control with audit data, which is contrary to the AWS Well-Architected security guidance of separating logging into a dedicated account. S3 default encryption only encrypts objects at rest; it does not enforce encryption in transit or restrict which principals from member accounts can write to the bucket. A bucket policy with explicit allows for each account's logging service and condition statements such as aws:SecureTransport and s3:x-amz-server-side-encryption is still required, making this option incomplete.

Trap 2: Configure each account to deliver logs to the same S3 bucket used…

Reusing an existing bucket that already stores operational or application data violates the principle of least privilege because the bucket policy must grant cross-account write access to logging services for a bucket that also contains sensitive non-log objects. This broadens the effective permissions of the logging service principal and makes it difficult to apply appropriate lifecycle, retention, and access-control policies that are specific to audit logs. Mixing logs with other data increases the risk of accidental deletion or modification of log evidence and complicates compliance audits.

Trap 3: Create an S3 bucket in each account and use S3 replication to copy…

This approach requires creating and managing a bucket in every account, duplicating storage costs and introducing asynchronous S3 replication delays, so logs do not arrive at the central bucket in near real time. S3 replication is not designed for log aggregation; it replicates objects based on source-bucket lifecycle rules and requires additional configuration for encryption, object ownership, and cross-account IAM, which scales poorly across many accounts in an organization. This also complicates data retention because replicated copies are subject to source-bucket lifecycle policies, undermining the goal of a single authoritative log archive.

Study all Security Logging and Monitoring common traps →

A
Create a dedicated S3 bucket in the management account, enable S3 default encryption, and configure service delivery for each account.
Why wrong: Placing the centralized S3 bucket in the management account expands the attack surface of the root account and conflates administrative control with audit data, which is contrary to the AWS Well-Architected security guidance of separating logging into a dedicated account. S3 default encryption only encrypts objects at rest; it does not enforce encryption in transit or restrict which principals from member accounts can write to the bucket. A bucket policy with explicit allows for each account's logging service and condition statements such as aws:SecureTransport and s3:x-amz-server-side-encryption is still required, making this option incomplete.
B
Create a dedicated S3 bucket in the security account with a bucket policy that grants write access to the logging services of all accounts and enforces encryption in transit and at rest.
This approach aligns with AWS best practices by placing logs in a dedicated security account that is isolated from production workloads and the management account. The bucket policy grants write access only to the logging services of all accounts, using service principals like logging.s3.amazonaws.com, while condition keys such as aws:SecureTransport force TLS and a deny statement without s3:x-amz-server-side-encryption ensures all objects are encrypted at rest. This centralizes auditability, enforces least privilege, and provides a single source of truth for compliance and incident investigation.
C
Configure each account to deliver logs to the same S3 bucket used for other data.
Why wrong: Reusing an existing bucket that already stores operational or application data violates the principle of least privilege because the bucket policy must grant cross-account write access to logging services for a bucket that also contains sensitive non-log objects. This broadens the effective permissions of the logging service principal and makes it difficult to apply appropriate lifecycle, retention, and access-control policies that are specific to audit logs. Mixing logs with other data increases the risk of accidental deletion or modification of log evidence and complicates compliance audits.
D
Create an S3 bucket in each account and use S3 replication to copy logs to a central bucket.
Why wrong: This approach requires creating and managing a bucket in every account, duplicating storage costs and introducing asynchronous S3 replication delays, so logs do not arrive at the central bucket in near real time. S3 replication is not designed for log aggregation; it replicates objects based on source-bucket lifecycle rules and requires additional configuration for encryption, object ownership, and cross-account IAM, which scales poorly across many accounts in an organization. This also complicates data retention because replicated copies are subject to source-bucket lifecycle policies, undermining the goal of a single authoritative log archive.

Full breakdown with real-world context →

Question 18hardmultiple choice

Read the full Security Logging and Monitoring explanation →

A company is using Amazon CloudWatch Logs to store application logs. The security team needs to retain logs for 7 years to comply with regulatory requirements. The logs are accessed infrequently after the first 90 days. What is the MOST cost-effective way to meet these retention and access requirements?

Trap 1: Stream logs to an S3 bucket using Kinesis, then use S3 Lifecycle…

Streaming logs from CloudWatch Logs to S3 using Amazon Kinesis Data Firehose is a valid real-time delivery mechanism, but transitioning those objects to S3 Standard-IA after 90 days is not cost-optimal for 7-year archival that only needs occasional access. Standard-IA carries a per-GB retrieval fee and is designed for infrequent but immediate access, whereas S3 Glacier Deep Archive provides the lowest storage cost at the expense of hours-long retrieval. The Kinesis pipeline also introduces per-GB ingestion costs and additional operational overhead compared to a straightforward export task.

Trap 2: Set a retention policy on the CloudWatch Logs log group to 7 years…

Keeping a 7-year retention policy directly on the CloudWatch Logs log group means paying CloudWatch Logs storage rates (per GB per month) for the entire duration, which is an order of magnitude more expensive than moving data to S3 Glacier Deep Archive. CloudWatch Logs Insights is an interactive query engine intended for real-time troubleshooting on recent logs, not a cost-effective archival or analytics solution, and it bills additional query costs. For compliance-grade data that is rarely accessed, storing everything in CloudWatch Logs for 7 years is financially impractical.

Trap 3: Set a retention policy on the CloudWatch Logs log group to 7 years…

This option incorrectly assumes CloudWatch Logs has a native lifecycle policy that can transition log events directly to Amazon S3 Glacier. In reality, CloudWatch Logs only supports exporting data to an S3 bucket via export tasks or log subscriptions; there is no built-in S3 lifecycle integration within CloudWatch Logs itself. To ultimately archive in Glacier, you must first export the log data to S3 and then configure an S3 lifecycle rule — the retention policy on the log group only controls deletion in CloudWatch Logs, not movement to another service.

Study all Security Logging and Monitoring common traps →

A
Export logs from CloudWatch Logs to an S3 bucket, then use S3 Lifecycle policies to transition logs to S3 Glacier Deep Archive after 90 days.
Exporting log data from CloudWatch Logs to S3 via the CreateExportTask API is the native, recommended path for long-term archival. Once in S3, a lifecycle rule can transition objects from S3 Standard to S3 Glacier Deep Archive after 90 days, minimizing storage costs for data that is rarely, if ever, accessed while meeting the 7-year compliance requirement. This approach also lets you set a short retention on the original log group to avoid ongoing CloudWatch Logs storage fees after export completes.
B
Stream logs to an S3 bucket using Kinesis, then use S3 Lifecycle policies to transition logs to S3 Standard-IA after 90 days.
Why wrong: Streaming logs from CloudWatch Logs to S3 using Amazon Kinesis Data Firehose is a valid real-time delivery mechanism, but transitioning those objects to S3 Standard-IA after 90 days is not cost-optimal for 7-year archival that only needs occasional access. Standard-IA carries a per-GB retrieval fee and is designed for infrequent but immediate access, whereas S3 Glacier Deep Archive provides the lowest storage cost at the expense of hours-long retrieval. The Kinesis pipeline also introduces per-GB ingestion costs and additional operational overhead compared to a straightforward export task.
C
Set a retention policy on the CloudWatch Logs log group to 7 years and use CloudWatch Logs Insights for queries.
Why wrong: Keeping a 7-year retention policy directly on the CloudWatch Logs log group means paying CloudWatch Logs storage rates (per GB per month) for the entire duration, which is an order of magnitude more expensive than moving data to S3 Glacier Deep Archive. CloudWatch Logs Insights is an interactive query engine intended for real-time troubleshooting on recent logs, not a cost-effective archival or analytics solution, and it bills additional query costs. For compliance-grade data that is rarely accessed, storing everything in CloudWatch Logs for 7 years is financially impractical.
D
Set a retention policy on the CloudWatch Logs log group to 7 years and use CloudWatch Logs lifecycle policies to transition to Amazon S3 Glacier.
Why wrong: This option incorrectly assumes CloudWatch Logs has a native lifecycle policy that can transition log events directly to Amazon S3 Glacier. In reality, CloudWatch Logs only supports exporting data to an S3 bucket via export tasks or log subscriptions; there is no built-in S3 lifecycle integration within CloudWatch Logs itself. To ultimately archive in Glacier, you must first export the log data to S3 and then configure an S3 lifecycle rule — the retention policy on the log group only controls deletion in CloudWatch Logs, not movement to another service.

Full breakdown with real-world context →

Question 19mediummultiple choice

Read the full Security Logging and Monitoring explanation →

A security engineer is troubleshooting an issue where Amazon GuardDuty is not generating findings for a specific EC2 instance that is known to be compromised. The instance is in a VPC with VPC Flow Logs enabled. What could be the reason for the lack of findings?

Trap 1: CloudTrail is not enabled in the account.

CloudTrail records API activity and management events, not network traffic. GuardDuty does use CloudTrail events for detecting suspicious API calls, such as unusual IAM actions or S3 operations, but the absence of CloudTrail would only suppress those API-based findings. The inability to analyze network traffic stems from missing VPC Flow Log data, which CloudTrail never provides. Therefore, disabling CloudTrail is not the cause of the network-related detection gap.

Trap 2: AWS Config is not enabled for the EC2 instance.

AWS Config tracks configuration changes and resource compliance, maintaining a historical inventory of resources. GuardDuty does not ingest AWS Config data as a threat-detection source, so enabling or disabling Config has no bearing on GuardDuty's findings. The missing network visibility is caused by GuardDuty not receiving VPC Flow Logs, not by a lack of configuration recording. Thus, this option is incorrect because it misidentifies the data source GuardDuty relies on.

Trap 3: VPC Flow Logs are only enabled for the subnet, not the instance's…

VPC Flow Logs can be captured at the VPC, subnet, or ENI level, and subnet-level capture includes traffic for every ENI in that subnet, including the instance in question. GuardDuty can consume any of these scopes as long as the logs are delivered to CloudWatch Logs. It is not necessary to have flow logs enabled directly on the instance's ENI; the subnet-level configuration would still provide the required data. Therefore, this is not a valid explanation for the missing findings.

Study all Security Logging and Monitoring common traps →

A
CloudTrail is not enabled in the account.
Why wrong: CloudTrail records API activity and management events, not network traffic. GuardDuty does use CloudTrail events for detecting suspicious API calls, such as unusual IAM actions or S3 operations, but the absence of CloudTrail would only suppress those API-based findings. The inability to analyze network traffic stems from missing VPC Flow Log data, which CloudTrail never provides. Therefore, disabling CloudTrail is not the cause of the network-related detection gap.
B
AWS Config is not enabled for the EC2 instance.
Why wrong: AWS Config tracks configuration changes and resource compliance, maintaining a historical inventory of resources. GuardDuty does not ingest AWS Config data as a threat-detection source, so enabling or disabling Config has no bearing on GuardDuty's findings. The missing network visibility is caused by GuardDuty not receiving VPC Flow Logs, not by a lack of configuration recording. Thus, this option is incorrect because it misidentifies the data source GuardDuty relies on.
C
VPC Flow Logs are only enabled for the subnet, not the instance's ENI.
Why wrong: VPC Flow Logs can be captured at the VPC, subnet, or ENI level, and subnet-level capture includes traffic for every ENI in that subnet, including the instance in question. GuardDuty can consume any of these scopes as long as the logs are delivered to CloudWatch Logs. It is not necessary to have flow logs enabled directly on the instance's ENI; the subnet-level configuration would still provide the required data. Therefore, this is not a valid explanation for the missing findings.
D
VPC Flow Logs are not being delivered to CloudWatch Logs.
GuardDuty analyzes network traffic from VPC Flow Logs by reading them from CloudWatch Logs. If the flow logs are configured but not delivered to CloudWatch Logs—for example, because the log group is missing, delivery permissions are incorrect, or the destination is set to S3—GuardDuty has no network telemetry to analyze and cannot generate findings. Enabling flow logs alone is insufficient; they must be published to CloudWatch Logs in the same account and Region for GuardDuty to consume them. This is exactly the root cause described in the question.

Full breakdown with real-world context →

Question 20hardmultiple choice

Read the full Security Logging and Monitoring explanation →

A company uses Amazon S3 to store sensitive data. The security team needs to be alerted when an S3 bucket policy is changed to allow public access. Which combination of services should be used to meet this requirement?

Trap 1: AWS CloudTrail and Amazon Simple Notification Service (SNS)

CloudTrail records the PutBucketPolicy API call as a control-plane event in its event history, but CloudTrail is an audit log, not a real-time event router. It delivers logs to an S3 bucket or CloudWatch Logs, and it does not natively invoke an SNS topic for each bucket policy change. To alert on the event you would need an Amazon EventBridge rule or a CloudWatch Logs subscription filter, so pairing CloudTrail and SNS alone does not satisfy the requirement.

Trap 2: S3 server access logs and Amazon Athena

S3 server access logs capture object-level requests such as GET, PUT, and DELETE against objects, not control-plane API calls like PutBucketPolicy. A bucket policy change is therefore absent from these logs, so Amazon Athena queries would never surface the modification. Even if the logs did contain relevant data, they are delivered on a best-effort basis with variable delays, making them unsuitable for real-time notification.

Trap 3: AWS Trusted Advisor and Amazon Simple Notification Service (SNS)

Trusted Advisor runs periodic checks—typically refreshed on a daily schedule—and its S3 permission checks are designed to flag publicly accessible buckets, not to detect every policy edit at the moment it occurs. Its SNS notifications are tied to overall check status changes or weekly digests, not to individual PutBucketPolicy events. Thus Trusted Advisor and SNS could eventually alert on a risky bucket configuration, but they cannot provide the real-time, change-triggered alerting described in the requirement.

Study all Security Logging and Monitoring common traps →

A
AWS CloudTrail and Amazon Simple Notification Service (SNS)
Why wrong: CloudTrail records the PutBucketPolicy API call as a control-plane event in its event history, but CloudTrail is an audit log, not a real-time event router. It delivers logs to an S3 bucket or CloudWatch Logs, and it does not natively invoke an SNS topic for each bucket policy change. To alert on the event you would need an Amazon EventBridge rule or a CloudWatch Logs subscription filter, so pairing CloudTrail and SNS alone does not satisfy the requirement.
B
S3 server access logs and Amazon Athena
Why wrong: S3 server access logs capture object-level requests such as GET, PUT, and DELETE against objects, not control-plane API calls like PutBucketPolicy. A bucket policy change is therefore absent from these logs, so Amazon Athena queries would never surface the modification. Even if the logs did contain relevant data, they are delivered on a best-effort basis with variable delays, making them unsuitable for real-time notification.
C
AWS Trusted Advisor and Amazon Simple Notification Service (SNS)
Why wrong: Trusted Advisor runs periodic checks—typically refreshed on a daily schedule—and its S3 permission checks are designed to flag publicly accessible buckets, not to detect every policy edit at the moment it occurs. Its SNS notifications are tied to overall check status changes or weekly digests, not to individual PutBucketPolicy events. Thus Trusted Advisor and SNS could eventually alert on a risky bucket configuration, but they cannot provide the real-time, change-triggered alerting described in the requirement.
D
AWS Config with AWS Lambda and Amazon Simple Notification Service (SNS)
AWS Config can continuously record configuration changes to an S3 bucket policy and evaluate those changes against a managed or custom rule. When a PutBucketPolicy event occurs, AWS Config marks the configuration item as changed and invokes a custom Lambda function, which can in turn publish a message to an SNS topic to notify security teams. This design provides real-time detection and alerting because the Lambda function is triggered by the configuration change, not by a periodic scan.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Security Logging and Monitoring sessions

Start a Security Logging and Monitoring only practice session

Every question in these sessions is drawn from the Security Logging and Monitoring domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Security Logging and Monitoring questions →Mixed SCS-C02 session

Frequently asked questions

What does the SCS-C02 exam test about Security Logging and Monitoring?: Security Logging and Monitoring questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Security Logging and Monitoring questions in a focused session?: Yes — the session launcher on this page draws every question from the Security Logging and Monitoring domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other SCS-C02 topics?: Use the topic links above to move to related areas, or go back to the SCS-C02 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the SCS-C02 exam covers. They are not copied from any real exam or dump site.

Security Logging and Monitoring only

10 questions 20 questions 30 questions 50 questions

Mixed SCS-C02 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All SCS-C02 questions Security Logging and Monitoring domain overview SCS-C02 exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Security Logging and Monitoring practice questions

What to know about Security Logging and Monitoring

Common Security Logging and Monitoring exam traps

Security Logging and Monitoring questions

A company uses AWS CloudTrail to log management events in all regions. The security team notices that some API calls made by an IAM user are not appearing in the CloudTrail event history. What is the most likely reason?

A company requires real-time analysis of AWS CloudTrail logs to detect unauthorized API calls. The logs are stored in Amazon S3. Which architecture minimizes latency and cost?

A security engineer needs to be alerted when an IAM user attempts to modify an S3 bucket policy. Which method is the MOST efficient?

A company uses Amazon GuardDuty and wants to suppress low-severity findings that are known false positives. What is the recommended approach?

A company stores sensitive data in Amazon S3 and wants to detect and alert on any public read access to objects. Which combination of services provides the most comprehensive solution?

A security engineer needs to centrally collect and analyze AWS CloudTrail logs from multiple accounts. Which service is designed for this purpose?

A company uses AWS CloudTrail and wants to ensure that any modification to the trail itself is detected immediately. What should be done?

A company wants to use AWS CloudTrail to monitor data events for all S3 buckets. Which THREE steps are necessary? (Choose THREE.)

Refer to the exhibit. A security engineer reviews a CloudTrail log entry. What is the MOST concerning security issue?

Exhibit

Refer to the exhibit. A security engineer reviews the CloudTrail trail configuration. What is a security concern?

Exhibit

A security engineer wants to receive real-time notifications when an AWS API call is made to delete an S3 bucket. Which service should be used to capture and forward these events to an Amazon SNS topic?

A security engineer is designing a monitoring solution for a multi-account AWS environment using AWS Organizations. The solution must provide a centralized view of all API activities and send alerts for suspicious events. Which TWO services together can achieve this? (Choose TWO.)

A security engineer needs to ensure that all API calls made in an AWS account are captured and retained for auditing purposes. The engineer must be able to query the logs for specific user activity over the past 90 days. Which AWS service should the engineer use to meet these requirements?

Drag and drop the steps to set up AWS Shield Advanced with automatic application layer DDoS mitigation in the correct order.

Drag and drop the steps to respond to a suspected AWS IAM credential compromise in the correct order.

A company uses AWS Organizations with multiple accounts. The security team wants to centralize security logs (CloudTrail, VPC Flow Logs, AWS Config) from all accounts into a single S3 bucket for analysis. What is the MOST secure way to set up this centralized logging?

A security engineer is troubleshooting an issue where Amazon GuardDuty is not generating findings for a specific EC2 instance that is known to be compromised. The instance is in a VPC with VPC Flow Logs enabled. What could be the reason for the lack of findings?

A company uses Amazon S3 to store sensitive data. The security team needs to be alerted when an S3 bucket policy is changed to allow public access. Which combination of services should be used to meet this requirement?

Track your progress over time

Start a Security Logging and Monitoring only practice session

Related SCS-C02 topic practice pages

Threat Detection and Incident Response practice questions