SOA-C03 sample questions — 25 answered and explained

Subscription filters stream matching log events from a log group to Kinesis Data Streams, Amazon Data Firehose or Lambda in near real time. Metric filters produce numbers; export tasks are batch copies to S3.

The requirement is to move the events themselves, within seconds, with no code. A subscription filter that targets the Firehose stream directly does exactly that. Routing through a Lambda function also works but adds code. The metric-stream option is tempting because it ends at Firehose, but it delivers metrics, not log events; export tasks are batch and slow.

1. Decide whether the destination needs the events or a count: here, the events.
2. Note the latency: within seconds rules out batch exports.
3. Choose the feature that delivers matching events to Firehose: a subscription filter.

Exam tip: Need the log events somewhere else in near real time: subscription filter. Need a number to alarm on: metric filter.

CloudWatch Logs Insights runs ad hoc queries over log data already stored in one or more log groups (fields, filter, stats, sort, bin). Live Tail streams new events interactively; metric and subscription filters act only on events ingested after they are created.

The engineer needs historical counts, binned by time, across several groups, without new configuration. Logs Insights does exactly that. Live Tail is the tempting near-miss because it is also an interactive console tool, but it only shows events from now on; metric and subscription filters are new configuration and are not retroactive.

1. Note the time direction: the question looks back six hours.
2. Note the constraint: no new monitoring configuration.
3. Eliminate forward-only tools (Live Tail, new filters).
4. Run a Logs Insights stats query with bin(5m) over the incident window.

Exam tip: Looking back through logs during an incident: Logs Insights. Watching new events arrive: Live Tail.

CloudTrail records API calls. Management events are captured by default, and the CloudTrail event history shows the last 90 days of them per Region without any trail.

Who terminated an instance is an audit question about an API call, and three days falls inside the 90-day event history, which exists even with no trails configured. AWS Config would need a recorder that was never turned on, VPC Flow Logs are off by default and carry no API identities, and Session Manager history covers shell sessions, not API calls.

1. Classify the question: who did what — an audit question.
2. Recall that management events are in the event history for 90 days by default.
3. Filter the event history by event name TerminateInstances and the instance ID.

Exam tip: Who did it: CloudTrail. How did it perform: CloudWatch.

The CloudTrail event history shows only the last 90 days of management events. Keeping events longer requires a trail that delivers log files to an S3 bucket (management events are logged by trails by default; data events are opt-in).

The requirement is long-term retention of management activity. A trail to S3 provides it. The event history cannot be extended past 90 days, Insights records only unusual activity (and needs a trail anyway), and EventBridge notifications forward activity but keep nothing for three years.

1. Recall the event history limit: 90 days.
2. Identify the event class required: management events.
3. Choose a trail that records them and delivers to S3, then set the bucket's lifecycle for three years.

Exam tip: Retention beyond 90 days needs a trail to S3 — and it must record the event class the requirement names.

An alarm evaluates the most recent N periods (evaluation periods) and enters ALARM when M of them breach (datapoints to alarm). M out of N filters isolated spikes without lengthening the period.

The requirement has two halves: ignore single-minute spikes and still detect sustained load within about 3 minutes. 2 of 3 one-minute datapoints satisfies both. A higher threshold still pages on spikes and misses moderate load, a 15-minute period breaks the 3-minute requirement, and missing-data handling does not apply to real breaching datapoints.

1. Name the problem: isolated breaching datapoints, not gaps.
2. Keep the 1-minute period so detection stays fast.
3. Require more than one breaching datapoint in a short window: M out of N.

Exam tip: Flapping on short spikes: use M out of N datapoints, not a longer period or a higher threshold.

Treat missing data decides what a gap in the metric means. The four options: missing (the default — eventually INSUFFICIENT_DATA), ignore (keep current state), breaching (gaps are bad — right for heartbeats where silence is the failure), and notBreaching (gaps are good — right for sparse metrics like error counts that only emit when something goes wrong).

