Associate-level AWS certification for deploying, operating and troubleshooting workloads on AWS: monitoring and remediation, reliability and business continuity, automation, security operations and networking, with a worked explanation on every practice question.
Free sample questions
No account needed. Every question has a worked explanation, just like the full bank.
lock_openFree sampleMonitoring, Logging, Analysis, Remediation, and Performance Optimizationmedium
An operations team must alarm on the percentage of used memory and free disk space on a fleet of EC2 instances running a standard Amazon Linux AMI. They have not changed the default monitoring configuration. What is the most operationally efficient way to make these signals available as CloudWatch metrics?
- AInstall and configure the CloudWatch agent on the instances to collect memory and disk metrics and publish them to a custom namespace.check_circle Correct
- BEnable detailed monitoring on each EC2 instance so that memory and disk metrics are published at a one-minute frequency.
- CRead the existing MemoryUtilization and DiskSpaceUtilization metrics that EC2 publishes by default to the AWS/EC2 namespace.
- DCreate a CloudWatch metric filter over the instance system logs to extract memory and disk values into custom metrics.
Recognise that EC2 publishes no memory or disk metrics by default and the CloudWatch agent is needed to collect in-guest signals. CloudWatch receives EC2 metrics from the hypervisor, which can see CPU, network and EBS activity but cannot see inside the guest operating system. Memory utilisation and free disk space are in-guest values, so they require the CloudWatch agent to read system counters and publish them as custom metrics before any alarm can use them.
Why A is correct: The CloudWatch agent reads in-guest counters such as mem_used_percent and disk_free, publishing them as custom metrics that alarms can then evaluate, which is exactly the supported pattern.
Why B is wrong: Detailed monitoring only raises the publishing frequency of the existing hypervisor metrics to one minute; it never adds in-guest memory or disk usage, so the required signals are still missing.
Why C is wrong: It sounds right because CPU is there by default, but EC2 publishes no memory or disk-space metric to AWS/EC2; those values live inside the guest and are never collected automatically.
Why D is wrong: Metric filters only run against log events already in CloudWatch Logs, and the default AMI does not log memory or disk usage, so there is nothing for the filter to match.
lock_openFree sampleMonitoring, Logging, Analysis, Remediation, and Performance Optimizationmedium
An application writes structured logs to a CloudWatch Logs log group, and each authentication failure produces a line containing the token ERROR Login. The team wants to alarm when more than fifty such failures occur in five minutes, using the least additional infrastructure. Which approach meets the requirement?
- ACreate an EventBridge rule that matches the failure log events directly and triggers an alarm action once the threshold is crossed.
- BCreate a CloudWatch Logs metric filter that matches the failure pattern and publishes a count metric, then alarm on its five-minute sum.check_circle Correct
- CCreate a CloudWatch alarm directly on the log group so that it counts matching log lines and fires above the configured threshold.
- DConfigure a Logs subscription filter to stream events to Lambda, which counts failures in memory and raises an alarm when fifty are seen.
Use a CloudWatch Logs metric filter to convert a log pattern into a metric so an alarm can evaluate it over a window. CloudWatch alarms can only watch metrics, never raw log groups. A metric filter scans incoming log events, and each match increments a custom metric value. An alarm set to the sum statistic over a five-minute period then detects when more than fifty failures occur, all using native CloudWatch features without any extra compute.
Why A is wrong: EventBridge does not subscribe to raw log lines inside a log group, and rules cannot count events over a window, so this cannot evaluate a fifty-in-five-minutes threshold.
Why B is correct: A metric filter turns matching log events into a numeric metric inside CloudWatch, and a standard alarm on the five-minute sum then fires above fifty, meeting the requirement with no extra services.
Why C is wrong: Alarms evaluate metrics, not log groups; there is no way to point an alarm at a log group, so a metric must first be produced from the log data.
Why D is wrong: Streaming to Lambda works but adds a function and stateful counting logic, which is far more infrastructure than a metric filter plus a native alarm for the same outcome.
lock_openFree sampleMonitoring, Logging, Analysis, Remediation, and Performance Optimizationmedium
A platform team runs separate CloudWatch alarms on CPU, memory and request latency for a service. They are paged whenever any single alarm fires, but they only want a page when the service is genuinely unhealthy, defined as high latency occurring at the same time as either high CPU or high memory. Which CloudWatch feature expresses this combined condition with the least new configuration?
- AReplace the three alarms with a single metric-math alarm that adds the CPU, memory and latency metrics and alarms on the combined total.
- BConfigure each existing alarm with an alarm action that pages only when the other two alarms are also in the ALARM state at that moment.
- CCreate a composite alarm whose rule references the existing alarms as latency AND (CPU OR memory) and send the page from that composite alarm.check_circle Correct
- DAdd an anomaly-detection band to the latency alarm so it pages only when latency is statistically unusual relative to CPU and memory.
Use a composite alarm to combine the states of existing alarms with boolean logic and reduce noisy paging. A composite alarm does not watch a metric directly; instead its rule expression evaluates the ALARM and OK states of other alarms using AND, OR and NOT operators. Encoding latency AND (CPU OR memory) means the composite enters ALARM only when the dangerous combination is present, which suppresses single-signal noise while keeping the existing alarms intact.
Why A is wrong: Metric math can combine metrics, but summing differently scaled values is meaningless and cannot express the latency-AND-resource logical condition the team actually needs.
Why B is wrong: Individual alarms cannot read the state of other alarms in their actions, so there is no native way to make one alarm wait on the status of the others.
Why C is correct: A composite alarm evaluates a boolean rule over the states of existing alarms, so latency AND (CPU OR memory) pages only on the genuine combination while reusing the alarms already in place.
Why D is wrong: Anomaly detection models a single metric against its own history and has no awareness of CPU or memory, so it cannot encode the cross-metric AND or OR relationship.
Examworthy is not affiliated with or endorsed by Amazon Web Services. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. SOA-C03 and related marks belong to their respective owners.
