Free SOA-C03 practice questions

Default EC2 metrics come from the hypervisor, which can only observe the instance from outside: CPU, network, disk I/O, and status checks. Memory utilization, disk-space utilization, and swap usage are internal to the guest OS, so they are never in the default metric set.

Installing and configuring the CloudWatch agent is the only way to collect in-guest metrics such as memory, because the agent runs inside the operating system and publishes what the hypervisor cannot see. Detailed monitoring is tempting but only increases the frequency of the same hypervisor metrics; a metric filter works on logs, not OS measurements; and IAM changes grant permission without creating any data source.

1. Confirm the missing metric is an in-guest metric (memory, disk space, swap) rather than a hypervisor metric.
2. Install the CloudWatch agent on the instance.
3. Configure the agent's JSON configuration to collect the memory metrics required.
4. Verify the new metrics arrive in CloudWatch and build alarms or dashboards on them.

Exam tip: Memory and disk-space metrics missing from CloudWatch always point to installing the CloudWatch agent — detailed monitoring never adds new metrics.

Target tracking scaling holds a chosen metric — such as average CPU utilization — at a target value by automatically creating and managing the CloudWatch alarms and scaling in both directions.

The requirement 'keep a metric near a value' maps directly to target tracking, which needs only the metric and the target number — the least configuration of any policy type. Step scaling could approximate the behavior but demands hand-built alarms and tiered adjustments; simple scaling is legacy and makes only one adjustment per cooldown window; scheduled scaling follows the clock, not the metric.

1. Translate the requirement: 'keep average CPU near 50%' is a target-value goal, not a threshold or schedule.
2. Create a target tracking policy on the Auto Scaling group with ASGAverageCPUUtilization as the metric and 50 as the target.
3. Let AWS manage the generated alarms — do not edit or delete them.
4. Set instance warmup so booting instances do not distort the aggregate metric.

Exam tip: When a requirement says keep a metric near a value, the answer is a target tracking policy — the modern default with the least operational overhead.

Deregistering an AMI and deleting its backing EBS snapshots are two separate operations, so stale-image cleanup is always a two-step job.

Deregistration only prevents new launches from the image; the EBS snapshots that back it stay in the account and keep billing until deleted. The 30-day retention answer invents a lifecycle that does not exist, the sharing answer confuses launch permissions with storage lifecycle, and the source-volume answer gets snapshot billing backwards — snapshots are independent of volumes.

1. Identify the snapshot IDs associated with each deregistered AMI (they are listed in the AMI's block device mappings before deregistration, or findable by description).
2. Deregister the AMI so no new instances can launch from it.
3. Delete the now-orphaned EBS snapshots explicitly.
4. Confirm in billing or Cost Explorer that snapshot storage charges drop.

Exam tip: Deregistering an AMI never deletes its EBS snapshots — delete them separately or keep paying for them.

The IAM account password policy cannot require MFA — it only controls console password rules. MFA is enforced with an IAM policy that denies actions when the request lacks MFA context.

A Deny statement conditioned on aws:MultiFactorAuthPresent (using BoolIfExists so access-key requests, which never carry MFA context, are also denied) blocks every action except MFA registration until the user authenticates with MFA. The password policy has no MFA option, and AWS Config and Trusted Advisor are detective tools — they report problems but cannot prevent an unauthenticated action.

1. Create an IAM policy with a Deny on all actions, excepting the MFA-management actions users need to register a device.
2. Add the condition BoolIfExists aws:MultiFactorAuthPresent is false, so both console and access-key requests without MFA are denied.
3. Attach the policy to all IAM users, typically through a group.
4. Verify a test user can only manage MFA until authenticating with a registered device.
5. Enable MFA on the root user separately — it is not covered by IAM user policies.

Exam tip: The password policy cannot require MFA — enforce it with a Deny conditioned on aws:MultiFactorAuthPresent.

In every VPC subnet, AWS reserves five IP addresses that cannot be assigned to resources: the network address, the VPC router (+1), the Amazon DNS resolver (+2), a future-use address (+3), and the broadcast address (the last address, held back even though broadcast is not supported).

A /28 block has 16 total addresses, and after AWS's five reservations, 11 remain assignable. The answer 14 applies traditional networking (network + broadcast reserved) but misses the three AWS-specific reservations, 16 ignores reservations entirely, and 13 undercounts the reserved set. This matters operationally because small subnets fill up fast — load balancer nodes and interface endpoints each consume addresses too.

1. Compute the total addresses in the CIDR: a /28 yields 2^(32−28) = 16.
2. Subtract the five AWS-reserved addresses (network, router, DNS, future use, broadcast).
3. Confirm the result: 16 − 5 = 11 usable addresses.
4. When sizing subnets, add headroom for ENIs consumed by load balancers, endpoints, and NAT gateways.

Exam tip: Every AWS subnet loses exactly five IP addresses to reservations — a /28 gives 11 usable addresses, not 14 or 16.