notBreaching matches the semantics of a sparse error metric: no datapoints means no errors, so the alarm should read OK. breaching would page every quiet night, missing is the default that produces INSUFFICIENT_DATA, and ignore just freezes whatever state the alarm was last in. An equivalent fix at the source is a metric filter default value of 0 so datapoints keep flowing during quiet periods.

1. Identify the metric as sparse — it only emits datapoints when errors occur.
2. Edit the alarm and set treat missing data to notBreaching.
3. Alternatively (or additionally), set a default value of 0 on the metric filter so the metric emits during quiet periods.
4. Confirm the alarm sits in OK overnight and still fires when errors appear.

Exam tip: Choose treat-missing-data deliberately: notBreaching for sparse error metrics, breaching for heartbeats — the default missing just yields INSUFFICIENT_DATA.

Caching is a scaling mechanism: CloudFront serves static and cacheable dynamic responses from edge locations, cutting the request volume the origin fleet must handle.

The load is dominated by repeated fetches of infrequently changing content — the ideal CloudFront workload. Offloading it at the edge reduces the fleet size needed at peak, directly cutting cost. Raising max or resizing instances buys capacity to redo work a cache would eliminate, and an ElastiCache page cache behind the web tier saves rendering work per request but every request still reaches the web servers, so the fleet still scales with request volume.

1. Identify that the hot requests are cacheable: same pages and assets, infrequent changes.
2. Create a CloudFront distribution with the site as origin.
3. Tune cache behaviors and TTLs so the article pages — not just images and CSS — are cached.
4. Watch the cache hit ratio and origin request count, then right-size the Auto Scaling group.

Exam tip: Offload repeated, cacheable traffic to CloudFront before resizing the fleet — cached requests never reach your compute.

ElastiCache for Valkey or Redis OSS replicates each shard to replica nodes and, with Multi-AZ enabled, fails over automatically; Memcached has no replication or persistence.

Surviving a node failure with the data intact requires a copy of the data on another node, plus automatic promotion. That is Valkey or Redis OSS with at least one replica per shard and Multi-AZ automatic failover. Memcached cannot replicate, so more nodes or Auto Discovery only change how much is lost or how fast clients reconnect; cluster mode with zero replicas shards data but has nothing to fail over to.

1. Read the requirement: keep the existing cached data after a node failure, with no manual step.
2. Rule out Memcached: no replication, so a lost node means lost keys.
3. Require at least one replica per shard; sharding alone does not protect data.
4. Enable Multi-AZ so ElastiCache promotes a replica automatically.

Exam tip: Cache must survive node loss → Valkey/Redis OSS with replicas and Multi-AZ failover; Memcached and replica-less shards lose data.

In ElastiCache, Evictions counts keys removed because memory is full, while expired keys (TTL) are tracked separately; rising evictions with a falling CacheHitRate mean the cache is undersized for its working set.

Two facts combine: a falling hit rate sends reads back to the database, and the Evictions metric rises only under memory pressure — keys removed because their TTL expired are reported separately (Reclaimed), so TTL expiry cannot account for rising Evictions. The fix is more memory: a larger node type or, with cluster mode enabled, more shards. Connection-pool exhaustion shows up as errors, and read replicas add read throughput, not memory.

1. Link the database CPU climb to the falling CacheHitRate: misses fall through to the database.
2. Read Evictions as memory pressure; expired keys are counted as Reclaimed, a different metric.
3. Confirm with memory metrics such as DatabaseMemoryUsagePercentage.
4. Scale up the node type or add shards, then watch evictions fall and the hit rate recover.

Exam tip: Evictions rising + hit rate falling = cache too small; TTL expiry shows up as Reclaimed, not Evictions.

On a Multi-AZ DB instance deployment, RDS applies an instance class change to the standby, fails over to it, then updates the old primary — the interruption is about the length of a failover. Converting Single-AZ to Multi-AZ itself does not require downtime.

Two facts combine: the Single-AZ to Multi-AZ conversion runs online (RDS creates the standby from a snapshot), and once Multi-AZ, the resize is applied through a failover, keeping the same endpoint. Resizing the Single-AZ instance, now or in the maintenance window, takes the database down for the full resize; promoting a replica changes the endpoint. A blue/green deployment is another endpoint-preserving route, but it is not offered here.

