AWS Certified CloudOps Engineer - Associate (SOA-C03) practice questions

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.

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.

A web tier runs in an EC2 Auto Scaling group, and operators want the group to keep average CPU utilisation across the fleet close to 50 percent, adding or removing instances automatically as traffic rises and falls throughout the day. They want the simplest policy that maintains this set point without them defining individual thresholds for each capacity step. Which scaling policy meets this requirement with the least ongoing tuning?

• AA simple scaling policy that adds two instances whenever a CPU alarm breaches and then waits for a cooldown before evaluating again.
• BA step scaling policy with several CPU alarm bands that each add a different number of instances as utilisation climbs higher.
• CA scheduled scaling action that sets desired capacity higher during the day and lower at night based on the usual traffic curve.
• DA target tracking scaling policy on the average CPU utilisation metric with the target value set to 50 percent.check_circle Correct

Why A is wrong: Simple scaling reacts to one alarm with a fixed change and a blocking cooldown, so it cannot hold a continuous set point and needs the team to hand-tune the threshold and step.

Why B is wrong: Step scaling reacts faster than simple scaling but still forces operators to design and maintain every alarm band and step, which is exactly the per-threshold tuning they want to avoid.

Why C is wrong: Scheduled scaling changes capacity on a clock and is blind to the live CPU metric, so it cannot track an actual utilisation set point as traffic varies unpredictably.

Why D is correct: Target tracking creates and manages the CloudWatch alarms for you and adjusts capacity to hold the metric at the chosen set point, which is the lowest-effort way to keep CPU near 50 percent.

A platform team rebuilds a hardened Amazon Linux golden AMI every time the upstream base image receives security patches, and they want the rebuild, the hardening steps, a smoke test and the production of a new AMI to run automatically on a schedule with no instance kept running between builds. Which service produces the new golden AMI in the most managed, repeatable way?

• AKeep a long-running EC2 builder instance and use a Systems Manager State Manager association to reapply the hardening configuration to it whenever new patches are released.
• BLaunch an instance from the base AMI on a schedule with Run Command, apply the hardening commands by hand-written scripts, then call CreateImage and terminate the instance manually each cycle.
• CDefine an EC2 Image Builder pipeline with the base image, hardening and test components and a schedule, so each run builds, tests and outputs a new versioned AMI then tears the build instance down.check_circle Correct
• DStore the hardening steps in a CloudFormation template and deploy a new stack on each patch release so the stack update bakes the configuration into a fresh machine image for the fleet.

Why A is wrong: State Manager enforces configuration on a running instance and never outputs an AMI, so it keeps a builder alive between rebuilds and does not produce the new golden image the team needs.

Why B is wrong: Run Command can drive the steps but the team must stitch together scheduling, image creation and cleanup themselves, which is the manual orchestration that a managed image pipeline removes.

Why C is correct: Image Builder pipelines orchestrate build and test components on a transient instance, output a versioned AMI and clean up automatically, which matches the scheduled hands-off golden image rebuild exactly.

Why D is wrong: CloudFormation provisions resources from a template but does not build or register an AMI from a base image, so it cannot bake a hardened golden image the way an image pipeline does.