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 image cleanup is always a two-step job.

Deregistration only prevents new launches from the image; the EBS snapshots referenced in its block device mappings stay in the account and keep billing until deleted. There is no built-in retention countdown that removes them, sharing affects launch permissions rather than storage, and snapshots do not depend on their source volumes for billing.

1. Before deregistering, record the snapshot IDs in each AMI's block device mappings.
2. Deregister the AMI so no new instances can launch from it.
3. Delete the orphaned snapshots explicitly (or let an Amazon Data Lifecycle Manager policy handle AMI deprecation and snapshot deletion).
4. Confirm in Cost Explorer that EBS snapshot storage charges fall.

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

The IAM account password policy cannot require MFA. MFA is enforced with an identity policy that denies everything except MFA self-management when the request lacks MFA context.

A Deny statement conditioned on BoolIfExists aws:MultiFactorAuthPresent = false matches both console sessions without MFA and access-key requests, which carry no MFA key at all, so the users are locked out until they authenticate with a device. The password policy has no MFA option. The MultiFactorAuthAge variant looks equivalent but fails open: the key is missing when MFA was not used, so the condition is false and nothing is denied. AWS Config only reports users without a device.

1. Rule out the password policy: it only governs console password rules.
2. Rule out detective tools (Config rules) when the requirement is to block actions.
3. Write a Deny with an exception for the MFA self-management actions.
4. Use BoolIfExists on aws:MultiFactorAuthPresent so requests without any MFA context are also denied.

Exam tip: Enforce MFA with a Deny on BoolIfExists aws:MultiFactorAuthPresent = false; the password policy has no MFA switch.

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.