1. Note the constraints: an interruption of a minute or two at most, same endpoint.
2. Convert to Multi-AZ (no downtime, some I/O impact while the standby is built).
3. Modify the instance class; RDS upgrades the standby, fails over, then upgrades the old primary.
4. Keep Multi-AZ for resilience or convert back to Single-AZ afterwards if cost requires it.

Exam tip: Resize with only a brief interruption → be Multi-AZ first; the change rides a failover and the endpoint stays put.

RDS storage autoscaling automatically grows a DB instance's allocated storage when free space drops below a threshold, up to a configured maximum — and storage only grows, never shrinks.

The task is eliminating manual storage grows on an existing RDS instance, which is the exact feature description of storage autoscaling. Aurora Serverless v2 answers spiky compute demand and requires migrating; replicas scale reads, not primary storage; and instance class changes compute while forcing a restart.

1. Enable storage autoscaling on the DB instance.
2. Set a maximum storage threshold that caps cost while leaving growth headroom.
3. Keep a FreeStorageSpace alarm as a backstop near the configured maximum.
4. Remember the volume never shrinks back after growing.

Exam tip: Unpredictable data growth on RDS → enable storage autoscaling with a sensible maximum; it grows automatically and never shrinks.

RDS read replicas replicate asynchronously, so they serve eventually consistent reads; the ReplicaLag metric quantifies how far behind the replica is.

Stale reads from a replica are lag by definition, and ReplicaLag is the metric that measures it directly — alarm on it to catch the condition before users do. Storage, connections, and primary CPU are all adjacent signals that can be normal while lag grows, or abnormal without any lag.

1. Create a CloudWatch alarm on the replica's ReplicaLag metric with a threshold matching the tolerable staleness.
2. When the alarm fires, investigate replica capacity and write volume on the primary.
3. Consider a larger replica instance class or reduced replica query load.
4. Remember rising lag also means a longer catch-up if the replica is ever promoted.

Exam tip: Read replicas are asynchronous — alarm on ReplicaLag to catch stale reads and growing catch-up risk.

Drift detection reports differences between the template and live resources; it never remediates them.

Running drift detection is a read-only comparison. The MODIFIED security group still has its console changes, remains part of the stack, and the stack can still be updated. Reconciliation is a separate step: either change the template to accept the new configuration or revert the resource (by hand or by redeploying the property) so it matches.

1. Read the drift result's expected and actual property values.
2. Decide which side is correct: the template or the live change.
3. Update the template, or revert the resource so it matches the template.
4. Re-run drift detection to confirm IN_SYNC.

Exam tip: Drift detection tells you; it never fixes.

In a failed deployment, the first failure event is the root cause; the later failures are cancellations that cascade from it.

When one resource fails, CloudFormation cancels the operations still in progress and rolls back, so the history fills with secondary failures. The earliest failed event's status reason (which the console's 'Detect root cause' option points to) is the actual error. Newest-first reading lands on cancellations, drift detection is unrelated to deployment errors, and CloudTrail is a slower path to the same message.

1. Filter the stack events to failed statuses.
2. Sort chronologically and go to the earliest CREATE_FAILED or UPDATE_FAILED event.
3. Read its status reason (permissions, limits, invalid property, name conflict).
4. Fix that cause and redeploy; the cascaded failures disappear with it.

Exam tip: Read the first failure, not the last - everything after it is collateral.

Failed creates and failed updates end differently: a failed create rolls back to ROLLBACK_COMPLETE (terminal — delete and recreate), while a failed update automatically rolls back to the last working configuration and the stack stays usable.

Because the failure happened during creation, there is no previous working state to return to; CloudFormation deleted the partial resources and parked the stack in a terminal state. Updating is rejected in ROLLBACK_COMPLETE, continue update rollback belongs to the UPDATE_ROLLBACK_FAILED state, and drift detection is irrelevant when the rollback already removed every resource.

1. Confirm the root cause is fixed (read the first CREATE_FAILED event if not already done).
2. Delete the stack in ROLLBACK_COMPLETE.
3. Create the stack again with the corrected template.
4. Monitor the new creation's events to verify it completes.

