AWS SysOps Monitoring, Logging, and Remediation: 100 practice questions

12 of the 100 Monitoring, Logging, and Remediation questions in the Certsqill AWS SysOps bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS SysOps? Take the free 5-min readiness check →

1. Memory utilization is not a default CloudWatch metric: What is the most likely cause and solution?

1. Memory utilization is not a default CloudWatch metric for EC2; install the CloudWatch Agent on the instances to collect memory metrics ✓

   AWS does not have access to the EC2 operating system internals by default. Memory, disk utilization, and swap are OS-level metrics that require the CloudWatch Agent (or the legacy collectd/StatsD integration) to collect and publish to CloudWatch as custom metrics.
2. Memory metrics appear only for instances that run inside a VPC, so confirm that these instances were not launched into the legacy EC2-Classic platform

   Memory metrics are unrelated to VPC vs EC2-Classic networking. Regardless of network placement, OS-level memory data requires the CloudWatch Agent to be installed and configured.
3. Create a CloudWatch alarm on CPUUtilization and rely on it as a proxy, since memory pressure always drives the reported CPU higher

   CPU and memory are independent metrics; high memory usage does not reliably raise CPU. The correct fix is to install the CloudWatch Agent to capture actual memory metrics.
4. Enable detailed monitoring on the EC2 instances, which surfaces operating-system memory metrics alongside CPU at a one-minute collection granularity

   Detailed monitoring reduces the collection interval from 5 minutes to 1 minute for standard EC2 metrics (CPU, network, disk I/O at the hypervisor level). It does NOT add memory, disk utilization, or OS-level metrics; those require the CloudWatch Agent regardless of monitoring mode.

Memory utilization is NOT a default EC2 CloudWatch metric; install the CloudWatch Agent to collect OS-level metrics including memory, disk utilization, and swap.

2. AWS migrates the instance to healthy hardware: Which statement accurately describes what happens to the instan

1. AWS terminates the failed instance and launches a fresh, identical replacement from the source AMI, assigning it a brand-new instance ID and instance metadata

   Recovery does not terminate the instance or create a new one. It migrates the existing instance to healthy hardware, preserving the instance ID and all associated attributes.
2. AWS migrates the instance to healthy hardware; the instance retains the same instance ID, Elastic IP, instance metadata, and private/public IP addresses ✓

   The EC2 recover action moves the instance to healthy underlying hardware while preserving the instance ID, Elastic IP (if associated), private IP, and instance metadata. It is different from a reboot; the instance gets new physical hardware but maintains its identity. Instance store data is not preserved.
3. AWS reboots the instance in place on the same underlying host hardware, which often fails to clear the original system status check failure

   Recovery is distinct from reboot. Recovery moves to healthy hardware specifically to address system-level failures (hypervisor, hardware, power, network). A reboot on the same failing hardware would not fix a hardware-level issue.
4. All instance store volume data survives the recover action because the original instance is migrated to new hardware rather than being terminated in the process

   Instance store volumes are ephemeral and tied to the underlying physical host. During EC2 recovery (migration to new hardware), instance store data is LOST. Only EBS-backed data is preserved.

EC2 recover action migrates the instance to healthy hardware preserving instance ID, EIP, private IP, and metadata — but instance store data is lost during the hardware migration.

3. Create a CloudWatch Logs subscription filter on the Lambda: What is the correct approach for near real-time lo

1. Enable Lambda enhanced monitoring to push error events directly to Kinesis

   Lambda enhanced monitoring provides additional metrics in CloudWatch (memory, initialization duration, etc.) but does not stream log events to Kinesis. Subscription filters on the log group are the correct mechanism.
2. Schedule a CloudWatch Logs export task to run every 5 minutes to deliver logs to S3 with sub-minute latency

   Export tasks are batch operations that process historical log data. Even if scheduled every 5 minutes, they cannot provide near real-time (seconds) delivery. Subscription filters are the real-time mechanism.
