3.1 - Improving monitoring, logging and operational response
AWS Solutions Architect Professional objective 3.1 covers improving monitoring, logging, and automated operational response on an existing system. You replace error-prone manual recovery with a parameterized SSM Automation runbook, centralize scattered logs with the CloudWatch agent shipping to CloudWatch Logs, and surface idle resources with Trusted Advisor cost checks plus Compute Optimizer. AWS X-Ray distributed tracing pinpoints the slow downstream segment, CloudWatch anomaly detection alarms adapt to daily and weekly cycles instead of static thresholds, and a CloudWatch Logs metric filter turns a log string like OutOfMemoryError into an alarmable custom metric. For noisy incidents you model dependencies with composite alarms and quiet child alerts with an actions suppressor, and you build a hands-off GuardDuty response where an EventBridge rule triggers an SSM Automation runbook to isolate an instance and creates an OpsCenter OpsItem. Central observability aggregates logs across accounts. Expect scenarios about a scattered-log incident, a cyclical false page, or automated remediation, and ask which monitoring capability fits.
Turn a log string into an alarm = CloudWatch Logs metric filter into a custom metric. Alarms that follow a daily/weekly pattern = CloudWatch anomaly detection. Suppress child alerts under a firing parent = composite alarm with an actions suppressor.
Practice questions
1. An operations team wants automatic remediation when a security group is changed to allow 0.0.0.0/0 on port 22, with no human in the loop. Which combination does this?
- CloudTrail alone, which reverts the change when it logs the API call
- GuardDuty findings emailed to the on-call engineer
- AWS Config rule detecting the violation, triggering an SSM Automation remediation (correct answer)
- A CloudWatch dashboard that highlights the open port in red
AWS Config detects the noncompliant security group and can trigger an SSM Automation document that revokes the rule automatically, closing the loop with no human. CloudTrail only records events, GuardDuty and dashboards alert but do not remediate on their own.
2. A running fleet of hundreds of EC2 instances is patched manually, causing drift and missed updates. The team wants scheduled, auditable OS patching with no custom scripting. What should they adopt?
- A cron job baked into each AMI that runs the package manager nightly on its own
- Systems Manager Patch Manager with patch baselines and maintenance windows
- A Lambda function that SSHes into every instance to run updates in sequence (correct answer)
- An Auto Scaling lifecycle hook that reinstalls the whole instance every week
Patch Manager applies patch baselines on a schedule via maintenance windows and records compliance centrally, giving auditable patching with no scripting. Per-AMI cron drifts and is unauditable, a Lambda SSH loop is brittle custom code, and reinstalling instances weekly is disruptive overkill.
3. A microservices app is slow intermittently, and the team cannot tell which service or call is responsible. They want end-to-end request tracing and correlated logs. Which TWO steps help most? (Choose TWO.)
- Instrument the services with AWS X-Ray to trace requests across service hops (correct answer)
- Increase every single instance size over and over until the intermittent slowness eventually stops appearing at all
- Reboot the services on a fixed weekly schedule to clear any accumulated state
- Send structured logs to CloudWatch and query them with Logs Insights (correct answer)
X-Ray builds a service map and per-segment timings that pinpoint the slow hop, and structured CloudWatch logs queried with Logs Insights let you correlate and drill into the offending requests. Oversizing masks the symptom without finding the cause, and scheduled reboots neither diagnose nor trace anything.
4. An on-call team follows a wiki page of manual steps to recover a stuck data-pipeline instance, and mistakes happen under pressure. They want a repeatable, parameterized runbook they can execute or automate. What should they build?
- A shared shell script emailed to on-call engineers before each rotation begins
- An SSM Automation runbook document capturing the recovery steps as parameters (correct answer)
- A detailed comment block added to the top of the pipeline application source code
- A CloudWatch dashboard that displays every recovery step as a text widget
An SSM Automation runbook codifies the steps as a versioned, parameterized document you can run on demand or trigger automatically, removing human error and giving an audit trail. An emailed script is unmanaged, a code comment is not executable, and a dashboard only displays text without performing actions.
5. An operations team is flooded with noisy alerts: a single backend hiccup fires dozens of separate CloudWatch alarms at once. They want fewer, more meaningful pages and a single view of service health. Which TWO steps help? (Choose TWO.)
- Use a CloudWatch composite alarm that fires only when a combination of conditions is true (correct answer)
- Delete most of the alarms and instead simply rely on engineers eventually noticing the problems from incoming user complaints
- Raise every alarm threshold high enough that alarms almost never trigger at all
- Build a CloudWatch dashboard aggregating the key service metrics in one view (correct answer)
A composite alarm combines several alarms into one signal that fires only on a meaningful pattern, cutting the flood, and a dashboard gives a single health view for triage. Deleting alarms and waiting for complaints removes detection entirely, and raising thresholds until alarms never fire hides real incidents.
6. Logs are scattered across many EC2 instances and accounts, and diagnosing an incident means SSHing into hosts one by one to grep files. The team wants centralized, searchable logs. What should they implement?
- Copy each and every instance's log files across to one single shared S3 bucket just once per day entirely by hand
- Keep logs local but write a script that opens an SSH session to every host
- Install the CloudWatch agent to ship logs to CloudWatch Logs for central search (correct answer)
- Enlarge the disk on every instance so logs are retained locally much longer
The CloudWatch agent streams logs from every instance into CloudWatch Logs, where log groups are centrally searchable with Logs Insights, ending per-host SSH grepping. Manual daily S3 copies are slow and lossy, scripted SSH grep does not centralize or index, and bigger disks keep logs local and still scattered.