Exam tip: ROLLBACK_COMPLETE after a failed create means delete and recreate — the stack cannot be updated out of that state.

UPDATE_ROLLBACK_FAILED is recovered with continue update rollback (optionally skipping resources), not with another update or a delete.

When a rollback fails, the stack cannot accept updates. After fixing the cause, ContinueUpdateRollback retries the rollback, and any resource that still cannot be restored can be listed in ResourcesToSkip so the stack reaches UPDATE_ROLLBACK_COMPLETE. A new update is rejected in this state, cancel only works during an in-progress update, and deleting a production stack is needlessly destructive.

1. Read the rollback failure reason to find the blocking resource.
2. Fix the cause (here, restore the deleted dependency).
3. Run continue update rollback, adding resources to skip only if they still cannot roll back.
4. Once the stack reaches UPDATE_ROLLBACK_COMPLETE, reconcile any skipped resources and redeploy.

Exam tip: Stuck in UPDATE_ROLLBACK_FAILED? Fix the cause, then continue update rollback.

AWS reserves 5 IP addresses in every subnet (the first four and the last), which matters most in small subnets.

A /28 contains 16 addresses. AWS keeps the network address, the VPC router, the DNS server, one for future use and the broadcast address, so 11 are usable. Nine are already taken by network interfaces, leaving 2. A deployment that adds more than 2 instances fails with an insufficient free IP addresses error unless the group can use a larger subnet.

1. Compute the subnet size: 2^(32-28) = 16 addresses.
2. Subtract the 5 AWS-reserved addresses: 11 usable.
3. Subtract the 9 addresses already in use: 2 free.
4. If the deployment needs more, add or enlarge subnets (or add a secondary CIDR block).

Exam tip: Usable IPs = 2^(32 - prefix) - 5.

A principal's effective permissions are the intersection of its identity-based policies with each limiting policy that applies: the permissions boundary and the SCPs.

AdministratorAccess allows everything, but the boundary allows only two actions on one bucket, so only those two are effective. s3:PutObject and ec2:DescribeInstances are outside the boundary and are implicitly denied. Read-only actions get no exemption.

1. List what the identity policy allows: everything.
2. List what the boundary allows: two S3 read actions.
3. Take the overlap and test each requested action against it.

Exam tip: Boundary + identity policy = intersection; the boundary itself grants nothing.