3. Create a CloudWatch Logs subscription filter on the Lambda log group targeting a Kinesis Data Stream ✓

   CloudWatch Logs subscription filters stream log data in near real-time to supported destinations: Kinesis Data Streams, Kinesis Data Firehose, Lambda, and OpenSearch. Data arrives within seconds. The 'Export to S3' feature is a batch process that may deliver data hours later and is not suitable for real-time use cases.
4. Use Amazon EventBridge to trigger a rule on Lambda function error events and route them to Kinesis

   EventBridge can capture Lambda function state change events (invocation errors at a high level) but cannot stream individual log lines from the function logs. For log content streaming, CloudWatch Logs subscription filters are required.

CloudWatch Logs subscription filters stream log data in near real-time (seconds) to Kinesis, Firehose, Lambda, or OpenSearch. S3 export is batch — hours of latency.

4. Enable CloudTrail data events for S3: What must be configured, and what is a cost consideration?

1. Create a CloudWatch Events rule that matches S3 object API calls, since EventBridge rules log every request with full actor detail for free

   CloudWatch Events (EventBridge) can match certain S3 events (like object creation for Lambda triggers) but does not log all S3 API calls with full actor attribution the way CloudTrail does. CloudTrail data events are the authoritative source for S3 API audit.
2. Enable S3 server access logging on each bucket, which records every object-level API call with full IAM attribution at no cost

   S3 server access logging records request details to S3 log files, but it uses best-effort delivery, lacks CloudTrail Lake integration, and does not provide the same IAM-actor attribution as CloudTrail data events. CloudTrail data events are the correct audit mechanism.
3. Rely on CloudTrail management events, which already include S3 object-level operations once the trail spans all regions

   Management events log resource-management API calls (CreateBucket, DeleteBucket, PutBucketPolicy). Object-level operations (GetObject, PutObject) are DATA events, a separate category that is disabled by default.
4. Enable CloudTrail data events for S3; data events are disabled by default and incur additional charges per 100,000 events ✓

   CloudTrail logs two types of events: management events (API calls for resource management, enabled and free for 90 days in event history) and data events (S3 object-level, Lambda invocations, DynamoDB item-level, disabled by default and priced per event). Enabling S3 data events on all buckets logs every GetObject, PutObject, and DeleteObject call.

CloudTrail data events (S3 object-level, Lambda invocations) are disabled by default and cost extra. Enable them in the trail configuration for S3 object-level audit logging.

5. A CloudWatch Composite Alarm with the rule: Which CloudWatch feature should the administrator use?

1. A CloudWatch Composite Alarm with the rule: ALARM('CPU-Alarm') AND ALARM('Network-Alarm') AND ALARM('ELB-5XX-Alarm') ✓

   CloudWatch Composite Alarms evaluate Boolean rule expressions combining the states of multiple existing alarms. Using AND logic ensures the composite alarm only enters ALARM state when all three component alarms are simultaneously in ALARM — eliminating false positives from individual transient spikes. Only the composite alarm needs an SNS action; suppress actions on the component alarms.
2. Increase the alarm evaluation periods on all three alarms to 10 minutes to filter out transient spikes

   Longer evaluation periods reduce false positives for transient spikes on each individual alarm but do not prevent pages when only one or two alarms are genuinely in ALARM state. Composite alarms provide the logical AND requirement across all three alarms simultaneously.
3. Configure SNS message filtering on the SNS topic to only deliver notifications when three alarms fire within 60 seconds

   SNS message filtering filters messages based on attributes of individual messages. It cannot correlate multiple alarm messages from different sources or implement time-window AND logic. Composite alarms evaluate states continuously, not time-windowed event correlation.
4. A CloudWatch metric math alarm that multiplies all three metrics; the result exceeds a threshold only when all are high

   Metric math alarms operate on metric values, not alarm states. Multiplying the three metric values produces an uninterpretable number with no semantic meaning relative to individual thresholds. Composite alarms combine alarm STATES with Boolean logic.

CloudWatch Composite Alarms evaluate Boolean expressions (AND/OR/NOT) across multiple alarm states — AND logic ensures paging only when all three are simultaneously in ALARM.

6. VPC Flow Logs do not capture traffic to the Amazon DNS: Which statement correctly explains this behavior?

1. DNS queries are recorded only in CloudTrail rather than VPC Flow Logs, so enable Route 53 Resolver query logging to inspect this resolver traffic instead

   Route 53 Resolver query logging captures DNS queries to Route 53 resolvers (useful but separate). The claim that CloudTrail captures DNS traffic is incorrect; CloudTrail logs AWS API calls, not network-level DNS query traffic.
2. VPC Flow Logs do not capture traffic to the Amazon DNS server; this is a documented exclusion along with instance metadata service traffic and DHCP traffic ✓

   VPC Flow Logs have several documented exclusions: traffic to/from the Amazon DNS server (169.254.169.253 or the VPC+2 DNS address), traffic to/from the instance metadata service (169.254.169.254), DHCP traffic, Windows KMS activation traffic, and traffic mirrored via Traffic Mirroring. These exclusions are by design.
3. Capturing DNS requires a Flow Log created at the subnet level, because VPC-level Flow Logs silently omit all traffic that is sent to the Amazon resolver

   The exclusion applies regardless of whether Flow Logs are configured at the VPC, subnet, or ENI level. DNS to the Amazon resolver is excluded at all levels.
4. The Flow Log traffic-type filter must be set to ALL rather than to ACCEPT or REJECT, otherwise the Amazon DNS resolver queries are never written to the logs at all

   The Flow Log traffic type filter (ACCEPT, REJECT, ALL) controls which accepted/rejected connections are logged. DNS to the Amazon resolver is excluded entirely regardless of the filter setting.

VPC Flow Logs exclude: Amazon DNS server traffic, instance metadata service (169.254.169.254), DHCP, and Windows KMS activation — these are documented exclusions at all log levels.

7. Configure an AWS Config remediation action on the rule: What is the correct architecture?

1. Configure a CloudWatch alarm on the Systems Manager fleet health metric so the operations team is paged whenever some instances appear as unmanaged

   A CloudWatch alarm would notify the team but does not perform automatic remediation. The requirement specifies remediation that starts automatically without human intervention.
2. Create an EventBridge rule matching the Config non-compliance events that triggers a Lambda function which calls SSM Run Command to install the SSM Agent

   This can work but is more complex than necessary. AWS Config's built-in automatic remediation with SSM Automation is the purpose-built, simpler approach; EventBridge plus Lambda is a workaround for when Config remediation is insufficient.
3. Configure an AWS Config remediation action on the rule that invokes an SSM Automation runbook to install the SSM Agent and attach the required IAM role ✓

   AWS Config rules can have remediation actions configured, either manual or automatic. Automatic remediation runs immediately on non-compliant resources without human approval. For SSM non-management, the remediation can invoke AWS-ConfigureAWSPackage or a custom SSM Automation runbook to install the agent and attach the AmazonSSMManagedInstanceCore policy.
4. Use Systems Manager State Manager to run a continuous association that reinstalls and starts the SSM Agent on every EC2 instance across the account

   State Manager associations maintain desired state but require the SSM Agent to already be running, creating a chicken-and-egg problem for instances without the agent. Config remediation handles the bootstrap problem through SSM Automation or other mechanisms.

AWS Config automatic remediation actions invoke SSM Automation runbooks immediately when non-compliant resources are detected — no human intervention required.

8. Create a metric filter with a pattern like 'Transaction: Which CloudWatch Logs metric filter configuration ach

1. Enable CloudWatch Container Insights, which automatically parses every log pattern and publishes any embedded numeric values it finds as time-series metrics

   Container Insights is for ECS/EKS container monitoring. It does not automatically extract arbitrary numeric values from application log lines. Metric filters are the correct mechanism.