S3 bucket-level actions (s3:ListBucket) match the bucket ARN; object-level actions (s3:GetObject, s3:PutObject) match object ARNs of the form bucket-name/*.

The symptom pattern, list works but put fails, points at the resource element: the allow for s3:PutObject names only the bucket, so it never matches a request for an object. Adding /* fixes it. A bucket policy or extra actions keep the same mismatched ARN.

1. Compare what works (bucket-level) with what fails (object-level).
2. Check the Resource element against the action's resource type.
3. Add the object ARN pattern bucket-name/* for object actions.

Exam tip: Object actions need bucket/*; the bare bucket ARN covers only bucket-level actions.

CloudTrail is the record of who did what: each management API call is logged with the calling principal (userIdentity), event name, source IP address and time.

Changing a security group is a management API call (AuthorizeSecurityGroupIngress), so CloudTrail holds the principal, source IP and timestamp; event history shows the last 90 days without any trail configured. Flow logs show traffic, Access Analyzer shows potential access, and the credential report shows credential status.

1. Recognise that the question is who made an API call.
2. Open CloudTrail event history in the Region of the security group.
3. Filter on the AuthorizeSecurityGroupIngress event name and read userIdentity, sourceIPAddress and eventTime.

Exam tip: Who changed what and from where: CloudTrail.

The IAM policy simulator answers 'would this be allowed?': it evaluates policies for given actions and resources without executing any API call.

The simulator can test a new or edited policy before it is attached and shows the result per action and resource. CloudTrail is historical, Access Analyzer validation is a lint, not an allow/deny evaluation, and --dry-run is limited to EC2-style operations.

1. Note the constraints: unreleased policy, specific actions, no real calls.
2. Rule out historical tools such as CloudTrail.
3. Rule out linting tools that do not evaluate specific requests.
4. Use the policy simulator with each action and resource ARN.

Exam tip: Predict allow or deny without calling the API: IAM policy simulator.

Network ACLs are stateless: return traffic is evaluated as brand-new packets and must be explicitly allowed. A client connecting to port 443 receives the response on a high-numbered ephemeral port — commonly within 1024-65535 — so the subnet's NACL needs an outbound allow covering that range.

The custom NACL allows the request in but has no outbound rule matching the ephemeral destination ports of the responses, so connections hang after the initial packets. Security groups never hit this because they are stateful. The inbound ephemeral rule addresses the wrong direction for this flow, a UDP rule cannot match TCP replies, and port 80 is unrelated to failing HTTPS replies.

1. Recognize the symptom: requests arrive (SYNs accepted) but connections hang — a return-path block.
2. Recall that NACLs are stateless and evaluate replies as new packets.
3. Add an outbound allow for TCP 1024-65535 to 0.0.0.0/0 on the subnet's NACL.
4. Retest HTTPS; the stateful security groups needed no change.

Exam tip: A stateless NACL needs explicit allows for ephemeral-port return traffic — forgetting the outbound 1024-65535 rule is the classic hang.

Network ACLs are subnet-level, stateless filters that support both allow and deny rules, evaluated from the lowest rule number. Security groups are instance-level and allow-only.

Blocking a source across a whole subnet without touching security groups is the job of the network ACL: one deny rule covers every interface in the subnet. Because rule 100 already allows everything and evaluation stops at the first matching rule, the deny must have a lower number than 100; a higher-numbered deny is never reached. Security groups cannot deny, and WAF only sees HTTP(S) traffic through its associated resource.

1. Note the scope (an entire subnet) and the action (deny a source range).
2. Rule out security groups: allow-only, and the stem forbids changing them.
3. Add a network ACL inbound deny for the range with a number lower than 100.
4. Confirm in VPC Flow Logs that traffic from the range is now REJECT.

Exam tip: Subnet-wide deny of a source range is a low-numbered network ACL deny rule; security groups cannot deny.

Interface VPC endpoints, powered by AWS PrivateLink, place elastic network interfaces with private IPs in your subnets for most AWS services. With private DNS enabled, the service's default public hostname resolves to those private IPs inside the VPC, so applications work unchanged.

Interface endpoints with private DNS meet both constraints: traffic stays on the AWS network, and the unchanged default hostnames mean zero SDK reconfiguration. A gateway endpoint cannot serve Systems Manager, a NAT gateway reintroduces the internet path, and disabling private DNS forces the endpoint-URL overrides the requirement rules out.

1. Create interface endpoints for the Systems Manager services Session Manager requires.
2. Enable private DNS on each endpoint (the VPC needs DNS support and DNS hostnames enabled).
3. Allow inbound HTTPS (443) from the instances in the endpoints' security group.
4. Start a Session Manager session to confirm connectivity without any instance-side changes.

Exam tip: Interface endpoints plus private DNS give private subnets AWS API access with no application changes — gateway endpoints exist only for S3 and DynamoDB.

Both gateway and interface VPC endpoints accept an endpoint policy — an IAM-style resource policy that scopes what the endpoint may be used for. For an S3 gateway endpoint, that typically means restricting access to specific buckets, complementing bucket policies and identity policies.

The endpoint policy is the control that lives on the network path itself, restricting every request through the endpoint regardless of which instance or role sends it. Gateway endpoints have no security groups, NACLs cannot understand buckets or hostnames, and route entries direct packets rather than authorize API actions.

1. Open the S3 gateway endpoint's configuration and edit its endpoint policy.
2. Write a policy allowing the needed S3 actions only on the approved buckets' ARNs.
3. Apply the policy and test access to an approved bucket (success) and an unapproved one (denied).
4. Layer bucket policies and IAM policies on top for defense in depth.

Exam tip: An endpoint policy scopes what a VPC endpoint can be used for — the way to pin an S3 gateway endpoint to approved buckets.