2. Create a metric filter with the pattern 'Transaction completed' and set the Metric Value to '1', which yields a metric that reflects each response time

   Setting Metric Value to '1' counts how many times the pattern matches (occurrence counting). It does not capture the actual response time value. To extract the numeric value, use a named token in the filter pattern and reference it as the Metric Value.
3. Use a Lambda subscription filter that parses each log line and calls the PutMetricData API with the extracted duration value as a custom metric

   A Lambda subscription filter could accomplish this but requires custom code. CloudWatch Logs metric filters natively support numeric value extraction from patterns without Lambda, making them the simpler, purpose-built solution.
4. Create a metric filter with a pattern like 'Transaction completed in $duration ms' and set the Metric Value to '$duration' to extract the numeric value ✓

   CloudWatch Logs metric filters support extraction of numeric values from log events using named tokens (e.g., $variable syntax). Setting the Metric Value to '$duration' instead of a static number (like '1') extracts the actual numeric value from each matching log line as a time-series metric.

CloudWatch Logs metric filters extract numeric values from logs using named variables in filter patterns ($variable syntax); set Metric Value to '$variable' to capture the actual number.

9. Enable log file integrity validation on the trail: Which CloudTrail feature supports this requirement?

1. Enable log file integrity validation on the trail; CloudTrail creates SHA-256 signed digest files referencing each log file, allowing validation with the AWS CLI ✓

   CloudTrail log file integrity validation creates a digitally signed digest file every hour. Each digest file contains SHA-256 hashes of all log files delivered during that period and is signed with a private key by CloudTrail. You can verify them using the 'aws cloudtrail validate-logs' command; any modification to log files or digest files causes validation to fail.
2. Enable S3 Object Lock in Compliance mode on the log bucket so the delivered CloudTrail files become immutable and cannot be altered or deleted by anyone

   S3 Object Lock prevents modification or deletion of objects but does not provide a verification mechanism that proves to an auditor that specific files remained intact. CloudTrail integrity validation creates an independent, verifiable audit trail.
3. Use CloudTrail Lake to store and analyze the events, since the Lake event data store continuously validates the integrity of every single log record that it ingests

   CloudTrail Lake stores event data in a managed data store optimized for querying. It is a separate feature from trail-based logging to S3 and does not provide the signed digest file mechanism used to verify S3-delivered trail logs.
4. Enable MFA Delete on the S3 log bucket so that removing any delivered CloudTrail log file requires an additional multi-factor authentication credential first

   MFA Delete prevents deletion of S3 objects without MFA credentials. It helps protect against deletion but does not detect whether existing log files have been modified. CloudTrail integrity validation detects both modification and deletion.

CloudTrail log file integrity validation creates hourly SHA-256 signed digest files; use 'aws cloudtrail validate-logs' to verify no log files were modified or deleted.

10. CloudWatch Anomaly Detection: Which CloudWatch feature provides a dynamic threshold that adapts to the expecte

1. Increase the alarm evaluation period to a full 24 hours so that short-lived latency spikes are averaged out and can no longer push the alarm into ALARM state

   A 24-hour evaluation period would severely delay alarm detection. Anomaly Detection maintains a dynamic band at the configured granularity (1 minute, 5 minutes, etc.), so there is no need to sacrifice responsiveness for false-positive reduction.
2. CloudWatch Anomaly Detection — trains an ML model on historical metric data to create a band of expected values; alarms trigger when the metric falls outside the band ✓

   CloudWatch Anomaly Detection uses ML to analyze historical metric patterns (including time-of-day and day-of-week seasonality) and creates a dynamic expected-value band. Alarms based on anomaly detection trigger when the metric moves outside the band rather than crossing a fixed threshold, adapting to predictable daily patterns.
3. Create several static CloudWatch alarms with different thresholds for business hours and off-hours, combined with the native time-based alarm suppression windows

   Multiple alarms could approximate time-based thresholds, but they require manual threshold definition, do not adapt to pattern changes, and CloudWatch does not natively support time-based alarm suppression. Anomaly Detection is purpose-built for this pattern.
4. Use a Metric Math alarm built on a moving-average expression that smooths the latency line so the predictable seasonal daily variation stops producing any false positives at night

   Metric Math moving averages smooth the metric line but do not create a dynamic expected-value band that adapts to time-of-day patterns. Anomaly Detection captures the cyclical pattern in a two-dimensional band.

CloudWatch Anomaly Detection uses ML to model expected metric patterns including daily/weekly seasonality; alarms trigger when the metric falls outside the dynamically computed band.

11. Store the CloudWatch Agent configuration file in SSM: What is the recommended approach?

1. Use EC2 user data to download the CloudWatch Agent from an S3 bucket and apply its configuration automatically every time an instance is first launched

   User data only runs at first launch. For configuration updates to existing instances, a separate mechanism is needed. SSM Parameter Store plus Run Command works for both the initial deployment and ongoing updates.
2. Manually configure the CloudWatch Agent on every one of the instances over SSH using the interactive built-in configuration wizard to keep the settings identical everywhere

   Manual SSH configuration does not scale to 200 instances and is inconsistent (human error risk). SSM-based deployment with centralized configuration in Parameter Store is the scalable, consistent approach.
3. Store the CloudWatch Agent configuration file in SSM Parameter Store; deploy the agent via SSM Run Command and reference the SSM parameter during installation ✓

   The CloudWatch Agent can retrieve its configuration from SSM Parameter Store. Storing the config in Parameter Store enables centralized management: updating the SSM parameter and running the 'AmazonCloudWatch-ManageAgent' action reloads configuration across all instances without manual file editing.
4. Build a custom AMI with the CloudWatch Agent pre-installed and fully configured, then launch all two hundred of the instances from that single golden image

   A custom AMI with a pre-installed agent works but requires rebuilding the AMI for configuration changes and cannot easily update running instances. SSM Parameter Store with Run Command lets you update configuration on running instances without AMI rebuilds.

Store CloudWatch Agent config in SSM Parameter Store; use SSM Run Command with AmazonCloudWatch-ManageAgent to deploy and update configuration across a fleet of instances.

12. Amazon Data Lifecycle Manager: Which AWS service and feature provides this scheduled automation with the least

1. An SSM Maintenance Window running a Run Command document that creates each production volume snapshot during the scheduled daily window

   Maintenance Windows with Run Command are designed for instance-level operations (patching, commands). EBS snapshot creation is a storage-level API call, and DLM is the appropriate managed service.
2. An EventBridge scheduled rule that triggers a Lambda function calling the CreateSnapshot API against every production volume

   EventBridge plus Lambda can accomplish this but requires writing Lambda code to enumerate volumes and call the API. Amazon DLM is the purpose-built service designed for this use case with zero custom code.
3. AWS Backup with a backup plan that selects the production EBS volumes and runs them on a daily scheduled backup rule

   AWS Backup is a valid alternative and supports cross-account and cross-region backup. For straightforward EBS snapshot scheduling, DLM is simpler; AWS Backup is the better choice when centralized backup across multiple services (EBS, RDS, DynamoDB) is needed.
4. Amazon Data Lifecycle Manager (DLM) — create a lifecycle policy that schedules daily EBS snapshots with retention management ✓

   Amazon Data Lifecycle Manager automates EBS snapshot and AMI creation on a schedule. A DLM policy targets volumes by tags, runs on a daily schedule at the specified time, and manages retention automatically. It is the purpose-built, fully managed solution for automated EBS snapshot lifecycle management.

Amazon Data Lifecycle Manager (DLM) automates EBS snapshot scheduling, tag-based targeting, and retention management — the purpose-built solution for snapshot lifecycle with no custom code.

Other AWS SysOps domains

• Networking and Content Delivery — 90 questions →
• Deployment, Provisioning, and Automation — 89 questions →
• Reliability and Business Continuity — 80 questions →
• Security and Compliance — 79 questions →
• Cost and Performance Optimization — 60 questions →
• All 498 AWS SysOps questions →