AWS Certified CloudOps Engineer – Associate (SOA-C03)

Learn symptom → evidence → control → verified result. Follow a two-AZ workload, compare the closest alternatives, then practise the deciding constraint. Cards contain service features, small examples and AWS references.

Checked: 10 November 2026. Scope follows the SOA-C03 guide and revisions. Exercises are local simulations; no AWS account is needed.

Operating model · Deciding constraint · Service cards · Six labs · Practice · Coverage · Architecture explorer

1. Understand the operating environment

Provision → operate → observe → investigate → remediate → recover. Select a responsibility, then reveal the AWS services. Workload traffic, changes and evidence are separate flows.

ARCHITECTURE BEFORE SERVICESOne workload. Find the boundary that owns the symptom.

Provisioning changes the environment; users exercise it; evidence guides a bounded repair. Recovery succeeds only when the service and its data are validated. These are logical handoffs, not one packet travelling through every box.

Operating sequenceApplication traffic / dataConfiguration / corrective actionMonitoring evidence / feedback

All responsibilities · static reading

Provision / configure

Review the intended resource configuration and artifact before an operational change.

Dependencies. Versioned template, image, role, quota and free subnet IPs.

Failure. A deployment fails or creates drift from intended state.

Evidence. Stack events, change set, image/task status and CloudTrail actor.

Verify. Fix the prerequisite, complete rollback/reconcile and verify deployed state.

Operate

Keep the workload serving within its availability, latency and cost constraints.

Dependencies. Healthy targets, runtime identity, database, storage and network.

Failure. Instance running but unhealthy, or insufficient surviving capacity.

Evidence. Target health, scaling activities, guest metrics and DB load.

Verify. Restore usable capacity and verify the same user path under representative load.

Observe

Collect the metrics, logs, traces and relevant resource/API events needed to distinguish failures.

Dependencies. Agent/instrumentation, permissions, dimensions, retention and cross-account links.

Failure. An alarm has no data or the useful log/trace was never collected.

Evidence. Publication timestamps, alarm history, log streams and collection errors.

Verify. Repair collection, send a known test event and verify both evidence and alert delivery.

Investigate

Trace symptom → affected scope → evidence → likely cause. Identify the first boundary with a proven fault.

Dependencies. Correct account, Region, AZ, time window, principal and request correlation.

Failure. Treating a correlation or assistant recommendation as a confirmed cause.

Evidence. Logs/trace timing, API changes, configuration history and service health.

Verify. Choose a test that distinguishes the likely cause from the nearest alternative.

Remediate

Perform the smallest approved corrective action, with safe targeting, retries and rollback.

Dependencies. Scoped role, runbook, preconditions, approvals and concurrency/error limits.

Failure. A broad repair damages healthy resources or loops on its own events.

Evidence. Runbook step output, target API error and resulting resource state.

Verify. Confirm the exact action and retry safely; remove the cause, not just the symptom.

Validate / recover

Prove service and data recovery against actual RTO/RPO, then prevent recurrence.

Dependencies. Usable recovery point, KMS access, target network, dependency order and cutover plan.

Failure. Backup succeeds but restore, access or application cutover fails.

Evidence. Restore job, record checks, endpoint tests, elapsed outage and data age.

Verify. Verify business results and recovery objectives; record prevention in controlled configuration.

User request

Resolve a name, connect to the advertised endpoint and send the application request.

Dependencies. DNS response, client network, TLS trust and caller identity as required.

Failure. The name is wrong or a certificate does not match.

Evidence. DNS answers, served certificate and client-visible status/timing.

Verify. Retest from the affected source and account for DNS caches.

Route / filter

Apply cache/origin behaviour and listener routing to an eligible backend.

Dependencies. Routes, SG/NACL, return path, health check and target port.

Failure. A good DNS answer reaches a blocked or unhealthy target.

Evidence. Access/WAF/flow logs and target-health reason.

Verify. Correct the first failed hop and verify request plus response.

Application

Use the deployed artifact and runtime identity to process the request and construct a response.

Dependencies. CPU, memory, dependencies, role permissions, configuration and state.

Failure. A bad rollout, exhausted resource or denied downstream request.

Evidence. Version, logs, traces, utilisation, failed API action and status checks.

Verify. Rollback or repair the measured dependency; verify latency, errors and business outcome.

Durable state

Preserve the authoritative data and independent recoverable history.

Dependencies. Storage performance, database consistency, backups, encryption and access.

Failure. Slow I/O, logical corruption, inaccessible key or unusable recovery point.

Evidence. DB waits, volume metrics, version/recovery timestamp and KMS errors.

Verify. Restore/tune the right layer and validate integrity before cutover.

2. Read the deciding constraint

Name the affected scope, operation, failure and evidence before changing anything. A timeout, AccessDenied and stale data need different investigations.

Distinction	Deciding clue	Start with
Metrics / logs / traces	Trend / event detail / one slow request	Dimensions and statistic / matching log / downstream spans.
Audit / configuration history	Who changed it / what settings existed	CloudTrail / Config timeline.
Availability / capacity / performance	Keep serving / handle more / finish faster	Healthy targets / scaling activity / first saturated dependency.
Backup / replication / failover	Historical undo / another copy / service continuity	Recovery point / replication lag / failover evidence.
RTO / RPO	Maximum outage / tolerable data loss	Measured recovery time / usable recovery timestamp.
Identity / permissions / network	Who / allowed action / reachable path	Trust and policies / SG, NACL, routes and DNS.

Restore service first; prevent recurrence next. API success is not proof of application recovery.

3. Connect theory to services

Use the decision tables, then open a card for features and an example. Optional exercises expand in place; examples are excerpts with illustrative identifiers.

Local exercises: Alarm evaluation · Failure capacity · RTO/RPO · Stack recovery · Encrypted access · Network path.

3.1 Monitoring & performance — 22%

Signal → correlated evidence → bounded repair → measured outcome

When the requirement is…	Start with…	Deciding boundary
Trend / threshold	CloudWatch metrics + alarm	Check dimensions, statistic, period and missing data.
Individual slow request	Logs + trace	Correlate the actual dependency; sampling may hide a trace.
API change / resource history	CloudTrail / Config	Actor and configuration are different evidence.
Sustained performance limit	Compute, EBS, storage or DB metrics	Fix the first saturated dependency; measure before resizing.

CloudWatch metrics & alarms Logs, queries & traces CloudTrail & change evidence EventBridge, SNS & remediation EC2 performance & capacity EBS performance & snapshots S3 operations & protection EFS, FSx & S3 Files Health & assisted investigation

Implementation notes

Collect before investigating. Cross-account observability needs regional source links; a dashboard alone does not establish them. Verify notification delivery and the repaired workload.

Optional exercise · Alarm evaluation

Think of an alarm as a rule over a time window. Change the data or missing-data policy and explain why the state changes.

Illustrative fixed-window calculation: no older datapoints, ingestion lag, premature-transition rules or namespace-specific exceptions. Real CloudWatch evaluates more conditions; inspect its state history.

For 70, 90, missing with a threshold above 80 and 2-of-3: one known breach is insufficient alone. Treating absence as breaching supplies the second breach; treating it as notBreaching does not.

3.2 Reliability & recovery — 22%

Healthy capacity → failure isolation → protected history → tested recovery

When the requirement is…	Start with…	Deciding boundary
Traffic growth	Scaling + a proportional metric	More instances cannot fix a saturated shared database by themselves.
Host/AZ failure	Healthy targets + Multi-AZ dependencies	Measure surviving capacity, not only instance count.
Logical deletion	Version / snapshot / PITR restore	A healthy replica may contain the same deletion.
Regional disaster	Approved DR runbook	Choose by tested RTO, RPO, cost and dependency readiness.

Auto Scaling & elasticity Load balancing & target health RDS, Aurora & database recovery DynamoDB scaling & recovery ElastiCache & cache operations AWS Backup & disaster recovery

Implementation notes

Test the restored data and application. Include permissions, networking, reconnection and endpoint cutover in the recovery clock; a replica can contain the same logical deletion.

Optional exercise · ASG failure capacity

The ASG sets the staffing target; the ALB routes to eligible workers. A surviving instance count does not prove enough usable capacity.

Assumes equal instance capacity of 100 requests/s and health convergence. Launches are eventual and can fail. ASG min/max and single-Region scope still apply; this is not a capacity reservation.

Actual 5 and desired 5 with +3 requests desired 8. Losing AZ A leaves 3 instances, or an illustrative 300 requests/s: below 400 requests/s demand until adequate capacity recovers.

Optional exercise · RTO / RPO

RTO is the outage clock; RPO is how far the recovered ledger may lag. Both constraints must be met.

The table uses assumed measured procedures, not universal AWS timings or guarantees. Listed order approximates increasing standby cost; actual costs differ. Live standby options here have no independent historical undo.

Procedure	Assumed RTO	Assumed RPO	Cost boundary
Daily backup + restore	180 min	1,440 min	Low standby cost
Continuous PITR + restore	90 min	5 min	Retention + restore
Pilot light	45 min	5 min	Core data running
Warm standby	10 min	1 min	Reduced stack running

At RTO 120 minutes and RPO 15 minutes, the assumed daily backup fails both constraints; the illustrated PITR procedure meets both. Validate real recovery before making the same claim.

3.3 Deployment & automation — 22%

Versioned definition → reviewed change → rollout → health gate → rollback / reconcile

When the requirement is…	Start with…	Deciding boundary
Preview infrastructure impact	Change set / CDK diff	Preview does not execute or guarantee success.
Rollback itself failed	Repair prerequisite + continue rollback	Reconcile skipped resources before the next update.
Maintain existing nodes	Systems Manager	Agent, identity and outbound connectivity are prerequisites.
Many accounts / Regions	StackSets, RAM and trusted roles	Deploying copies differs from sharing an existing resource.

CloudFormation & CDK lifecycle Images & deployment operations Systems Manager operations Multi-account operations EventBridge, SNS & remediation

Implementation notes

Pin versions, test a small target, limit rollout concurrency and retain rollback inputs. Verify the workload after the stack or runbook finishes.

Optional exercise · Stack recovery

A failed update and a failed rollback are different states. Repair the prerequisite before repeating the operation.

For UPDATE_ROLLBACK_FAILED, fix the permission/resource problem and continue rollback. Once UPDATE_ROLLBACK_COMPLETE, review a corrected change set before another deployment.

3.4 Security & compliance — 16%

Known principal → trusted session → permitted operation → protected data → compliance evidence

When the requirement is…	Start with…	Deciding boundary
Cannot assume role	Caller policy + target trust	Trust is not the role’s downstream permission policy.
Encrypted read denied	Data access + KMS key access	Key state/context/policy still apply.
Unapproved configuration	Config evaluation + safe remediation	An aggregator alone neither records nor repairs.
Finding needs action	Match finding source to control	Patch, restrict or investigate; verify the actual outcome.

IAM access investigation Multi-account operations Config & continuous compliance KMS, encryption & secrets ACM & encrypted connections Security findings & classification

Implementation notes

Check the principal, trust, action/resource policy and any restricting controls separately. Keep secrets out of investigation logs.

Optional exercise · IAM / KMS access

The resource permission and the key-use permission protect different boundaries. This example uses an IAM-enabled KMS key policy.

A valid role and S3 permission still cannot read this SSE-KMS object without the required KMS permission. Explicit denial wins even when other allows are present.

3.5 Networking & delivery — 18%

Name → route → filter → listener → target → return path

When the requirement is…	Start with…	Deciding boundary
Name fails; IP succeeds	DNS / Resolver / delegation	Changing SG rules does not repair a wrong DNS answer.
Timeout on a reachable name	Routes + SG/NACL + listener	Check response path and ephemeral ports too.
Private AWS API access	Gateway or interface endpoint	Endpoint policy limits access; it does not grant IAM permissions.
Wrong cached response	CloudFront behaviour / cache key	Lower TTL cannot correct a missing variation dimension.

VPC routes, subnets & filters Endpoints & private connectivity Route 53 & DNS operations CloudFront & Global Accelerator Network evidence & protection

Implementation notes

Trace the actual source, destination and return path. Compare NAT, endpoint and cross-AZ costs. A modelled reachable path still needs a real application test.

Optional exercise · Network path

A route is a road; an SG is a stateful gate; a NACL is a stateless checkpoint in each direction.

Simplified browser ↔ ALB path plus backend SG check; backend NACLs, OS listener and TLS are assumed correct. ALB → backend is a separate connection with its own source ephemeral port and return rules. Broad 1024–65535 examples are not every OS’s exact range.

browser:54321 → ALB:443 needs inbound destination 443; ALB:443 → browser:54321 needs outbound destination 54321 at the ALB subnet NACL. Stateful SGs track the allowed connection; NACLs do not.

4. Practise the boundary

72 original questions. Answer once, identify the deciding clue and reject the closest alternative. Multiple-answer questions state the required count; focused follow-ups do not predict exam frequency.

All 72 scenarios & explanations · static reference

1.1 · Missing guest metric

CPU metrics arrive, but an EC2 memory-utilisation alarm has no datapoints. What directly supplies the missing measurement?

1. Enable detailed EC2 monitoring
2. Configure CloudWatch Agent to publish memory usage
3. Create a CloudTrail trail
4. Lower the alarm threshold

Answer & deciding boundary

Correct: Configure CloudWatch Agent to publish memory usage

Clue. The metric does not exist yet; frequency and threshold are secondary.

• Enable detailed EC2 monitoring: Changes supported built-in metric frequency; it does not collect guest memory.
• Configure CloudWatch Agent to publish memory usage: The agent reads the guest metric and publishes it with configured identity/network access.
• Create a CloudTrail trail: Records AWS API activity, not guest memory usage.
• Lower the alarm threshold: Cannot create missing datapoints.

Change the requirement. If CPU existed but five-minute publication was too coarse, detailed monitoring could be appropriate.

Analogy. Install a thermometer before setting its warning temperature.

CloudWatch metrics & alarms · Logs, queries & traces

1.1 · No-data policy

A continuously reporting heartbeat must alert when publishing stops. With no older real datapoints available, which setting makes missing periods count toward a metric alarm?

1. notBreaching
2. ignore
3. breaching
4. Disable alarm actions

Answer & deciding boundary

Correct: breaching

Clue. Absence itself is the failure signal. Real evaluation can retrieve older data.

• notBreaching: Treats missing values as good for evaluation.
• ignore: Retains the existing state when missing data controls evaluation.
• breaching: Substitutes breaching values when CloudWatch needs missing datapoints.
• Disable alarm actions: Prevents notification, not data loss.

Change the requirement. For a sparse error-only metric where absence is normal, notBreaching may fit.

Analogy. A missed check-in should ring the bell, not count as a healthy check-in.

CloudWatch metrics & alarms

1.2 · Find the change

A security group became open just before an incident. Which evidence identifies the API caller and change time?

1. CloudTrail management event
2. EC2 CPU graph
3. ALB access log
4. AWS Config configuration timeline

Answer & deciding boundary

Correct: CloudTrail management event

Clue. The question is who changed an AWS setting.

• CloudTrail management event: Captures supported configuration API activity and caller identity.
• EC2 CPU graph: Shows utilisation, not the actor changing a rule.
• ALB access log: Records requests, not this administrative API operation.
• AWS Config configuration timeline: Shows recorded resource settings and changes, but does not replace CloudTrail API caller evidence.

Change the requirement. If you needed the sequence of recorded rule configurations, Config history would help.

Analogy. Consult the change register to find the signatory.

CloudTrail & change evidence · Config & continuous compliance

1.2 · Matched but not repaired

An EventBridge rule matches stopped-instance events, but the Automation never starts. Select TWO first checks.

1. Target invocation permissions and role trust
2. FailedInvocations, retry/DLQ and target execution evidence
3. Only retest the already-matching event pattern
4. Remove the event pattern to match every event
5. Increase retries without inspecting a permanent AccessDenied

Answer & deciding boundary

Correct: Target invocation permissions and role trust; FailedInvocations, retry/DLQ and target execution evidence

Clue. Matching and target invocation are separate boundaries.

• Target invocation permissions and role trust: The rule/target needs the appropriate invocation and assumption permissions.
• FailedInvocations, retry/DLQ and target execution evidence: Distinguishes routing success from delivery or execution failure.
• Only retest the already-matching event pattern: Confirms matching again but does not diagnose the failed target invocation.
• Remove the event pattern to match every event: Broadens potentially unsafe actions without fixing target access or delivery.
• Increase retries without inspecting a permanent AccessDenied: Retrying the same permission denial does not repair the policy.

Change the requirement. If the runbook started but failed inside a step, inspect its step output and target resource access.

Analogy. A ticket accepted by dispatch may still never reach the technician.

EventBridge, SNS & remediation · Systems Manager operations

1.3 · Disk bottleneck

An EC2 service has high EBS latency and queue depth while CPU and memory are healthy. Instance EBS bandwidth has headroom; gp2 burst balance is depleted. What is the most relevant change to evaluate?

1. Enable detailed EC2 monitoring as the performance fix
2. Create a snapshot as the primary latency fix
3. Move to appropriately provisioned gp3 performance
4. Increase only CPU cores

Answer & deciding boundary

Correct: Move to appropriately provisioned gp3 performance

Clue. The exhausted resource is volume I/O, with instance bandwidth ruled out.

• Enable detailed EC2 monitoring as the performance fix: Improves metric frequency but does not add the missing volume I/O capacity.
• Create a snapshot as the primary latency fix: Protects recovery state rather than provisioning sustained volume performance.
• Move to appropriately provisioned gp3 performance: Separates volume performance from capacity; benchmark the required IOPS/throughput.
• Increase only CPU cores: Evidence points to the volume, not CPU.

Change the requirement. If the instance EBS bandwidth were saturated, changing only volume IOPS would be insufficient.

Analogy. A faster loading dock helps only when the road to it has spare capacity.

EBS performance & snapshots · EC2 performance & capacity

1.3 · Database wait evidence

Writer transaction latency rises with lock waits on a few SQL statements; storage and CPU have headroom. What should you investigate first?

1. SQL, transaction duration and lock contention with Database Insights
2. Double every EC2 web instance
3. Add RDS Proxy without investigating transaction locks
4. Add a read replica and leave blocking writer transactions unchanged

Answer & deciding boundary

Correct: SQL, transaction duration and lock contention with Database Insights

Clue. Wait type identifies a database concurrency issue.

• SQL, transaction duration and lock contention with Database Insights: Directly addresses the measured wait.
• Double every EC2 web instance: Can increase database pressure without fixing locks.
• Add RDS Proxy without investigating transaction locks: Connection pooling does not remove the demonstrated blocking writer transactions.
• Add a read replica and leave blocking writer transactions unchanged: Read scaling does not directly fix the lock contention on the writer.

Change the requirement. If connection setup rather than lock waits dominated, RDS Proxy/connection pooling could be relevant.

Analogy. More checkout lanes do not help when one transaction holds the only storeroom key.

RDS, Aurora & database recovery

1.3 · Shared-file operating boundary

Two Linux application instances in separate AZs need concurrent access to the same persistent files. Which option directly fits?

1. Regional EFS with mount targets and permitted NFS access
2. One EBS volume attached across both AZs
3. Two instance-store directories
4. Only a CloudFront distribution

Answer & deciding boundary

Correct: Regional EFS with mount targets and permitted NFS access

Clue. The required interface is shared files across AZs, not independent block disks.

• Regional EFS with mount targets and permitted NFS access: Provides supported shared NFS access across AZs; check DNS and mount security.
• One EBS volume attached across both AZs: EBS attachments cannot cross AZ boundaries.
• Two instance-store directories: They are separate local ephemeral storage, not a shared persistent filesystem.
• Only a CloudFront distribution: Caches HTTP content; it is not the requested shared application filesystem.

Change the requirement. For Windows SMB/AD semantics, consider an appropriate FSx deployment.

Analogy. Choose a shared filing room rather than two independent desk drawers.

EFS, FSx & S3 Files · EBS performance & snapshots

1.3 · Replica writes: default versus exception

An RDS MySQL read replica normally rejects writes. An engineer says no write can ever succeed before promotion. Which correction is accurate?

1. read_only=0 can permit writes, but conflicting changes can break replication
2. Any replica write is safe once read_only=0
3. Its endpoint automatically redirects writes to the source
4. Changing max_allowed_packet makes it a writable primary

Answer & deciding boundary

Correct: read_only=0 can permit writes, but conflicting changes can break replication

Clue. Distinguish normally prohibited writes from a documented parameter-controlled exception.

• read_only=0 can permit writes, but conflicting changes can break replication: The default is a control, not an absolute physical impossibility; replica-specific indexes are a documented special case.
• Any replica write is safe once read_only=0: Permitting a write does not protect replication from conflicting application changes.
• Its endpoint automatically redirects writes to the source: The replica has its own endpoint; do not assume transparent write routing.
• Changing max_allowed_packet makes it a writable primary: Message-size limits do not change the replica’s role or consistency model.

Change the requirement. If independent application writes are required, use an appropriate writer architecture rather than exploiting a read-replica exception.

Analogy. Removing a desk’s read-only sign does not make two clerks’ conflicting ledger edits safe.

RDS, Aurora & database recovery

1.3 · Replication breaks only on a large message

MySQL replication works until a large logical message arrives. The source allows a larger max_allowed_packet than the replica. What should be checked first?

1. Matching appropriate source/replica parameter values and the failing message
2. The total number of stored database rows
3. Only aggregate writes per minute
4. The VPC MTU as if max_allowed_packet were a TCP frame size

Answer & deciding boundary

Correct: Matching appropriate source/replica parameter values and the failing message

Clue. The error identifies message size, not capacity or overall transaction throughput.

• Matching appropriate source/replica parameter values and the failing message: The smaller receiving limit can reject a sufficiently large logical message.
• The total number of stored database rows: Database size does not define this individual-message limit.
• Only aggregate writes per minute: A rate is not the logical size limit that the error identifies.
• The VPC MTU as if max_allowed_packet were a TCP frame size: MySQL logical messages and network frames are different units.

Change the requirement. If the error instead identifies a conflicting local replica write, parameter matching will not repair that inconsistency.

Analogy. A letterbox opening limits one envelope, not the total size of the archive.

RDS, Aurora & database recovery

1.3 · Busy device name after detach

Evidence identifies a guest driver retaining a device mapping after detach; the EBS volume is otherwise available in the correct AZ. What should be evaluated next?

1. An unused supported attachment name, after checking actual guest mappings
2. More gp2 burst credits
3. A cross-AZ attachment to avoid the name
4. Format the first disk whose name looks similar

Answer & deciding boundary

Correct: An unused supported attachment name, after checking actual guest mappings

Clue. The question supplies a specific driver-name cause; do not infer it from every stuck attachment.

• An unused supported attachment name, after checking actual guest mappings: The identified collision concerns naming/mapping, not disk I/O performance.
• More gp2 burst credits: Credits affect performance, not resolution of this device-name collision.
• A cross-AZ attachment to avoid the name: EBS attachment must remain in the volume’s AZ.
• Format the first disk whose name looks similar: Names may be remapped; identify the actual volume before touching its data.

Change the requirement. For a different error such as attachment-count limit, use that control rather than repeatedly renaming devices.

Analogy. Two devices cannot claim the same reserved label merely because the storage service calls one available.

EBS performance & snapshots

1.3 · Resize a public EBS-backed instance

A compatible EBS-backed On-Demand instance has an auto-assigned public IPv4 and no EIP. Which TWO effects should an operator plan for during an in-place type change?

1. Stop/change/start downtime
2. The auto-assigned public IPv4 normally changes
3. The instance ID and private IPv4 must always be replaced
4. Instance-store contents are safely retained across the stop
5. ASG membership can never interfere with planned stopping

Answer & deciding boundary

Correct: Stop/change/start downtime; The auto-assigned public IPv4 normally changes

Clue. In-place change preserves identity differently from replacement, but needs downtime and address planning.

• Stop/change/start downtime: Changing the type through this workflow requires stopping the instance.
• The auto-assigned public IPv4 normally changes: An Elastic IP would have different address persistence.
• The instance ID and private IPv4 must always be replaced: Those normally persist through ordinary stop/start of the same instance.
• Instance-store contents are safely retained across the stop: Instance-store data is lost; EBS persistence is a different mechanism.
• ASG membership can never interfere with planned stopping: An ASG can mark the stopped instance unhealthy and replace it.

Change the requirement. With an EIP, its public address can remain associated; a controlled replacement rollout has a different availability plan.

Analogy. The same named machine can reboot on another host while its temporary street number changes.

EC2 performance & capacity · Auto Scaling & elasticity

1.3 · Legacy network-interface bottleneck

Measurements identify a legacy EC2 virtual network interface as the bottleneck. General application networking is required, not tightly coupled MPI/HPC. Which path should be evaluated?

1. Compatible enhanced networking/ENA and the exact instance’s bandwidth/PPS limits
2. EFA as the universal answer to every packet-rate issue
3. Direct Connect as if it replaced the guest instance NIC
4. A universal 20K-PPS or 25-Gbps ceiling for all modern EC2

Answer & deciding boundary

Correct: Compatible enhanced networking/ENA and the exact instance’s bandwidth/PPS limits

Clue. The workload and measured constraint identify ordinary enhanced networking, not a different network product.

• Compatible enhanced networking/ENA and the exact instance’s bandwidth/PPS limits: Targets the identified interface capability and measured resource limits.
• EFA as the universal answer to every packet-rate issue: EFA serves specialised tightly coupled communication requirements.
• Direct Connect as if it replaced the guest instance NIC: It supplies hybrid connectivity, not a replacement for this interface capability.
• A universal 20K-PPS or 25-Gbps ceiling for all modern EC2: Legacy exam figures are not per-type modern guarantees.

Change the requirement. For tightly coupled HPC communication, EFA compatibility and application support could become relevant.

Analogy. Choose the correct vehicle interface before buying a different intercity road.

EC2 performance & capacity · Network evidence & protection

1.2 · New launch API versus instance start

Notify an SNS subscriber when a matching new EC2 launch API operation occurs, including while prior notifications are still being processed. What is the clearest event path?

1. CloudTrail RunInstances event → EventBridge rule → SNS
2. Any EC2 running state event, assumed to identify creation uniquely
3. One metric alarm held in ALARM for every matching event
4. CloudTrail is mandatory for every EventBridge service event

Answer & deciding boundary

Correct: CloudTrail RunInstances event → EventBridge rule → SNS

Clue. The operation identity is RunInstances; a state name alone is ambiguous.

• CloudTrail RunInstances event → EventBridge rule → SNS: Matches the launch operation; configure the appropriate trail/event and target permissions.
• Any EC2 running state event, assumed to identify creation uniquely: Starting an existing instance can also produce running transitions.
• One metric alarm held in ALARM for every matching event: State-transition notification is not one notification per repeated event.
• CloudTrail is mandatory for every EventBridge service event: EventBridge can also receive direct service events without CloudTrail.

Change the requirement. If the requirement is per created instance rather than per API call, extract/process every instance ID from a multi-instance launch event.

Analogy. Use the new-order receipt rather than every later “order now active” status change.

EventBridge, SNS & remediation · CloudTrail & change evidence

1.1 · Test the journey without real users

Operations needs scheduled browser/API checks with managed metrics and test artifacts even when no customers are active. Which capability most directly fits?

1. CloudWatch Synthetics canary
2. ServiceLens / trace map alone
3. A dashboard alone
4. Only a scheduled Lambda invocation, assuming all canary reporting exists automatically

Answer & deciding boundary

Correct: CloudWatch Synthetics canary

Clue. The requirement is active synthetic execution plus managed evidence, not passive correlation.

• CloudWatch Synthetics canary: Purpose-built scheduled synthetic tests with monitoring integrations and artifacts.
• ServiceLens / trace map alone: Correlates observed telemetry; it does not execute the endpoint test.
• A dashboard alone: Displays existing signals rather than generating test requests.
• Only a scheduled Lambda invocation, assuming all canary reporting exists automatically: Custom Lambda can run checks, but monitoring/reporting/artifacts must be assembled appropriately.

Change the requirement. If a bespoke unsupported test executor is required, scheduled custom execution with explicit instrumentation may fit.

Analogy. A mystery shopper creates a test visit; a CCTV index only helps inspect visits already recorded.

CloudWatch metrics & alarms · Logs, queries & traces · EventBridge, SNS & remediation

1.3 · Resize an EBS-root host with scratch data

A compatible EBS-root EC2 instance also has important temporary results on instance store. It needs more RAM by in-place resizing. What should operations expect?

1. Resize by editing AMI metadata without stopping
2. Detach and move instance store to the larger host
3. A normal reboot and a stop/start erase the same storage
4. Copy required scratch data out, then stop/change type/start with downtime

Answer & deciding boundary

Correct: Copy required scratch data out, then stop/change type/start with downtime

Clue. Root storage is EBS, while additional scratch storage has a different lifecycle.

• Resize by editing AMI metadata without stopping: The running instance’s compute configuration is not changed by editing an image definition.
• Detach and move instance store to the larger host: Instance-store volumes cannot be detached and transferred like EBS volumes.
• A normal reboot and a stop/start erase the same storage: Normal reboot preserves instance-store data; stop/start does not.
• Copy required scratch data out, then stop/change type/start with downtime: EBS-root resizing uses stop/start; EBS data persists, but instance-store data does not.

Change the requirement. An instance-store-root workload needs migration rather than this normal resize path.

Analogy. A persistent filing cabinet and a temporary workbench have different moving rules.

EC2 performance & capacity · EBS performance & snapshots

1.1 · Shard quota warning is not a latency trace

Operations needs supported checks warning about Kinesis shard-count quota utilisation, with a notification on check status changes. Which approach fits?

1. Treat Trusted Advisor results as guaranteed real-time delivery
2. Trusted Advisor → eligible EventBridge integration in us-east-1 → SNS
3. ServiceLens automatically detects the 80% quota threshold
4. Watch only IncomingBytes to determine allocated shard-count quota

Answer & deciding boundary

Correct: Trusted Advisor → eligible EventBridge integration in us-east-1 → SNS

Clue. The requirement concerns quota allocation and check status, not one request’s latency.

• Treat Trusted Advisor results as guaranteed real-time delivery: Checks can lag and the EventBridge delivery is best effort; plan eligibility applies.
• Trusted Advisor → eligible EventBridge integration in us-east-1 → SNS: The supported quota check uses environment usage snapshots and check-status events.
• ServiceLens automatically detects the 80% quota threshold: Trace correlation investigates observed application telemetry, not every AWS quota recommendation.
• Watch only IncomingBytes to determine allocated shard-count quota: Data throughput is different from the number of allocated shards against an account quota.

Change the requirement. Producer throttling or a hot shard instead requires throughput/error metrics and partition-key investigation.

Analogy. A building occupancy inspection is different from timing each service desk.

Health & assisted investigation · CloudWatch metrics & alarms · EventBridge, SNS & remediation

1.1 · The image has the agent, but telemetry is missing

A new ASG member boots from an AMI containing the configured CloudWatch Agent. EC2 built-in CPU metrics appear but guest memory metrics do not. What should be checked?

1. Assume ASG reinstalls and starts every agent automatically
2. Enable detailed monitoring to create the missing memory metric
3. Use the original image-source host’s metrics as proof
4. Agent startup, configuration, instance-role permission and endpoint connectivity

Answer & deciding boundary

Correct: Agent startup, configuration, instance-role permission and endpoint connectivity

Clue. The missing signal is a guest metric, although built-in monitoring works.

• Assume ASG reinstalls and starts every agent automatically: ASG launches the image; it does not independently guarantee arbitrary guest software startup.
• Enable detailed monitoring to create the missing memory metric: Detailed EC2 monitoring changes built-in frequency, not guest memory collection.
• Use the original image-source host’s metrics as proof: The new member needs its own correctly dimensioned telemetry.
• Agent startup, configuration, instance-role permission and endpoint connectivity: The image supplies software; each running instance must actually start and publish the configured telemetry.

Change the requirement. If only built-in EC2 frequency is required, detailed monitoring can be the relevant choice.

Analogy. Packing a measuring tool in the box does not turn it on after delivery.

Images & deployment operations · CloudWatch metrics & alarms

2.1 · Desired versus actual

An ASG has actual capacity 3, desired 5 and maximum 10. A ChangeInCapacity policy adds 3. What desired capacity does it request?

1. 6
2. 8
3. 10
4. 3

Answer & deciding boundary

Correct: 8

Clue. Policies change desired capacity, not actual capacity directly.

• 6: Adds to actual rather than desired.
• 8: The adjustment applies to desired 5; actual is then reconciled toward 8.
• 10: The maximum is a cap, not the requested target.
• 3: Ignores the scaling adjustment.

Change the requirement. If maximum were 6, the resulting desired capacity would be capped at 6.

Analogy. The staffing target changes before the new staff arrive.

Auto Scaling & elasticity

2.1 · Cache under write load

A node-based Redis OSS cluster has one busy primary and several replicas. Write throughput is the bottleneck. What change can distribute key writes when the key distribution supports it?

1. Add replicas only
2. Enable suitable cluster-mode sharding and distribute keys
3. Increase CloudFront TTL
4. Increase TTL only

Answer & deciding boundary

Correct: Enable suitable cluster-mode sharding and distribute keys

Clue. Horizontal write scaling needs multiple shards, not more copies of one shard.

• Add replicas only: Replicas copy a shard; they do not partition its primary writes.
• Enable suitable cluster-mode sharding and distribute keys: Multiple primaries own different key ranges.
• Increase CloudFront TTL: Does not directly repartition Redis writes.
• Increase TTL only: Changes entry lifetime and potential read misses, not the number of write-owning shards.

Change the requirement. If reads dominated and stale reads were acceptable, replicas could improve read capacity.

Analogy. More photocopies do not create more editors; separate sections can have separate editors.

ElastiCache & cache operations

2.2 · Direct works, ALB fails

An instance answers on port 8080 directly, but ALB marks it unhealthy. Which investigation is most useful first?

1. Health path/port/matcher and ALB-to-target SG rules
2. Increase ASG desired capacity before checking the health configuration
3. Disable all health checks
4. Enable only EC2 status checks in the ASG

Answer & deciding boundary

Correct: Health path/port/matcher and ALB-to-target SG rules

Clue. Direct reachability is not proof that the configured ALB check passes.

• Health path/port/matcher and ALB-to-target SG rules: The load balancer uses its own configured request and source security boundary.
• Increase ASG desired capacity before checking the health configuration: New instances with the same mismatched health setup can fail identically.
• Disable all health checks: Hides evidence and risks routing to failures.
• Enable only EC2 status checks in the ASG: Does not diagnose or repair the ALB application health-check request.

Change the requirement. If every target failed due to a bad application release, roll back the release rather than only changing checks.

Analogy. A front entrance working does not prove the inspector’s assigned entrance opens.

Load balancing & target health

2.2 · Standby or reader

A traditional RDS Multi-AZ DB instance must survive an AZ failure; separate reporting also needs read scaling with acceptable lag. Select TWO appropriate capabilities.

1. Keep Multi-AZ for failover
2. Add a suitable read replica and route reporting reads to it
3. Read directly from the traditional standby
4. Keep all reporting on the primary and expect automatic replica routing
5. Treat a manual snapshot as automatic live database failover

Answer & deciding boundary

Correct: Keep Multi-AZ for failover; Add a suitable read replica and route reporting reads to it

Clue. Availability and read scaling are separate requirements.

• Keep Multi-AZ for failover: The synchronous standby supports availability.
• Add a suitable read replica and route reporting reads to it: Adds asynchronous read capacity with lag considerations.
• Read directly from the traditional standby: It is not a readable replica endpoint.
• Keep all reporting on the primary and expect automatic replica routing: Applications must use the appropriate read endpoint; creating capacity alone does not redirect queries.
• Treat a manual snapshot as automatic live database failover: Snapshots support recovery; they are not a running synchronous failover target.

Change the requirement. A Multi-AZ DB cluster or Aurora has a different readable-instance architecture; inspect the specified deployment model.

Analogy. Keep an emergency replacement and a separate reporting desk.

RDS, Aurora & database recovery

2.3 · Logical deletion

A valid table was deleted at 10:12; the RDS service is healthy and the standby has the deletion. PITR is enabled and 10:11 is within the recovery window. What is appropriate?

1. Fail over to the standby
2. Restore to a new DB at 10:11, validate and plan cutover
3. Restart the current DB
4. Restore only a snapshot taken after the 10:12 deletion

Answer & deciding boundary

Correct: Restore to a new DB at 10:11, validate and plan cutover

Clue. Recover the state before the logical error, not merely a healthy host.

• Fail over to the standby: The logical deletion has already replicated.
• Restore to a new DB at 10:11, validate and plan cutover: Recovers historical state while preserving the source for investigation.
• Restart the current DB: Does not undo committed deletion.
• Restore only a snapshot taken after the 10:12 deletion: A post-deletion recovery point retains the unwanted logical state.

Change the requirement. For a host failure without logical corruption, managed failover is usually the relevant mechanism.

Analogy. A spare ledger with the same erasure cannot recover yesterday’s entry.

RDS, Aurora & database recovery · AWS Backup & disaster recovery

2.3 · Prove the recovery objective

A backup job is green. The runbook promises recovery in one hour with no more than fifteen minutes of lost data. Select TWO necessary validations.

1. Time full restore, dependency setup and application cutover
2. Check the latest usable recovery point against the incident time
3. Assume green backup means both objectives are met
4. Time only the restore API request being accepted
5. Verify only that a backup plan exists

Answer & deciding boundary

Correct: Time full restore, dependency setup and application cutover; Check the latest usable recovery point against the incident time

Clue. Both elapsed outage and recoverable data age need evidence.

• Time full restore, dependency setup and application cutover: RTO covers usable recovery, not only API acceptance.
• Check the latest usable recovery point against the incident time: Tests whether data loss can meet RPO.
• Assume green backup means both objectives are met: A backup success does not test restoration.
• Time only the restore API request being accepted: Acceptance excludes resource readiness, dependency configuration and usable application cutover.
• Verify only that a backup plan exists: A configured plan does not prove backup job success or a working restore.

Change the requirement. If only retention compliance were asked, recovery-point retention and vault controls would be central.

Analogy. A packed parachute is not the same as a demonstrated safe landing.

AWS Backup & disaster recovery

2.3 · Version recovery

An object was overwritten yesterday in an S3 bucket that already had versioning enabled. The previous version is retained. What is the narrowest recovery?

1. Retrieve the retained prior version and verify it before restoring the current object
2. Fail over the RDS database
3. Enable versioning now and assume it recreates yesterday’s data
4. Delete the whole bucket

Answer & deciding boundary

Correct: Retrieve the retained prior version and verify it before restoring the current object

Clue. The required historical object version already exists.

• Retrieve the retained prior version and verify it before restoring the current object: Uses existing object history and avoids broad workload changes.
• Fail over the RDS database: Unrelated to the overwritten S3 object.
• Enable versioning now and assume it recreates yesterday’s data: Cannot retroactively create versions that were not retained.
• Delete the whole bucket: Destroys unrelated data and is unnecessary.

Change the requirement. If versioning was not enabled and no other recovery copy existed, enabling it now could not recover the previous content.

Analogy. Use the earlier filing revision rather than replacing the entire office.

S3 operations & protection · AWS Backup & disaster recovery

2.3 · Deregistered image with retained recovery

An eligible EBS-backed AMI was accidentally deregistered. A matching Recycle Bin rule already covered it and retention has not expired. What should be checked first?

1. Restore it through the applicable Recycle Bin recovery
2. Assume every deregistration is immediately unrecoverable
3. Create a rule now and expect it to protect past unretained deletions
4. Assume deregistration already terminated its running instances

Answer & deciding boundary

Correct: Restore it through the applicable Recycle Bin recovery

Clue. The rule existed before deletion and the retained item is still recoverable.

• Restore it through the applicable Recycle Bin recovery: Preconfigured retention can preserve a deregistered eligible image.
• Assume every deregistration is immediately unrecoverable: That ignores the specified retention mechanism.
• Create a rule now and expect it to protect past unretained deletions: Retention rules are not retroactive recovery of data that was not retained.
• Assume deregistration already terminated its running instances: Deregistration does not itself terminate instances previously launched from the image.

Change the requirement. Without applicable retention, investigate surviving snapshots/instances and reconstruct suitable image metadata if possible.

Analogy. A pre-arranged recovery bin can hold the discarded plan; adding a bin afterwards cannot recreate an already lost plan.

Images & deployment operations · AWS Backup & disaster recovery

2.3 · Durable image, unproven application state

A database application is captured in an EBS-backed AMI. The requirement is application-consistent recovery. Which statement is accurate?

1. Coordinate application consistency and test recovery; allowing reboot helps flush buffered state
2. Selecting No reboot always guarantees application consistency
3. Provision more IOPS to make an inconsistent image transactionally valid
4. Disable No reboot means prevent any reboot

Answer & deciding boundary

Correct: Coordinate application consistency and test recovery; allowing reboot helps flush buffered state

Clue. Consistency is about a coherent application state, not simply retained bytes.

• Coordinate application consistency and test recovery; allowing reboot helps flush buffered state: Durable captured blocks and a valid boot do not by themselves prove a coherent application transaction state.
• Selecting No reboot always guarantees application consistency: Skipping quiescing/reboot can preserve inconsistent in-memory versus disk state.
• Provision more IOPS to make an inconsistent image transactionally valid: I/O performance cannot reconstruct an uncoordinated application state.
• Disable No reboot means prevent any reboot: It means clearing that option and allowing reboot, not prohibiting it.

Change the requirement. For an already stopped/quiesced application with validated procedures, capture requirements may differ.

Analogy. A photograph of durable ledger pages is useful only if the pages describe a consistent point in the transaction.

Images & deployment operations · AWS Backup & disaster recovery

2.3 · New disk must avoid first-read lazy loading

A supported restored EBS workload must be fully initialised at volume creation. Which preparation directly addresses that requirement?

1. Enable FSR for the snapshot in the destination AZ, wait ready and check creation credits before creating the volume
2. Increase provisioned IOPS alone
3. Enable FSR only after creating the affected volume
4. Enable FSR in an unrelated AZ because snapshots are Regional

Answer & deciding boundary

Correct: Enable FSR for the snapshot in the destination AZ, wait ready and check creation credits before creating the volume

Clue. Immediate initialisation and steady-state I/O provisioning are separate mechanisms.

• Enable FSR for the snapshot in the destination AZ, wait ready and check creation credits before creating the volume: FSR applies to the relevant snapshot/AZ and eligible new-volume creation.
• Increase provisioned IOPS alone: Configured I/O capacity does not load missing snapshot blocks.
• Enable FSR only after creating the affected volume: It does not retroactively convert that already-created volume into an FSR creation.
• Enable FSR in an unrelated AZ because snapshots are Regional: The FSR preparation is destination-AZ specific despite the snapshot’s Regional scope.

Change the requirement. If a bounded initialisation interval is acceptable, evaluate current provisioned-initialisation-rate or manual-initialisation options.

Analogy. A faster disk motor does not pre-fill the restored pages before the first read.

EBS performance & snapshots

2.2 · All unhealthy does not mean guaranteed 503

All registered targets in an ALB target group are unhealthy. Which statement best describes the relevant distinction?

1. ALB can fail open and route to unhealthy targets; actual HTTP results still depend on the request/target
2. Every request must receive an ALB-generated 503 solely because health is Unhealthy
3. ALB runs a fresh health check before every user request
4. ASG must restart the failed application process instead of replacing an instance

Answer & deciding boundary

Correct: ALB can fail open and route to unhealthy targets; actual HTTP results still depend on the request/target

Clue. Distinguish target health, routing behaviour and the origin of an HTTP status.

• ALB can fail open and route to unhealthy targets; actual HTTP results still depend on the request/target: Health state is not a universal HTTP status mapping.
• Every request must receive an ALB-generated 503 solely because health is Unhealthy: That confuses all-unhealthy fail-open with conditions such as no registered/all-unused targets.
• ALB runs a fresh health check before every user request: Target health is evaluated periodically.
• ASG must restart the failed application process instead of replacing an instance: ASG instance replacement and application restart are different mechanisms.

Change the requirement. With healthy B available and cross-zone routing applicable, ALB normally avoids unhealthy A rather than needing all-unhealthy fail-open.

Analogy. A dispatcher choosing among bad destinations cannot guarantee what status their doors will return.

Load balancing & target health · Auto Scaling & elasticity

2.1 · Repeated cache misses overload an origin

Several CloudFront cache locations repeatedly fetch the same uncached objects. The goal is to consolidate eligible origin-bound misses with managed CloudFront functionality. What fits?

1. Origin Shield in a supported Region with low latency to the origin
2. Weighted DNS alone
3. Assume Origin Shield is a customer ElastiCache cluster
4. Move the CloudFront distribution into the S3 bucket’s Region

Answer & deciding boundary

Correct: Origin Shield in a supported Region with low latency to the origin

Clue. The missing mechanism is shared origin-miss consolidation, not merely more traffic destinations.

• Origin Shield in a supported Region with low latency to the origin: Adds a managed caching/consolidation layer before the origin.
• Weighted DNS alone: Distributes DNS answers without inherently consolidating identical origin fetches.
• Assume Origin Shield is a customer ElastiCache cluster: It is part of CloudFront’s managed caching infrastructure.
• Move the CloudFront distribution into the S3 bucket’s Region: A CloudFront distribution is global, not a Regional deployment to relocate.

Change the requirement. If values were custom application session data rather than HTTP object delivery, an application cache could be relevant.

Analogy. Several local counters can share one upstream copy desk instead of separately ordering the same item.

CloudFront & Global Accelerator · ElastiCache & cache operations

2.3 · Protection ends; deletion is separate

Compliance-mode Object Lock protected a version until yesterday. No legal hold remains and no Lifecycle expiration is configured. Must that version already be gone?

1. No; retention expiry permits eligible deletion but does not schedule it
2. Yes, Retain Until Date automatically deletes every version
3. Lifecycle must delete it even while compliance retention is active
4. A delete marker proves every retained version was destroyed

Answer & deciding boundary

Correct: No; retention expiry permits eligible deletion but does not schedule it

Clue. Preservation and cleanup are separate controls.

• No; retention expiry permits eligible deletion but does not schedule it: Automatic cleanup needs suitable version-aware Lifecycle rules or another authorised deletion action.
• Yes, Retain Until Date automatically deletes every version: It is a protection deadline, not a deletion job.
• Lifecycle must delete it even while compliance retention is active: Lifecycle cannot override active protection.
• A delete marker proves every retained version was destroyed: A marker and the protected historical versions are distinct objects/states.

Change the requirement. If suitable Lifecycle rules were configured, eligible expiration can occur asynchronously after applicable protection ends.

Analogy. A contract saying “do not shred before Friday” does not itself order shredding on Friday.

S3 operations & protection · AWS Backup & disaster recovery

2.1 · Desired fell but four members remain

An ASG has four healthy in-service members, all protected from scale-in. A valid scale-in changes desired capacity from 4 to 3. What can happen?

1. Desired becomes 3 while actual remains 4 until protection permits removal
2. Desired must remain 4 because protection freezes it
3. ASG must terminate an arbitrary protected member immediately
4. All protected members become immune to health replacement

Answer & deciding boundary

Correct: Desired becomes 3 while actual remains 4 until protection permits removal

Clue. All members are protected from the particular termination path.

• Desired becomes 3 while actual remains 4 until protection permits removal: Desired is a target; protection can prevent convergence without preventing that target update.
• Desired must remain 4 because protection freezes it: Protection controls eligible instance termination, not every desired-capacity change.
• ASG must terminate an arbitrary protected member immediately: The assumed scale-in protection blocks selecting the protected members for ordinary scale-in.
• All protected members become immune to health replacement: Scale-in protection does not prevent unhealthy replacement.

Change the requirement. If a member becomes unhealthy, replacement is a different operation.

Analogy. Changing the seat target does not evict a protected occupant.

Auto Scaling & elasticity

2.2 · Protected from API termination, then shutdown

DisableApiTermination is true. An EBS-root ASG member has InstanceInitiatedShutdownBehavior=terminate. Its administrator runs an OS shutdown. Which statement is correct?

1. Scale-in protection prevents every unhealthy replacement
2. Any AWS service can therefore ignore every protection
3. OS shutdown can terminate it; ASG can restore desired capacity
4. EC2 API protection must prevent OS shutdown

Answer & deciding boundary

Correct: OS shutdown can terminate it; ASG can restore desired capacity

Clue. The question explicitly supplies the OS terminate setting.

• Scale-in protection prevents every unhealthy replacement: The health-replacement path is not ordinary scale-in protection.
• Any AWS service can therefore ignore every protection: The documented exceptions do not establish a universal rule for all services or controls.
• OS shutdown can terminate it; ASG can restore desired capacity: API termination protection does not block the specified OS-initiated termination path.
• EC2 API protection must prevent OS shutdown: The OS shutdown behaviour is separate from direct TerminateInstances protection.

Change the requirement. With shutdown behaviour stop, it stops first; ASG can subsequently replace the stopped member.

Analogy. A lock on the front-door API is not the switch on the machine itself.

EC2 performance & capacity · Auto Scaling & elasticity

2.3 · Restore into AZ B at full initial performance

A completed Regional snapshot originated from AZ A. New volumes must be created in AZ B with eligible full initial performance. What prepares the restore?

1. Enable FSR for that snapshot in AZ B and wait for readiness plus sufficient credits
2. Enable FSR only in source AZ A
3. Increase IOPS and assume all snapshot blocks are already initialised
4. Enable FSR after creating the affected volume to retroactively initialise it

Answer & deciding boundary

Correct: Enable FSR for that snapshot in AZ B and wait for readiness plus sufficient credits

Clue. The deciding location is where the new volume is created.

• Enable FSR for that snapshot in AZ B and wait for readiness plus sufficient credits: FSR is configured for the destination snapshot/AZ pair before creating the volume.
• Enable FSR only in source AZ A: The source volume’s location does not initialise a new volume in another destination AZ.
• Increase IOPS and assume all snapshot blocks are already initialised: Provisioned performance and loading snapshot data are separate mechanisms.
• Enable FSR after creating the affected volume to retroactively initialise it: The FSR benefit applies at qualifying new-volume creation, not retroactively to the existing volume.

Change the requirement. If initialisation delay is acceptable, ordinary restore or supported initialisation-rate options may be more economical.

Analogy. Prepare the receiving workshop, not just the workshop the backup came from.

EBS performance & snapshots

2.1 · Discount commitment does not assure a launch

A workload must launch matching EC2 capacity in AZ A during an upcoming operation. It already has a Compute Savings Plan. What is still required for capacity assurance?

1. Assume a Regional RI reserves capacity in every AZ
2. Treat Savings Plan commitment as a maximum charge
3. A suitable active AZ Capacity Reservation or matching Zonal RI
4. Only increase ASG desired capacity

Answer & deciding boundary

Correct: A suitable active AZ Capacity Reservation or matching Zonal RI

Clue. The requirement is availability of matching AZ capacity, beyond pricing.

• Assume a Regional RI reserves capacity in every AZ: Regional RIs provide eligible discounts, not the Zonal capacity reservation.
• Treat Savings Plan commitment as a maximum charge: Unused commitment still costs money; eligible uncovered excess is billed separately.
• A suitable active AZ Capacity Reservation or matching Zonal RI: The billing commitment does not independently hold capacity in the required AZ.
• Only increase ASG desired capacity: Desired is a requested target, not a reservation of available EC2 capacity.

Change the requirement. Cost flexibility without a launch-capacity requirement may favour an appropriate Savings Plan alone.

Analogy. A discount voucher is not a reserved seat.

EC2 performance & capacity · Auto Scaling & elasticity

2.3 · Offline import followed by archive storage

An eligible existing Snowball Edge customer imports local data and later archives eligible objects in an S3 Glacier class. What is the correct order?

1. All new customers can order Snowball Edge without restrictions
2. Local copy → return device → AWS imports into S3 → configured Lifecycle transition
3. Snowball writes straight into Glacier without an S3 import
4. A shipped device proves S3 objects are already available

Answer & deciding boundary

Correct: Local copy → return device → AWS imports into S3 → configured Lifecycle transition

Clue. The customer is eligible, but import and archive transition are distinct stages.

• All new customers can order Snowball Edge without restrictions: Current availability is limited to existing customers; older exam onboarding assumptions need a caveat.
• Local copy → return device → AWS imports into S3 → configured Lifecycle transition: Physical transfer/import precedes the separate object storage-class transition.
• Snowball writes straight into Glacier without an S3 import: The illustrated import lands in S3; the later Lifecycle action chooses the archive class.
• A shipped device proves S3 objects are already available: Data still must be copied, returned and successfully imported.

Change the requirement. For a new customer, evaluate currently available online or physical-transfer alternatives.

Analogy. The courier delivery arrives before the warehouse files it in long-term storage.

S3 operations & protection

3.1 · Failed rollback

A stack is UPDATE_ROLLBACK_FAILED because a required permission was removed. What should the operator do after restoring that permission?

1. Run continue-update-rollback and verify final status
2. Create another change set and assume it executes
3. Delete the production stack immediately
4. Edit only local CDK code without deploying

Answer & deciding boundary

Correct: Run continue-update-rollback and verify final status

Clue. Rollback itself failed; repair it before another update.

• Run continue-update-rollback and verify final status: Resumes the failed rollback using repaired prerequisites.
• Create another change set and assume it executes: A preview does not resolve a stuck rollback.
• Delete the production stack immediately: Destructive and not required by this failure.
• Edit only local CDK code without deploying: Does not alter the current stack operation.

Change the requirement. For UPDATE_ROLLBACK_COMPLETE you can plan a corrected new update after inspection.

Analogy. Repair the exit route before trying to finish reversing the truck.

CloudFormation & CDK lifecycle

3.1 · Drift is not repair

An operator manually changes a resource setting managed by a CloudFormation stack. What does drift detection do for supported tracked properties?

1. Identifies supported differences against the stack definition
2. Repairs every possible property automatically
3. Treat NOT_CHECKED resources as confirmed IN_SYNC
4. Rewrites the template to match reality

Answer & deciding boundary

Correct: Identifies supported differences against the stack definition

Clue. Detection and remediation are separate operations.

• Identifies supported differences against the stack definition: Detection reports differences; it is not automatic reconciliation.
• Repairs every possible property automatically: Neither universal coverage nor automatic repair is guaranteed.
• Treat NOT_CHECKED resources as confirmed IN_SYNC: Unsupported or unchecked resources have not been proven free of drift.
• Rewrites the template to match reality: Not an automatic drift-detection effect.

Change the requirement. A deliberately updated template and executed change set could adopt a reviewed intended change.

Analogy. An inspection marks the deviation; it does not rebuild the wall.

CloudFormation & CDK lifecycle

3.1 · Share versus deploy

The organisation wants to deploy the same baseline stack in several accounts/Regions, and separately share an existing supported subnet. Select TWO correct tools.

1. StackSets for baseline stack instances
2. RAM for the supported existing subnet share
3. Use RAM to deploy independent baseline stacks
4. Use an SCP to create the required baseline resources
5. Assume stack deployment automatically shares every created resource

Answer & deciding boundary

Correct: StackSets for baseline stack instances; RAM for the supported existing subnet share

Clue. Deploy copies and share one resource are distinct responsibilities.

• StackSets for baseline stack instances: Deploys and manages copies with execution controls.
• RAM for the supported existing subnet share: Shares supported resources without recreating them.
• Use RAM to deploy independent baseline stacks: RAM shares supported resources; it is not the stack-copy deployment mechanism.
• Use an SCP to create the required baseline resources: SCPs restrict applicable operations; they do not provision the resources.
• Assume stack deployment automatically shares every created resource: Cross-account sharing requires an appropriate supported sharing configuration.

Change the requirement. For one account/Region only, a normal CloudFormation stack may suffice.

Analogy. Print copies of the plan with StackSets; grant access to one existing room with RAM.

Multi-account operations · CloudFormation & CDK lifecycle

3.1 · Container rollout failure

Every new ECS task stops with an image-pull permission error; old tasks remain healthy. What should be examined first?

1. Task execution-role registry permissions and image path/connectivity
2. Only the application business-role SQL permissions
3. Increase task CPU and memory as the permission fix
4. Change the application runtime command before fixing the image pull

Answer & deciding boundary

Correct: Task execution-role registry permissions and image path/connectivity

Clue. The failure happens before application execution.

• Task execution-role registry permissions and image path/connectivity: These govern pulling the image; inspect events for the exact failure.
• Only the application business-role SQL permissions: These apply after startup and do not explain the pull error.
• Increase task CPU and memory as the permission fix: Resources cannot compensate for a denied image-pull operation.
• Change the application runtime command before fixing the image pull: The application command is not reached when its image cannot be pulled.

Change the requirement. If the image pulled but the app failed to query DynamoDB, investigate the task role and app configuration.

Analogy. The installer cannot fetch the kit; debugging the installed program is premature.

Images & deployment operations

3.2 · Managed node offline

A private EC2 instance has SSM Agent installed but appears offline. No inbound SSH is allowed. Select TWO relevant checks.

1. Instance profile and required Systems Manager permissions
2. Outbound HTTPS/DNS access to required service endpoints
3. Open inbound SSH to the world
4. Permit only inbound HTTPS on the instance SG
5. Restart the application process without checking agent identity or network

Answer & deciding boundary

Correct: Instance profile and required Systems Manager permissions; Outbound HTTPS/DNS access to required service endpoints

Clue. Agent, identity and outbound network path are prerequisites.

• Instance profile and required Systems Manager permissions: The agent needs an authorised identity.
• Outbound HTTPS/DNS access to required service endpoints: The agent initiates service connectivity.
• Open inbound SSH to the world: Not required for Systems Manager connectivity.
• Permit only inbound HTTPS on the instance SG: The agent needs outbound service access; opening an inbound port does not supply it.
• Restart the application process without checking agent identity or network: Does not repair the agent prerequisites that determine management connectivity.

Change the requirement. For a running Automation failing an EC2 API step, inspect the automation role rather than only node connectivity.

Analogy. A remote technician needs both an access card and a phone line.

Systems Manager operations · Endpoints & private connectivity

3.2 · Bounded operational repair

A recurring repair needs approval, several AWS API steps, concurrency limits and execution history. What is the best starting capability?

1. Systems Manager Automation runbook
2. An untracked SSH command on every instance
3. Only an SNS topic
4. A CloudWatch dashboard

Answer & deciding boundary

Correct: Systems Manager Automation runbook

Clue. Repeatable governed maintenance is the requirement.

• Systems Manager Automation runbook: Coordinates operational steps with approvals and controls.
• An untracked SSH command on every instance: Lacks the stated coordinated controls.
• Only an SNS topic: Notifies but does not perform the multi-step procedure.
• A CloudWatch dashboard: Visualises evidence without executing the repair.

Change the requirement. For a simple stateless custom transformation, Lambda may be sufficient; EventBridge can trigger either.

Analogy. Use the controlled repair checklist rather than a broadcast message.

Systems Manager operations · EventBridge, SNS & remediation

3.1 · Repeatable AMI rollout

A patched AMI has passed tests. New ASG instances must use it, and existing instances must be replaced in controlled batches. Select TWO actions.

1. Publish/select an appropriate launch-template version containing the AMI
2. Run a configured instance refresh with health/warm-up controls
3. Only change a tag on the old instances
4. Assume copying an AMI updates running instances
5. Delete all targets before checking healthy capacity

Answer & deciding boundary

Correct: Publish/select an appropriate launch-template version containing the AMI; Run a configured instance refresh with health/warm-up controls

Clue. Artifact selection for new launches and replacement of existing instances are separate steps.

• Publish/select an appropriate launch-template version containing the AMI: Defines the artifact used for subsequent launches.
• Run a configured instance refresh with health/warm-up controls: Replaces existing instances gradually under the chosen deployment constraints.
• Only change a tag on the old instances: Does not replace the running machine image.
• Assume copying an AMI updates running instances: AMI creation/copying does not update already running instances.
• Delete all targets before checking healthy capacity: Discards the requested controlled rollout and availability checks.

Change the requirement. If only future scale-out needed the AMI, updating the launch template could be sufficient without refreshing the current fleet.

Analogy. Update the installation kit, then schedule controlled replacements.

Images & deployment operations · Auto Scaling & elasticity

3.2 · Repair when the agent cannot run

An important EBS-backed instance has an impaired OS and no working SSM Agent connection. The approved goal is root-volume repair, not replacement. Which capability can fit?

1. A suitable EC2Rescue Automation offline workflow with a temporary helper
2. Repeat Run Command and assume it executes despite the missing agent path
3. Assume installing the agent in the image proves it is now connected
4. Replace it via ASG while expecting to retain the same repaired OS instance

Answer & deciding boundary

Correct: A suitable EC2Rescue Automation offline workflow with a temporary helper

Clue. The target OS is unavailable, but the approved procedure can use external API-driven helper resources.

• A suitable EC2Rescue Automation offline workflow with a temporary helper: Automation can orchestrate AWS APIs and offline disk inspection instead of relying on code inside the impaired OS.
• Repeat Run Command and assume it executes despite the missing agent path: Ordinary agent-based commands still need a working managed-node connection.
• Assume installing the agent in the image proves it is now connected: Installed software may be stopped or unable to reach its endpoints.
• Replace it via ASG while expecting to retain the same repaired OS instance: Replacement and repairing this particular root disk are different outcomes.

Change the requirement. For disposable stateless ASG capacity, replacement may be preferable; do not accidentally mix it with an offline repair procedure.

Analogy. Repair the removed disk at a workshop rather than trying to run a command on a machine that cannot boot.

Systems Manager operations · EBS performance & snapshots

3.1 · Launch from an image is not disk transfer

An ASG launches another instance from an EBS-backed AMI. The original instance still uses its root volume. What normally happens?

1. Fresh root volumes are created from the AMI’s referenced snapshots
2. The original root disk is detached and moved to each new instance
3. The Launch Template is itself the root disk snapshot
4. The snapshot chooses instance type, SG and every launch setting automatically

Answer & deciding boundary

Correct: Fresh root volumes are created from the AMI’s referenced snapshots

Clue. Image reference and new resource creation differ from reattaching an existing resource.

• Fresh root volumes are created from the AMI’s referenced snapshots: The image describes boot metadata and captured disk state; the original working disk remains attached.
• The original root disk is detached and moved to each new instance: That is not the normal image-based launch mechanism.
• The Launch Template is itself the root disk snapshot: It supplies image and launch settings; it is not a disk backup.
• The snapshot chooses instance type, SG and every launch setting automatically: Those launch choices are not all encoded by snapshot data alone.

Change the requirement. If explicitly recovering one existing data disk, a same-AZ detach/attach workflow is a different operation.

Analogy. A photocopied installation image creates another disk; it does not move the original disk.

Images & deployment operations · EBS performance & snapshots · Auto Scaling & elasticity

3.1 · Share for launch versus share for copy

Another account will launch an instance from a shared unencrypted AMI in the same Region. Must its backing snapshots always be shared separately for that launch?

1. No; AMI sharing provides snapshot access needed for launch
2. Yes, launching and copying always have identical permissions
3. The AMI must always be copied merely to use another account
4. The AMI is copied automatically to every AZ

Answer & deciding boundary

Correct: No; AMI sharing provides snapshot access needed for launch

Clue. Name both the operation and changed boundary: launch, same Region, another account.

• No; AMI sharing provides snapshot access needed for launch: Copying the shared image has different backing-storage permission requirements.
• Yes, launching and copying always have identical permissions: This removes the documented distinction between the operations.
• The AMI must always be copied merely to use another account: Same-Region cross-account launch permission can be sufficient in this unencrypted example.
• The AMI is copied automatically to every AZ: An AMI is Regional; another AZ does not require a separate image copy.

Change the requirement. Encrypted sharing adds eligible KMS access; copying may additionally require storage read permissions.

Analogy. Permission to run the installation kit is not identical to permission to copy and redistribute it.

Images & deployment operations · KMS, encryption & secrets

3.1 · An allowed update must not replace the database

An operator may update a stack. A safeguard must reject accidental replacement of its existing database during updates while preserving ordinary stack administration. Which control fits?

1. Stack termination protection alone
2. DeletionPolicy: Retain alone
3. Only grant broader IAM permissions
4. A stack policy denying Update:Replace for that logical resource

Answer & deciding boundary

Correct: A stack policy denying Update:Replace for that logical resource

Clue. The forbidden operation is replacement during a stack update.

• Stack termination protection alone: Protects deletion of the whole stack, not every replacement during an update.
• DeletionPolicy: Retain alone: Controls resource preservation at deletion/removal boundaries; it is not the requested update-action prohibition.
• Only grant broader IAM permissions: More caller permissions cannot implement a guard against an unwanted protected update.
• A stack policy denying Update:Replace for that logical resource: Stack policies restrict existing-resource update actions independently of the caller’s UpdateStack permission.

Change the requirement. If the requirement were to prevent deleting the entire stack, choose termination protection.

Analogy. Permission to renovate a building is separate from a rule protecting one room.

CloudFormation & CDK lifecycle · IAM access investigation

3.1 · The second Region reports AlreadyExists

The same account deploys a template in Sydney and Melbourne. Both templates declare RoleName: shared-app. The second fails because the role exists. What is the clearest correction when each deployment needs its own role?

1. Change the instance subnet
2. Assume no resources were created because the stack failed
3. Generate names or include Region/stack identity
4. Retry until CloudFormation silently adopts it

Answer & deciding boundary

Correct: Generate names or include Region/stack identity

Clue. A new create operation is colliding with an account-wide physical name.

• Change the instance subnet: Subnet placement does not alter the IAM role’s account-wide namespace.
• Assume no resources were created because the stack failed: Earlier successful creates can precede a later failure; inspect rollback and stack events.
• Generate names or include Region/stack identity: IAM names are account-wide although the two owning stacks are Regional.
• Retry until CloudFormation silently adopts it: Matching a name does not automatically import an existing resource into a different stack.

Change the requirement. For one intentionally shared role, keep a single owner and pass its ARN instead of creating it twice.

Analogy. Two regional construction teams cannot separately register the same account-wide name.

CloudFormation & CDK lifecycle · IAM access investigation

3.1 · One baseline across account–Region targets

An operations team must maintain the same approved template in two accounts and two Regions, controlling Region order and rollout concurrency. What fits?

1. Share an AMI instead of deploying the baseline
2. CloudFormation StackSets
3. One ordinary stack becomes global
4. Use unrelated templates as an arbitrary dependency graph in one StackSet

Answer & deciding boundary

Correct: CloudFormation StackSets

Clue. The same template is repeated at explicit account–Region targets.

• Share an AMI instead of deploying the baseline: An AMI supplies launch artifacts, not every resource in the infrastructure baseline.
• CloudFormation StackSets: Creates and manages a distinct stack for each selected account–Region combination.
• One ordinary stack becomes global: A normal stack is Regional and does not automatically span target accounts and Regions.
• Use unrelated templates as an arbitrary dependency graph in one StackSet: A StackSet has a common template, not a general workflow for unrelated templates.

Change the requirement. Different templates with cross-workflow dependencies need a separate orchestration design.

Analogy. One blueprint produces separate buildings; it does not produce one building in four places.

Multi-account operations · CloudFormation & CDK lifecycle

3.1 · Encrypted image moves to another Region

One account needs to copy its EBS-backed AMI from Sydney to Melbourne. The source snapshots use aws/ebs. Which statement is accurate?

1. Use the Sydney AMI ID directly in Melbourne
2. An ordinary customer-managed key is global
3. A same-account cross-Region copy can use an appropriate destination-Region key
4. AWS-managed encryption prevents every AMI copy

Answer & deciding boundary

Correct: A same-account cross-Region copy can use an appropriate destination-Region key

Clue. Account ownership stays the same; the Region changes.

• Use the Sydney AMI ID directly in Melbourne: AMI IDs and their usable resources are Regional.
• An ordinary customer-managed key is global: KMS keys are Regional; multi-Region keys still have Regional primary/replica resources.
• A same-account cross-Region copy can use an appropriate destination-Region key: The cross-account restriction on sharing aws/ebs does not prohibit this same-account Region-copy workflow.
• AWS-managed encryption prevents every AMI copy: That confuses cross-account key sharing with a separate cross-Region copy operation.

Change the requirement. Another account using the encrypted image also requires appropriate sharing and customer-managed key access.

Analogy. Moving a regional copy and lending another company your key are different operations.

Images & deployment operations · KMS, encryption & secrets

3.2 · Snapshots every five minutes

An existing EBS volume needs a recurring CreateSnapshot request every five minutes. No custom processing is required. Which modern configuration fits?

1. DLM five-minute lifecycle schedule
2. AWS Backup snapshot rule every five minutes
3. Lambda function without a trigger
4. EventBridge Scheduler rate(5 minutes) → authorised EC2 CreateSnapshot target

Answer & deciding boundary

Correct: EventBridge Scheduler rate(5 minutes) → authorised EC2 CreateSnapshot target

Clue. The explicit sub-hour interval changes the otherwise useful managed-lifecycle answer.

• DLM five-minute lifecycle schedule: DLM custom snapshot schedules have a one-hour minimum, not the requested five-minute interval.
• AWS Backup snapshot rule every five minutes: Scheduled snapshot-backup rules have a minimum hourly frequency; continuous backup is a different supported-resource feature.
• Lambda function without a trigger: Custom function code does not by itself define recurring execution.
• EventBridge Scheduler rate(5 minutes) → authorised EC2 CreateSnapshot target: Scheduler can invoke the supported API directly; snapshot completion and retention remain separate concerns.

Change the requirement. Hourly EBS creation plus retention/deletion points to DLM; central multi-service protection points to AWS Backup.

Analogy. A recurring timer and a retention clerk perform different jobs.

EventBridge, SNS & remediation · EBS performance & snapshots · AWS Backup & disaster recovery

4.1 · Guardrail denial

A member-account role has an identity Allow for an operation, but an applicable SCP explicitly denies it. What happens?

1. Denied
2. Allowed because the role is trusted
3. Allowed because SCPs grant permissions
4. Allowed because a permissions-boundary Allow overrides the SCP Deny

Answer & deciding boundary

Correct: Denied

Clue. An applicable explicit deny is decisive.

• Denied: An applicable explicit deny overrides the allow.
• Allowed because the role is trusted: Trust establishes assumption, not exemption from guardrails.
• Allowed because SCPs grant permissions: SCPs limit available permissions; they do not grant an action to a role.
• Allowed because a permissions-boundary Allow overrides the SCP Deny: A boundary is another limit; it cannot override an applicable explicit deny.

Change the requirement. If no limiting deny applied, evaluate the remaining applicable permissions and resource-policy conditions.

Analogy. A room pass does not override a building-wide prohibition.

IAM access investigation · Multi-account operations

4.1 · Continuous property checks

An operator must record configuration history and continuously evaluate approved resource settings across accounts. Select TWO needed elements.

1. Appropriate Config recorders and rules in source accounts/Regions
2. An aggregator for the central supported view
3. Only an Artifact report
4. Configure only an aggregator and disable source recorders
5. Use CloudTrail alone to evaluate and enforce every resource property rule

Answer & deciding boundary

Correct: Appropriate Config recorders and rules in source accounts/Regions; An aggregator for the central supported view

Clue. Central visibility depends on configured source evidence.

• Appropriate Config recorders and rules in source accounts/Regions: Produce the history and evaluations.
• An aggregator for the central supported view: Collects views but does not replace source recording.
• Only an Artifact report: Reports AWS compliance evidence, not customer resource changes.
• Configure only an aggregator and disable source recorders: The central view cannot substitute for the required recording/evaluation at sources.
• Use CloudTrail alone to evaluate and enforce every resource property rule: API audit evidence is useful but is not Config configuration-rule evaluation.

Change the requirement. To identify which API actor changed a setting, add CloudTrail evidence.

Analogy. A central register needs inspections actually performed at each site.

Config & continuous compliance · CloudTrail & change evidence

4.2 · Encrypted object denied

A role can access a bucket, but GetObject fails for an SSE-KMS object using a customer-managed key. Select TWO relevant checks.

1. Key policy/IAM/grants for kms:Decrypt
2. Key state, Region and required encryption context
3. Add another s3:GetObject Allow without checking key access
4. Assume bucket permission always includes key use
5. Enable key rotation and expect it to override the denied policy

Answer & deciding boundary

Correct: Key policy/IAM/grants for kms:Decrypt; Key state, Region and required encryption context

Clue. The encrypted data and cryptographic key have separate controls.

• Key policy/IAM/grants for kms:Decrypt: KMS authorisation is distinct from object access.
• Key state, Region and required encryption context: Even otherwise allowed access can fail if the key or context is wrong.
• Add another s3:GetObject Allow without checking key access: Repeating resource permission does not grant the missing cryptographic permission.
• Assume bucket permission always includes key use: Incorrect separation of permissions.
• Enable key rotation and expect it to override the denied policy: Rotation changes cryptographic material management, not authorisation decisions.

Change the requirement. For SSE-S3, customer KMS decrypt permission would not be the corresponding dependency.

Analogy. The cabinet pass and the key-use permission are separate.

KMS, encryption & secrets

4.2 · Find the right security source

A report lists a vulnerable package version on supported EC2 workloads. Which service most directly supplies this assessment?

1. Inspector
2. Macie
3. GuardDuty
4. Artifact

Answer & deciding boundary

Correct: Inspector

Clue. Package vulnerability assessment, rather than data discovery or API auditing.

• Inspector: Assesses supported workload software vulnerabilities/exposure.
• Macie: Discovers sensitive S3 data.
• GuardDuty: Investigates supported threat/activity signals rather than replacing Inspector package assessment.
• Artifact: Provides AWS compliance documentation.

Change the requirement. Suspicious credential activity would point toward GuardDuty investigation.

Analogy. Use the mechanical inspection report for a faulty component, not a document classification report.

Security findings & classification

4.2 · Certificate placement

An ALB in ap-southeast-2 needs an ACM certificate for its HTTPS listener. A matching certificate exists only in us-east-1. What is required?

1. Request/import a suitable certificate in ap-southeast-2 and attach it
2. Attach the us-east-1 certificate directly because all ACM certificates are global
3. Change the target group without obtaining a regional listener certificate
4. Disable TLS permanently

Answer & deciding boundary

Correct: Request/import a suitable certificate in ap-southeast-2 and attach it

Clue. Certificate Region is determined by the TLS termination service.

• Request/import a suitable certificate in ap-southeast-2 and attach it: ALB certificate resources must be in its Region; verify domain validation and hostname coverage.
• Attach the us-east-1 certificate directly because all ACM certificates are global: ACM certificates used by ALB are regional.
• Change the target group without obtaining a regional listener certificate: Backend target selection does not satisfy the frontend certificate Region requirement.
• Disable TLS permanently: Does not meet the HTTPS requirement.

Change the requirement. For a CloudFront viewer certificate, ACM in us-east-1 is the required special case.

Analogy. The right identity document must be available at the endpoint that presents it.

ACM & encrypted connections · Load balancing & target health

4.2 · Same-account encrypted ASG launch

An ASG cannot launch from an image encrypted under a customer-managed key in its own account. The application role has decrypt access. Which identity still needs the documented launch-time key permissions?

1. The ASG service-linked role
2. Only the application instance profile again
3. A new cross-account AssumeRole session, despite same-account ownership
4. Any IAM user with console sign-in but no key policy access

Answer & deciding boundary

Correct: The ASG service-linked role

Clue. The failure precedes application startup; authorise the launch-time service identity.

• The ASG service-linked role: It participates in provisioning the encrypted volumes before the application instance profile can run.
• Only the application instance profile again: Runtime application permission does not authorise the launch workflow.
• A new cross-account AssumeRole session, despite same-account ownership: No foreign account is specified; assumption is not the missing control in this question.
• Any IAM user with console sign-in but no key policy access: Console authentication does not supply the required KMS authorisation.

Change the requirement. With an external key owner, use the documented cross-account key-policy and grant workflow.

Analogy. Give the installation crew permission to open the kit; the eventual resident’s key is a different permission.

KMS, encryption & secrets · Images & deployment operations · Auto Scaling & elasticity

4.2 · Cross-account key: grant, not role assumption

The ASG is in account A; its image’s snapshots use a customer-managed KMS key in account B. AMI access is valid. Which additional AWS-documented combination enables the ASG launch identity?

1. Suitable key policy plus an explicit KMS grant to the ASG service-linked role
2. Only AssumeRole into account B with no key grant
3. Only add the app instance profile to an S3 bucket policy
4. Copy and re-encrypt as the only possible solution

Answer & deciding boundary

Correct: Suitable key policy plus an explicit KMS grant to the ASG service-linked role

Clue. The deciding fact is that key ownership differs from ASG ownership.

• Suitable key policy plus an explicit KMS grant to the ASG service-linked role: The external key owner must authorise the documented cross-account grant path.
• Only AssumeRole into account B with no key grant: Role assumption is not the prescribed ASG service-linked-role KMS grant mechanism.
• Only add the app instance profile to an S3 bucket policy: That addresses neither the launch-time identity nor the encrypted EBS key.
• Copy and re-encrypt as the only possible solution: That can be an alternative, but is not mandatory when supported key-policy/grant access is configured.

Change the requirement. For a same-account key, configure the service-linked role’s documented key policy instead of assuming foreign ownership.

Analogy. The other building can authorise a specific installation crew through a key grant without lending that crew an employee identity.

KMS, encryption & secrets · Images & deployment operations · Auto Scaling & elasticity

4.1 · Object access audit coverage and cost

A management-event trail exists. The team needs CloudTrail identity evidence for S3 GetObject operations. Which statement is accurate?

1. Configure appropriate object data-event selectors and account for data-event charges
2. Assume management event history already includes every GetObject
3. Treat best-effort server access logs as a guaranteed immediate complete CloudTrail feed
4. Assume no S3 server-log delivery fee means every logging destination and query is free

Answer & deciding boundary

Correct: Configure appropriate object data-event selectors and account for data-event charges

Clue. Choose the evidence type and event coverage before assuming a trail satisfies the audit requirement.

• Configure appropriate object data-event selectors and account for data-event charges: Management events alone do not provide the requested object-level coverage.
• Assume management event history already includes every GetObject: Object data operations require their own applicable logging configuration.
• Treat best-effort server access logs as a guaranteed immediate complete CloudTrail feed: Different delivery/completeness and identity-evidence semantics apply.
• Assume no S3 server-log delivery fee means every logging destination and query is free: Storage/access/analysis cost remains, and other delivery destinations can have ingestion charges.

Change the requirement. For best-effort access analysis with logs delivered to S3, the service’s direct delivery fee model differs.

Analogy. A register of administrative changes does not automatically contain every document read.

S3 operations & protection · CloudTrail & change evidence

4.1 · Copy HR and Audit objects into Finance

A Finance identity can write its destination bucket. HR and Audit must permit that identity to copy selected source objects. Which approach keeps the permission path simplest?

1. Grant only source GetObject because CopyObject needs no destination permission
2. Grant Finance source GetObject in its identity policy and source bucket policies, keeping Finance credentials
3. Assume an HR role and automatically inherit Finance write access
4. Put a role trust policy on the S3 bucket

Answer & deciding boundary

Correct: Grant Finance source GetObject in its identity policy and source bucket policies, keeping Finance credentials

Clue. The same effective principal must be allowed at both ends.

• Grant only source GetObject because CopyObject needs no destination permission: The operation also requires the applicable destination PutObject permission.
• Grant Finance source GetObject in its identity policy and source bucket policies, keeping Finance credentials: The same copy credentials can then satisfy both source reads and destination writes.
• Assume an HR role and automatically inherit Finance write access: Assumed-role credentials do not union their permissions with the original user’s Finance permissions.
• Put a role trust policy on the S3 bucket: S3 bucket policies grant resource access; an IAM role trust policy governs role assumption.

Change the requirement. A deliberately authorised source role could work if it also has the destination access; it is not automatic.

Analogy. Changing badges does not keep the doors your previous badge opened.

IAM access investigation · S3 operations & protection

5.1 · Private S3 route

Private EC2 instances in one VPC need same-Region S3 API access without NAT. What is usually the appropriate lowest-overhead endpoint?

1. S3 gateway endpoint associated with relevant route tables
2. Internet gateway alone with no addressing changes
3. A DNS alias without any network path
4. An S3 gateway endpoint security group

Answer & deciding boundary

Correct: S3 gateway endpoint associated with relevant route tables

Clue. Same-VPC gateway endpoint use case, not remote on-premises access.

• S3 gateway endpoint associated with relevant route tables: Provides a prefix-list route; IAM/bucket/KMS access still applies.
• Internet gateway alone with no addressing changes: Does not give private-only IPv4 instances direct internet access.
• A DNS alias without any network path: Names do not provide routing.
• An S3 gateway endpoint security group: Gateway endpoints do not use interface ENI security groups.

Change the requirement. For supported remote/hybrid S3 access through private ENIs, consider an interface endpoint and its DNS/cost model.

Analogy. Choose the direct service road instead of buying an internet exit.

Endpoints & private connectivity

5.1 · Private egress cost

A zonal NAT gateway in AZ A carries large egress from workloads in AZ B. Which change should be evaluated against availability and cost requirements?

1. AZ-aligned NAT paths and applicable service endpoints
2. Assume every additional NAT is always cheaper
3. Send arbitrary internet egress through an S3 gateway endpoint
4. Choose interface endpoints for every service without comparing charges

Answer & deciding boundary

Correct: AZ-aligned NAT paths and applicable service endpoints

Clue. Compare processing, cross-AZ transfer and availability together.

• AZ-aligned NAT paths and applicable service endpoints: Can reduce cross-AZ dependency/transfer; compare added NAT hourly cost and endpoint charges.
• Assume every additional NAT is always cheaper: Hourly and volume costs vary.
• Send arbitrary internet egress through an S3 gateway endpoint: The endpoint routes supported S3 traffic; it is not a general internet egress service.
• Choose interface endpoints for every service without comparing charges: Availability, service support, hourly cost, data processing and AZ traffic still need evaluation.

Change the requirement. At very low volume a central path may be cheaper if its resilience trade-off is accepted.

Analogy. A local exit avoids a cross-town trip, but another exit has its own upkeep cost.

VPC routes, subnets & filters · Endpoints & private connectivity

5.2 · Private-name resolution

An AWS instance resolves an internal private hosted-zone name, but on-premises clients cannot. What should be checked first?

1. Resolver inbound endpoint, conditional forwarding and its network path
2. Change only a public hosted-zone record for the private name
3. Add only an AWS outbound Resolver endpoint for queries coming from on premises
4. Lower the private record TTL without establishing forwarding

Answer & deciding boundary

Correct: Resolver inbound endpoint, conditional forwarding and its network path

Clue. The failure is scoped to hybrid DNS clients.

• Resolver inbound endpoint, conditional forwarding and its network path: Enables hybrid clients to query the appropriate AWS resolver path.
• Change only a public hosted-zone record for the private name: Does not configure on-premises access to the intended private DNS view.
• Add only an AWS outbound Resolver endpoint for queries coming from on premises: Inbound and outbound endpoint directions differ; remote queries need the appropriate inbound resolution path.
• Lower the private record TTL without establishing forwarding: Changes cache time, not access to the resolver that can answer the private name.

Change the requirement. If DNS answered correctly but the TCP connection timed out, investigate routes/filters/target.

Analogy. The address exists in the branch directory but the head office cannot reach that directory.

Route 53 & DNS operations · Endpoints & private connectivity

5.2 · Incorrect cached language

CloudFront forwards lang to an origin that varies content by language, but its cache key ignores lang. Users receive another language. What fixes correctness?

1. Include lang in the appropriate cache policy and address existing entries
2. Lower TTL only
3. Add lang only to the origin request policy, leaving the cache key unchanged
4. Add an unrelated header to the cache key while still ignoring lang

Answer & deciding boundary

Correct: Include lang in the appropriate cache policy and address existing entries

Clue. The cache treats different content variants as the same key.

• Include lang in the appropriate cache policy and address existing entries: Separates response variants.
• Lower TTL only: Shortens the wrong sharing interval without fixing the key.
• Add lang only to the origin request policy, leaving the cache key unchanged: Forwarding a value does not necessarily partition cached responses by that value.
• Add an unrelated header to the cache key while still ignoring lang: Does not distinguish the response dimension causing the incorrect language reuse.

Change the requirement. If the response never varied by language, excluding lang would improve reuse without harming correctness.

Analogy. Different editions need different shelf labels.

CloudFront & Global Accelerator

5.3 · Response-only block

For a browser connection browser:54321 → ALB:443, a stateless subnet NACL permits inbound 443 but blocks outbound destination 54321. What occurs?

1. The response can be blocked; allow the relevant ephemeral return range
2. The inbound rule automatically permits the return
3. Change only the backend SG to repair the ALB subnet outbound NACL
4. Outbound destination 443 alone fixes this browser response

Answer & deciding boundary

Correct: The response can be blocked; allow the relevant ephemeral return range

Clue. Response destination differs from request destination.

• The response can be blocked; allow the relevant ephemeral return range: NACLs independently evaluate both directions.
• The inbound rule automatically permits the return: That describes stateful SG handling, not NACLs.
• Change only the backend SG to repair the ALB subnet outbound NACL: A different security boundary cannot override this explicit return-path filter.
• Outbound destination 443 alone fixes this browser response: The browser response destination is its ephemeral port.

Change the requirement. For a security group tracking the established allowed flow, return traffic is automatically permitted.

Analogy. A two-way trip needs the return gate open too.

VPC routes, subnets & filters · Network evidence & protection

5.3 · Model versus live traffic

Reachability Analyzer reports a supported path reachable, but the application still times out. Select TWO useful next checks.

1. Application listener, target health and OS firewall
2. Actual flow/access logs and measured network/application outcome
3. Conclude every packet must succeed
4. Assume a correct DNS answer proves the application is healthy
5. Treat Flow Logs ACCEPT as business success

Answer & deciding boundary

Correct: Application listener, target health and OS firewall; Actual flow/access logs and measured network/application outcome

Clue. A configuration model and a live application test prove different things.

• Application listener, target health and OS firewall: Configuration modelling does not prove the process is accepting traffic.
• Actual flow/access logs and measured network/application outcome: Tests real requests at the relevant time and source.
• Conclude every packet must succeed: Modelled reachability is not a live traffic guarantee.
• Assume a correct DNS answer proves the application is healthy: Name resolution does not prove the target process is listening or responding.
• Treat Flow Logs ACCEPT as business success: Acceptance is not an application result.

Change the requirement. If the model identified a blocking route, correct that proven dependency before application tuning.

Analogy. A clear road map does not prove the shop is open.

Network evidence & protection · Load balancing & target health

5.3 · Same VPC, different subnet, SQL timeout

An EC2 app and RDS MySQL instance use different subnets in one VPC. Local routes are intact, NACLs permit both directions, DNS is correct and MySQL is listening. The DB SG has no app ingress. What fixes the first proven block?

1. Allow the database port from the app SG in the DB SG
2. Create VPC peering between the two subnets
3. Add a NAT gateway to the database subnet
4. Grant the app role AdministratorAccess

Answer & deciding boundary

Correct: Allow the database port from the app SG in the DB SG

Clue. Evidence already establishes routing; the missing control is database ingress.

• Allow the database port from the app SG in the DB SG: The routing path exists; resource-level ingress is missing.
• Create VPC peering between the two subnets: Peering joins VPCs, not subnets already sharing the VPC local path.
• Add a NAT gateway to the database subnet: NAT is not required for this same-VPC private database connection.
• Grant the app role AdministratorAccess: IAM permissions do not open the database’s network security group.

Change the requirement. If the route were blackholed by a deliberate routing change, fix the proven path first.

Analogy. The road reaches the building, but its gate still needs to admit the visitor.

VPC routes, subnets & filters · RDS, Aurora & database recovery

5.1 · Custom NACL starts closed

A routed app-to-DB path uses a newly created custom NACL with no allow rules and a new DB SG with no inbound rules. Which TWO configurations are needed for the assumed TCP path?

1. DB SG ingress on the database port from the app SG
2. Custom NACL rules for the request and relevant return traffic
3. Rely on the default NACL allow rules in this custom NACL
4. Assume the default SG self-reference opens every new SG
5. Enable an egress-only IGW for private IPv4 SQL

Answer & deciding boundary

Correct: DB SG ingress on the database port from the app SG; Custom NACL rules for the request and relevant return traffic

Clue. Name the exact initial control type: custom NACL and custom SG.

• DB SG ingress on the database port from the app SG: New custom SGs do not start with arbitrary inbound access.
• Custom NACL rules for the request and relevant return traffic: A custom NACL initially denies and is stateless.
• Rely on the default NACL allow rules in this custom NACL: A newly created custom NACL does not inherit the default NACL’s allow-all rules.
• Assume the default SG self-reference opens every new SG: That self-reference applies to the default SG’s members, not every group.
• Enable an egress-only IGW for private IPv4 SQL: An egress-only IGW is IPv6 internet egress, not this local SQL path.

Change the requirement. With an unchanged default NACL, its initial allow rules would remove that particular NACL block; DB SG ingress could still be needed.

Analogy. A new checkpoint can start shut even though the site’s original checkpoint started open.

VPC routes, subnets & filters

5.1 · Public route but no public IPv4

A subnet routes 0.0.0.0/0 to an IGW, but an instance has only private IPv4. Filters are valid. What is still needed for direct IPv4 internet access?

1. Suitable public IPv4/EIP addressing on the instance
2. Only a larger instance type
3. An egress-only IGW for its private IPv4
4. A different subnet name

Answer & deciding boundary

Correct: Suitable public IPv4/EIP addressing on the instance

Clue. Direct IPv4 access requires both the path and suitable public addressing.

• Suitable public IPv4/EIP addressing on the instance: The IGW route alone does not supply a direct public IPv4 identity.
• Only a larger instance type: CPU and memory do not supply missing public addressing.
• An egress-only IGW for its private IPv4: That gateway supports IPv6, not direct IPv4 connectivity.
• A different subnet name: Names do not change addressing, routes or traffic controls.

Change the requirement. If the instance must remain private, use an appropriate NAT/endpoint path instead of direct public addressing.

Analogy. An exit road does not automatically give the vehicle a public return address.

VPC routes, subnets & filters

5.1 · IPv6 outbound only

Instances with deliberately assigned IPv6 addresses need outbound internet connections and replies, with no new inbound internet connections. Which gateway fits?

1. Egress-only internet gateway with the IPv6 route and controls
2. Public NAT gateway as if it were an IPv6 egress-only IGW
3. Only an IPv4 route to an IGW
4. No configuration because every EC2 instance automatically has IPv6

Answer & deciding boundary

Correct: Egress-only internet gateway with the IPv6 route and controls

Clue. The protocol and initiation direction jointly decide the gateway.

• Egress-only internet gateway with the IPv6 route and controls: Designed for outbound-initiated IPv6 internet communication.
• Public NAT gateway as if it were an IPv6 egress-only IGW: Private IPv4 NAT egress and native IPv6 outbound-only routing are different mechanisms.
• Only an IPv4 route to an IGW: An IPv4 route does not route the separate IPv6 address space.
• No configuration because every EC2 instance automatically has IPv6: IPv6 CIDR/address assignment and routing are not automatic for every instance.

Change the requirement. For private IPv4 outbound internet traffic, a suitable NAT path would be relevant.

Analogy. Choose the gate for the address family printed on the vehicle’s address.

VPC routes, subnets & filters

5.2 · Private origin and website endpoint

A distribution uses an S3 website endpoint. The requirement is authenticated CloudFront-only S3 access using OAC. Which change fits?

1. Use the S3 REST origin with appropriate OAC and a scoped bucket policy
2. Attach OAC directly to the website endpoint
3. Add HTTPS to the S3 website endpoint URL and assume support
4. Treat a secret Referer header as equivalent to OAC authentication

Answer & deciding boundary

Correct: Use the S3 REST origin with appropriate OAC and a scoped bucket policy

Clue. The origin endpoint type determines the authentication and transport features available.

• Use the S3 REST origin with appropriate OAC and a scoped bucket policy: OAC supports the REST-origin model; the website endpoint remains a custom HTTP origin.
• Attach OAC directly to the website endpoint: OAC/OAI do not apply to the website custom-origin endpoint.
• Add HTTPS to the S3 website endpoint URL and assume support: S3 website endpoints do not provide HTTPS themselves.
• Treat a secret Referer header as equivalent to OAC authentication: A spoofable header condition is a limited workaround, not the same trust mechanism.

Change the requirement. When website behaviour is deliberately retained, evaluate its custom-origin limitations rather than claiming OAC support.

Analogy. A different sign above the website entrance does not turn it into the authenticated API entrance.

CloudFront & Global Accelerator · S3 operations & protection

5.3 · Explicit S3 wrong-signing-Region error

A bucket name was deleted and recreated in Singapore. CloudFront receives AuthorizationHeaderMalformed: signed for ap-southeast-2, expected ap-southeast-1. What should be corrected first?

1. Refresh/update the origin’s current bucket information, deploy and verify the signing scope
2. Assign a home Region to the access key
3. Move the global CloudFront distribution to Singapore
4. Only open a VPC SG because every authorisation error is a timeout

Answer & deciding boundary

Correct: Refresh/update the origin’s current bucket information, deploy and verify the signing scope

Clue. Resource location and signature scope must agree; neither is a JSON-body routing field.

• Refresh/update the origin’s current bucket information, deploy and verify the signing scope: The explicit response identifies stale origin/signing Region information.
• Assign a home Region to the access key: Access keys do not carry that Regional ownership property.
• Move the global CloudFront distribution to Singapore: A distribution is not a Regional resource to move.
• Only open a VPC SG because every authorisation error is a timeout: S3 returned an explicit HTTP error; that is not evidence of a failed network connection.

Change the requirement. A timeout without an S3 response would require a different connectivity investigation.

Analogy. The parcel arrived, but the signed identity scope named the wrong regional authority.

CloudFront & Global Accelerator · S3 operations & protection

5.1 · Public destination does not select peering

Two EC2 workloads in ordinary AWS Regions use public IP addresses. A peering connection is then created, but requests still target those public IPs. Which statement is accurate?

1. AWS documents AWS-to-AWS public-IP traffic staying on its network, and peering needs private destinations/routes
2. Public addressing always proves external-internet transit
3. Peering automatically redirects every public-IP call
4. Direct Connect is automatically inserted

Answer & deciding boundary

Correct: AWS documents AWS-to-AWS public-IP traffic staying on its network, and peering needs private destinations/routes

Clue. Address selection and connectivity configuration have not changed.

• AWS documents AWS-to-AWS public-IP traffic staying on its network, and peering needs private destinations/routes: Public addressing is separate from the physical AWS network path; peering does not rewrite those requests.
• Public addressing always proves external-internet transit: Current AWS guidance contradicts that blanket statement; China/Sovereign Cloud exceptions are separately documented.
• Peering automatically redirects every public-IP call: Peering routes private connectivity; merely creating it does not change public-IP destinations.
• Direct Connect is automatically inserted: Direct Connect is a separately provisioned network connection, not an automatic EC2 communication hop.

Change the requirement. A private-address requirement needs suitable private routes/connectivity and permitted traffic.

Analogy. A public street address does not identify which owned road carried the delivery.

VPC routes, subnets & filters

Original practice material, not AWS exam questions. Single-answer and multiple-answer items are labelled. Progress stays in this browser when local storage is available.

5. Exam scope and next topics

SOA-C03 tests operating, configuring, investigating and recovering existing workloads. The five domain weights appear above. Official scope checked 9 November 2026; follow-up notes checked 10 November 2026.

Task-by-task coverage & next exercises · 13 official tasks

The June 2026 revisions include AI workload monitoring, Kiro, DevOps Agent, S3 Files, conformance packs and Security Agent (now documented under AWS Continuum). These receive introductory coverage; the table identifies deeper practice.

Official task	Lesson / references	Practice depth	Next hands-on step
1.1 · Implement metrics, alarms, and filters by using AWS monitoring and logging services.	Domain lesson CloudWatch metrics & alarms · Logs, queries & traces	Lesson + decision practice alarm lab · m1 · m2 · cp-canary	Configure agent + cross-account links; test alarm notifications with safe values.
1.2 · Identify and remediate issues by using monitoring and availability metrics.	Domain lesson CloudTrail & change evidence · EventBridge, SNS & remediation · Systems Manager operations · Health & assisted investigation	Lesson + decision practice alarm lab · m3 · m4 · cp-launch-notification	Run an approved Automation with an approval step; test EventBridge delivery failure and DLQ.
1.3 · Implement performance optimization strategies for compute, storage, and database resources.	Domain lesson EC2 performance & capacity · EBS performance & snapshots · S3 operations & protection · EFS, FSx & S3 Files · RDS, Aurora & database recovery	Lesson + guided investigation m5 · m6 · m7 · cp-replica-write · cp-packet · cp-attachment · cp-resize · cp-ena	Benchmark instance/volume bottlenecks; compare EFS/FSx/S3 Files and profile DB waits on a test workload.
2.1 · Implement scalability and elasticity.	Domain lesson Auto Scaling & elasticity · ElastiCache & cache operations · DynamoDB scaling & recovery · RDS, Aurora & database recovery	Lesson + decision practice capacity lab · r1 · r2 · cp-origin-shield	Exercise target tracking and warm-up; observe database/index throttling and cold-cache load.
2.2 · Implement highly available and resilient environments.	Domain lesson Load balancing & target health · RDS, Aurora & database recovery · Route 53 & DNS operations	Lesson + decision practice capacity lab · r3 · r4 · cp-alb-all-unhealthy	Perform a controlled instance/AZ and database failover; measure reconnect behaviour.
2.3 · Implement backup and restore strategies.	Domain lesson AWS Backup & disaster recovery · S3 operations & protection · RDS, Aurora & database recovery · DynamoDB scaling & recovery	Lesson + decision practice recovery lab · r5 · r6 · r7 · cp-recycle-bin · cp-consistency · cp-fsr · cp-retention	Restore real test data, validate content and time dependency recovery/cutover; exercise retention and version recovery.
3.1 · Provision and maintain cloud resources.	Domain lesson CloudFormation & CDK lifecycle · Images & deployment operations · Multi-account operations	Lesson + decision practice stack lab · d1 · d2 · d3 · d4 · d7 · cp-fresh-volume · cp-ami-share	Build/copy an image; operate an existing ECS/EKS rollout; test StackSets/RAM and a Terraform plan/state workflow.
3.2 · Automate the management of existing resources.	Domain lesson Systems Manager operations · EventBridge, SNS & remediation · Health & assisted investigation	Lesson + decision practice stack lab · d5 · d6 · cp-rescue	Patch a test node, use State Manager and scheduled/event-driven operations with least-privilege roles.
4.1 · Implement and manage security and compliance tools and policies.	Domain lesson IAM access investigation · Multi-account operations · Config & continuous compliance	Lesson + decision practice access lab · s1 · s2 · cp-s3-logs	Test federation/MFA, OU controls and cross-account access; configure recorder, conformance pack and safe remediation.
4.2 · Implement strategies to protect data and infrastructure.	Domain lesson KMS, encryption & secrets · ACM & encrypted connections · Security findings & classification	Lesson + decision practice access lab · s3 · s4 · s5 · cp-kms-same · cp-kms-cross	Test encrypted restore and secret rotation; resolve a certificate error; triage and verify security findings.
5.1 · Implement and optimize networking features and connectivity.	Domain lesson VPC routes, subnets & filters · Endpoints & private connectivity	Lesson + decision practice network lab · n1 · n2 · cp-default-filters · cp-ipv4 · cp-ipv6	Configure/test endpoint, IPv6 egress and existing peering/VPN routes; compare NAT/endpoint/AZ transfer costs.
5.2 · Configure domains, DNS services, and content delivery.	Domain lesson Route 53 & DNS operations · CloudFront & Global Accelerator	Lesson + guided investigation n3 · n4 · cp-oac	Test Resolver forwarding and routing policies; inspect CloudFront cache keys and Global Accelerator endpoint health.
5.3 · Troubleshoot network connectivity issues.	Domain lesson Network evidence & protection · VPC routes, subnets & filters · CloudFront & Global Accelerator	Lesson + decision practice network lab · n5 · n6 · cp-routing · cp-signing-region	Correlate Flow Logs, access/WAF/container logs and network monitors; investigate a hybrid return-path failure.

Scope boundary. Operate supplied designs and controls. Designing new distributed/hybrid architectures or CI/CD platforms, software development, governance definition and billing administration are outside the stated role. Operating scaling and optimising existing workloads remain in scope.

Next practice. EKS, Terraform, FSx variants, hybrid connectivity, AI tooling and specialised network protection need hands-on follow-up. Use the in-scope services with task skills and out-of-scope guidance.

Explore the architecture

35 flows · six comparisons. Search a service or feature to narrow the scenarios. Select a flow, then run or inspect its steps. Icons open the same service references.

EXAM SCOPE · ARCHITECTURE EXPLORERFind the failed boundary.

Moving labels show named operations; badges show resource state. Policy checks pulse without packets. Boundaries show placement, not extra hops.

AWS references: SOA-C03 guide · ASG health signals · Replacement order / maintenance policy · AMI launch semantics · S3 signing-Region errors · Synthetic testing · CloudFront Origin Shield · Stack update policies · StackSets · Scale-in protection · EC2 termination protection · Trusted Advisor events · AWS public-IP network paths · Destination-AZ FSR · Scheduler API targets · Capacity assurance · Snowball availability. Service panels also link to their specific documentation. These scenarios explain mechanisms; the exam guide defines scope.

Service reference library

All 29 service references · static reading

CloudWatch metrics & alarms

Measure workload behaviour; alarm on a defined statistic, dimension and time window.

Flow. Resource / agent → metric → alarm evaluation → configured action → verified outcome.

• EC2 basic monitoring usually publishes at five-minute intervals; detailed monitoring usually changes this to one minute. Memory and filesystem utilisation need an agent or custom publisher.
• Standard-resolution custom metrics use one-minute resolution; high-resolution metrics can publish at one second. Pick a supported alarm period and statistic; percentile latency and average latency answer different questions. Select the metric’s storage resolution when publishing with PutMetricData.
• M out of N means at least M breaching datapoints among N evaluated periods. Missing, breaching, notBreaching and ignore have different outcomes. Composite alarms combine alarm states; they do not support Auto Scaling actions directly.
• Use metric math for an error rate; publish both failed and total requests. Dashboards visualise data, alarms evaluate it. Cross-account observability links source accounts to a monitoring account within a Region; cross-Region dashboards are a separate capability.

Choose / compare. Choose an alarm for a recurring condition; use Logs Insights to investigate individual events. Neither creates a missing memory metric.

Try the related local exercise: alarm

Exam clue. Need an automatic response to sustained metric behaviour → alarm, then an appropriate action.

Trap. Detailed monitoring changes frequency, not the list of guest OS metrics. Composite alarms can notify or trigger supported operations; use underlying metric alarms for scaling.

Example

aws cloudwatch put-metric-alarm --alarm-name high-cpu \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --statistic Average --period 60 --evaluation-periods 3 \
  --datapoints-to-alarm 2 --threshold 80 \
  --comparison-operator GreaterThanThreshold --treat-missing-data missing

Investigate, remediate & verify

Evidence. Check namespace, dimensions, statistic, units, period, timestamps, ingestion delay and TreatMissingData before changing the threshold. Confirm the SNS subscription and alarm actions are enabled.

Action → verification. Correct the metric or action configuration; publish a controlled test value and verify state history plus delivery. Avoid testing destructive actions against production.

Analogy. The dashboard is the instrument panel; the alarm is the rule that decides when to ring.

Canary test, custom schedule, or trace correlation?

Scheduled canary → managed Lambda-based test → endpoint → metrics + artifacts → alarm
Existing request telemetry → correlated trace/map → investigation

CloudWatch Synthetics canaries run scheduled endpoint/browser scripts. Lambda functions perform the work underneath; Synthetics supplies monitoring integrations, metrics and test artifacts.

Scheduled Lambda can implement a custom check, but you assemble its schedule, measurements, reporting, artifact retention and alarms. Prefer the purpose-built monitor when those managed capabilities are the deciding requirement.

ServiceLens is older exam terminology for correlating metrics, logs and traces; it does not execute browser tests. Current docs combine ServiceLens/service maps into the X-Ray trace map and describe Application Signals for application observability.

Capability	Executes endpoint tests?	What it owns
Synthetics	Yes, configured canary	Scheduled test + monitoring/artifacts
Scheduled Lambda	Yes, custom code	Custom execution; you assemble monitoring
Trace map / older ServiceLens	No	Correlates observed request telemetry
Dashboard / alarm	No	Display / evaluate existing signals

Exam trigger. Scheduled customer-journey validation, even with no real traffic → Synthetics; investigate an existing slow request → traces/logs/correlation.

Common trap. Dashboards display evidence; metric alarms evaluate metrics; composite alarms combine alarm states. None is the endpoint test executor.

Official references: Canaries · Trace map / ServiceLens terminology

AWS references: Alarm evaluation · Missing data · Cross-account observability

Logs, queries & traces

Find the event or downstream operation behind an aggregate symptom.

Flow. Application / guest → configured collector → logs / traces → correlated query → hypothesis.

• CloudWatch Agent collects guest logs and metrics; its IAM role, configuration, network access and log retention must be managed. Container Insights supports ECS/EKS operational telemetry.
• A metric filter turns matching incoming log events into metric values for future alarms. Logs Insights queries retained log data; it does not retroactively populate a metric filter.
• X-Ray/OpenTelemetry traces correlate request segments and downstream subsegments. Sampling limits volume; an absent trace is not proof that no request occurred.
• Amazon Managed Service for Prometheus stores and queries Prometheus metrics; Amazon Managed Grafana presents dashboards. Monitor Lambda errors, duration, throttles and concurrency, plus Bedrock latency, invocation errors and quotas for AI workloads.

Choose / compare. Use logs for event detail, traces for where one request spent time and metrics for trends. Set retention and query windows to control cost.

Exam clue. Alarm says latency rose; need the slow dependency → correlated trace and application logs.

Trap. A trace is not an API audit log. Detailed EC2 monitoring does not install a log collector.

Example

# CloudWatch Logs Insights query (query editor)
fields @timestamp, @message, requestId
| filter @message like /ERROR/
| stats count(*) as errors by bin(5m)

Investigate, remediate & verify

Evidence. Correlate timestamps, request IDs, deployment version and trace ID. Confirm agent status, log stream timestamps, IAM permissions and ingestion before interpreting an empty query.

Action → verification. Repair collection or instrumentation; reproduce one known request and confirm its log and downstream trace. Redact secrets and personal data at source.

Analogy. Metrics count late deliveries; logs record each delivery; a trace follows one parcel through the depots.

AWS references: Logs Insights · Agent · Managed Prometheus

CloudTrail & change evidence

Record supported AWS API activity: who acted, what changed and from where.

Flow. Supported AWS API activity → event record → identity/change investigation.

• Event history provides recent management events in each Region. Trails deliver ongoing events; configure multi-Region and organisation coverage deliberately.
• Data events, such as supported S3 object operations, require appropriate event selectors and have separate cost. A management trail is not automatically an object access log.
• Log file validation supports integrity checking. Protect log buckets with least privilege, encryption, retention and deletion controls. Query long-term logs with Athena or supported CloudTrail analysis tools.

Choose / compare. Choose CloudTrail for API identity and change time; Config explains resource configuration history; ALB logs explain HTTP requests.

Exam clue. Who removed the ingress rule? → CloudTrail management event.

Trap. CloudTrail does not replace application logs, packet capture or a Config compliance rule.

Example

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AuthorizeSecurityGroupIngress \
  --max-results 10

Investigate, remediate & verify

Evidence. Search around the incident for eventName, userIdentity, errorCode, requestParameters and sourceIPAddress in the correct account/Region.

Action → verification. Correct the unauthorised or accidental change through controlled tooling; verify the resource state and a new successful operation, then prevent recurrence with policy or automation.

Analogy. A signed change register, rather than a live health monitor.

AWS references: Event history · Data events

EventBridge, SNS & remediation

Turn a matching operational event into a notification or a controlled recovery action.

Flow. Operational event → matching rule → authorised target → bounded procedure → result.

• EventBridge rules match event patterns on a bus; Scheduler handles time-based invocations. Input transformers change target input, not the source resource.
• SNS fans notifications to subscribed endpoints; confirm subscriptions and delivery permissions. SQS buffers work with visibility timeouts, retries and dead-letter queues.
• Use Lambda for bounded custom logic, Systems Manager Automation for a runbook and Step Functions for state, waits, retries and approvals. Standard and Express workflow semantics differ.
• Check EventBridge target retry policy and DLQ. A DLQ is an investigation queue, not automatic successful recovery. Make actions idempotent and constrain their role.

Choose / compare. An event routes work; a runbook owns the operational procedure. Use a schedule when the requirement is a recurring time, not a resource-state transition.

Exam clue. React to a resource event → EventBridge; notify people → SNS; execute a repeatable multi-step repair → Automation.

Trap. A matched rule does not prove the target ran or that the repair worked. Avoid recursive remediation loops.

Example

# EventBridge event-pattern excerpt
{"source":["aws.ec2"],"detail-type":["EC2 Instance State-change Notification"],
 "detail":{"state":["stopped"]}}

Investigate, remediate & verify

Evidence. Check the event bus, exact JSON pattern, MatchedEvents/FailedInvocations, target role or resource policy, DLQ and downstream execution history.

Action → verification. Test the pattern, fix target access and safely replay/reprocess eligible failures; verify the resource outcome as well as target invocation.

Analogy. The switchboard dispatches a ticket; the runbook is the repair procedure.

Notify on creation, not every transition or datapoint

EC2 RunInstances → CloudTrail API event → EventBridge rule → SNS
Direct EC2 state event → EventBridge is a separate event path

To distinguish new launches from restarting existing instances, match the RunInstances API event in the appropriate CloudTrail/EventBridge setup. EC2 pending/running events also occur on starts of existing instances.

EventBridge also receives direct service events without CloudTrail. Choose the event that identifies the required operation rather than adding an audit dependency to every event flow.

Logs → metric filter → alarm can be appropriate for aggregated conditions, but is a more complex route for individual event notifications. Alarm notifications normally follow state transitions; repeated matching events while already ALARM are not one notification each.

# EventBridge event-pattern excerpt
{"source":["aws.ec2"],"detail-type":["AWS API Call via CloudTrail"],
 "detail":{"eventSource":["ec2.amazonaws.com"],"eventName":["RunInstances"]}}

Exam trigger. Notify about each matching new launch API operation → event pattern and target, not a metric alarm that stays ALARM.

Common trap. One RunInstances call can launch multiple instances; one matching API event is not necessarily one notification per created instance. Transform/process IDs if the requirement is per instance.

Official references: EC2 API audit · CloudTrail events in EventBridge · Alarms

AWS references: Rules · Target retries · SNS

EC2 performance & capacity

Operate instances with sufficient CPU, memory, storage and network capacity.

Flow. Healthy launch configuration → instance → workload → resource measurements → controlled replacement/tuning.

• Distinguish instance status checks from system status checks; inspect OS logs and CloudWatch Agent metrics for guest failures.
• T-family CPU credits can constrain sustained burst workloads. Network and EBS limits belong to the instance as well as the volume; changing only one can leave the bottleneck.
• Use Compute Optimizer recommendations with representative workload metrics, tags and cost data. On-Demand, Spot and commitment discounts have different interruption and flexibility trade-offs.
• Placement groups address specific latency, partition or failure-isolation needs. Capacity Reservations reserve capacity; a Savings Plan discounts eligible usage without reserving capacity.

Choose / compare. Scale horizontally when the application supports more workers; resize when a single process needs more memory/CPU. Verify licensing, restart and architecture constraints.

Exam clue. Sustained CPU plus falling credit balance on burstable instances → investigate credits and instance family.

Trap. Minimum ASG capacity is not a capacity reservation. A lower hourly price can cost more if it cannot meet the workload.

Example

aws ec2 describe-instance-status --include-all-instances \
  --instance-ids i-0123456789abcdef0

Investigate, remediate & verify

Evidence. Compare CPU, credit balance, memory, swap, NetworkIn/Out, EBS queue/latency and service latency over the same interval. A busy CPU is a signal, not a root cause.

Action → verification. Right-size, tune or replace through the launch template and instance refresh; measure throughput and latency after warm-up and maintain a rollback version.

Analogy. Check whether the machine is short of engine power, working space or road capacity before buying a larger engine.

Resize: stop → change → start

Compatible EBS-backed instance → stop → change instance type → start → verify

In-place resizing requires compatibility and downtime. Stopping an ASG member can cause replacement unless maintenance is coordinated with ASG behaviour.

Instance ID, private IPv4, EIP and assigned IPv6 persist across ordinary stop/start; an auto-assigned public IPv4 normally changes. Instance-store contents are lost. EBS data persists according to its lifecycle.

Resizing changes the compatible EBS-root instance’s CPU/RAM configuration, not its AMI metadata or disk size. No manual root-volume move is required. An instance-store-root workload needs migration instead of this in-place path.

An EBS-root instance can also have instance-store disks. Their data survives a normal reboot, but is lost on stop/start, termination or underlying disk failure. Copy required data to persistent storage before maintenance.

Exam trigger. Need a larger compatible instance → account for stop/start downtime and the address clients use.

Common trap. An Elastic IP and an auto-assigned public IPv4 do not have the same stop/start behaviour.

Official references: Change instance type · Stop/start effects · Instance-store lifetime

Enhanced networking: capability versus implementation

Measure PPS / bandwidth / allowance counters → inspect instance + driver → select compatible networking

Enhanced networking uses SR-IOV; ENA is the modern implementation for Nitro-based instances. Some older families use Intel 82599 VF. Actual bandwidth/PPS constraints depend on instance type, size and traffic pattern.

An older practice explanation’s roughly 20K-PPS legacy-VIF clue is not a universal modern EC2 ceiling. Do not memorise old 10/25-Gbps figures as the limit of every current instance.

EFA targets tightly coupled HPC/AI communication. Direct Connect connects an on-premises network to AWS; neither is the general remedy for a legacy application instance’s network interface bottleneck.

Exam trigger. Legacy interface bottleneck on a compatible workload → examine enhanced networking/ENA and the exact instance limits.

Common trap. Buying bandwidth does not necessarily fix a packet-rate or single-flow limit.

Official references: Enhanced networking · Actual instance bandwidth

API termination, OS shutdown and ASG are separate

Direct TerminateInstances → DisableApiTermination check
OS shutdown → stop OR terminate setting
ASG scale-in / unhealthy replacement → separate ASG controls

DisableApiTermination=true blocks direct EC2 console/CLI/API termination. It does not block OS-initiated termination when InstanceInitiatedShutdownBehavior=terminate, or ASG scale-in/unhealthy replacement.

With shutdown behaviour stop, OS shutdown stops the EBS-root instance; a normally operating ASG may later replace that unhealthy member. Scale-in protection is another setting and does not block unhealthy replacement.

Control	Blocks	Does not guarantee
EC2 termination protection	Direct EC2 termination	No OS/ASG termination
Shutdown behaviour: stop	Selects OS-shutdown outcome	ASG keeps a stopped member
ASG scale-in protection	Selected scale-in termination	No unhealthy replacement

Exam trigger. First identify the actor and action: direct terminate, OS shutdown, scale-in or health replacement.

Common trap. A question claiming immediate termination after shutdown assumes the terminate setting. Do not infer it from API termination protection alone.

Official references: EC2 termination protection · ASG protection

Capacity assurance versus commitment discounts

Need launch capacity in AZ A → matching reservation
Need lower eligible usage price → RI / Savings Plan
Both requirements → compatible capacity and discount controls

A Capacity Reservation reserves matching AZ capacity, not a discount by itself. Immediate-start reservations have no fixed term; future-dated variants have commitment/cancellation conditions. Unused reserved capacity costs money; occupied capacity is not charged twice.

Eligible Regional RI/Savings Plan discounts can apply to matching Capacity Reservations. Sharing a reservation does not transfer ownership. Cluster placement groups are supported; older “no placement groups” explanations are outdated.

Savings Plans are spending commitments, not budget caps: unused commitment remains payable, while uncovered excess usage is On-Demand. Eligible Regional RIs offer size flexibility under documented platform/tenancy conditions.

Option	Discount?	Reserves capacity?	Commitment / flexibility
On-Demand Capacity Reservation	Not alone	Specific AZ	Immediate-start: no fixed term; future-dated variants differ
Regional RI	Yes	No	1/3 years; matching Region/configuration, eligible size flexibility
Zonal RI	Yes	Specific AZ	1/3 years; matching AZ/configuration
EC2 Instance Savings Plan	Yes	No	$/hour, 1/3 years; family + Region, size/OS/tenancy flexibility
Compute Savings Plan	Yes	No	$/hour, 1/3 years; eligible EC2/Lambda/Fargate, broader family/Region flexibility

Exam trigger. Guaranteed matching AZ capacity → capacity reservation / Zonal RI; cost-only commitment → discount mechanism.

Common trap. ASG desired capacity, a Regional RI and a Savings Plan do not independently reserve AZ capacity.

Official references: Capacity Reservations · RI scope · Savings Plan flexibility · Placement groups

AWS references: Status checks · Compute Optimizer

EBS performance & snapshots

Provide persistent block storage within an Availability Zone; tune IOPS and throughput to the workload.

Flow. EC2 block I/O ↔ same-AZ volume; snapshot → separately restored volume.

• gp2 performance is tied to size and credits; gp3 separates provisioned performance from capacity. io2 is for demanding I/O requirements. HDD types suit supported sequential workloads, not boot volumes.
• An EBS volume attaches to compatible instances in its own AZ. Multi-Attach is a specialised supported io1/io2 option, not a general cross-AZ shared filesystem.
• Snapshots are incremental backups managed regionally and can create volumes in another AZ. Copy snapshots to another Region when recovery requires it; check KMS access.
• New volumes restored from snapshots may need initialisation; Fast Snapshot Restore or supported provisioned volume initialisation options change readiness/cost.

Choose / compare. Block disk → EBS. Shared files → EFS/FSx. Objects → S3. Check instance bandwidth before buying more volume IOPS.

Choice	Performance mechanism	Operational boundary
gp2	IOPS tied to size; eligible burst credits	Watch credits and actual queue/latency.
gp3	Provision IOPS/throughput separately from capacity	Instance EBS limits still apply.
io2	Provisioned IOPS for demanding workloads	Check supported instance/volume capabilities and cost.

Exam clue. gp2 credits exhausted but disk size is already sufficient → consider gp3 performance settings.

Trap. Increasing a volume size does not automatically expand every filesystem. A completed snapshot is not a tested application restore.

Example

# Example only: check instance/volume requirements before applying
aws ec2 modify-volume --volume-id vol-0123456789abcdef0 \
  --volume-type gp3 --iops 6000 --throughput 250

Investigate, remediate & verify

Evidence. Correlate VolumeQueueLength, read/write latency, throughput, IOPS, BurstBalance where applicable, free space and the instance EBS limits.

Action → verification. Modify the supported volume type/performance, extend the partition/filesystem separately when growing size, then validate latency and restore a sample snapshot.

Analogy. A disk has separate capacity, operations-per-second and delivery-bandwidth limits.

Fast Snapshot Restore versus provisioned IOPS

Snapshot (Regional) → enable FSR for destination AZ → wait Ready + credits
→ create new volume in that AZ → initialized blocks at creation

A snapshot is Regional; a working volume is AZ-specific. FSR is enabled per snapshot/AZ pair before creation and needs a ready state plus sufficient volume-creation credits. A copied or later snapshot does not automatically inherit FSR.

Within supported FSR performance capabilities, the new volume is fully initialised at creation, removing first-read lazy-loading latency. Higher provisioned IOPS does not by itself load snapshot blocks.

Modern EBS also offers a provisioned volume-initialisation rate for supported restores. That controls initialisation speed; it is not a promise that the new volume is fully ready instantly. Check current support, quotas and cost.

Enable FSR for the destination AZ, regardless of the original volume’s AZ. Charges run per snapshot per enabled AZ, per minute with a one-hour minimum, even without a restore; normal snapshot/volume charges remain separate. It improves first-I/O readiness, not simply API creation speed.

Exam trigger. First-read restore latency with immediate full initialisation required → prepare suitable FSR before volume creation.

Common trap. “Preload in the AZ” is a mental model, not AWS’s documented internal storage implementation. Enabling FSR after creating the affected volume does not retroactively initialise it.

Official references: FSR · Volume initialisation

Available volume, but attachment is stuck

Volume ID → AttachVolume device mapping → driver / OS device → mount

The volume ID, requested attachment name and guest-visible device name are different identifiers. Drivers, especially NVMe enumeration, can remap names; use volume IDs/stable filesystem identifiers to identify the intended disk.

If evidence points to a retained/busy device name after a detach, verify the guest’s devices and retry with an unused supported name. Also check same-AZ placement, attachment limits and actual attachment state before choosing a remedy.

# Guest diagnostic example, Linux
lsblk -o NAME,SERIAL,SIZE,MOUNTPOINTS
# Compare with AWS volume ID/attachment mapping; do not format an unknown disk.

Exam trigger. Driver/device-name collision → unused supported mapping, not more disk performance credits.

Common trap. IOPS credits affect I/O performance, not whether the control plane can attach a disk. A stuck attachment alone does not prove which cause applies.

Official references: Attach volumes · Device naming · NVMe identifiers

Snapshot automation: lifecycle, central backup or five-minute API calls?

rate(5 minutes) → EventBridge Scheduler execution role → EC2 CreateSnapshot
→ asynchronous snapshot completion → separate retention / deletion controls

DLM manages EBS snapshot creation/retention/deletion through the EC2 console or APIs. DLM custom schedules and AWS Backup scheduled snapshot rules have a one-hour minimum; supported continuous backup is a separate mechanism.

For every few minutes, use EventBridge Scheduler with a supported EC2 universal API target and execution role. Lambda is optional custom logic, not a mandatory hop or the schedule itself.

“CloudWatch Events” is historical terminology. Modern flexible schedules use EventBridge Scheduler. Scheduling creates recovery points but does not by itself implement retention, exact completion times or application-consistent capture. DLM cannot automatically adopt snapshots created by unrelated mechanisms.

Requirement	Best fit
EBS snapshot creation, retention, deletion; hourly or less frequent	Data Lifecycle Manager
Central backup management across services/accounts/Regions	AWS Backup
Snapshot creation every few minutes / flexible API scheduling	EventBridge Scheduler

# Scheduler target excerpt (JSON), not a complete deployment
{"Arn":"arn:aws:scheduler:::aws-sdk:ec2:createSnapshot",
 "RoleArn":"arn:aws:iam::111122223333:role/snapshot-scheduler",
 "Input":"{\"VolumeId\":\"vol-0123456789abcdef0\"}"}
# ScheduleExpression: rate(5 minutes); FlexibleTimeWindow: {"Mode":"OFF"}

Exam trigger. Explicit every-five-minutes snapshot API requirement → Scheduler; built-in hourly lifecycle → DLM.

Common trap. Do not claim the EC2 console lacks automated snapshots, or that Lambda alone supplies recurrence.

Official references: DLM frequency · DLM ownership · AWS Backup frequency · Universal API targets · Legacy terminology

AWS references: Volume types · Snapshots

S3 operations & protection

Operate object storage with appropriate access, lifecycle, transfer and recovery controls.

Flow. Authorised object request → bucket/object version → response; lifecycle and recovery are separate operations.

• Use multipart upload for suitable large objects; abort incomplete uploads with lifecycle rules. Transfer Acceleration can help long-distance uploads; benchmark before enabling it. DataSync automates supported bulk transfers.
• Lifecycle transitions and expiration manage storage cost, subject to minimum durations, request/retrieval charges and retrieval latency. Versioning preserves older versions; a delete marker is not destruction of every version.
• SRR/CRR replicate eligible new objects after configuration; use Batch Replication for existing objects. Replication needs versioning, permissions and encryption configuration. Lifecycle actions are not simply copied to the destination.
• Keep access-log destination separate to avoid recursive logging. Block Public Access, bucket policies and Object Ownership govern access; an endpoint policy alone does not grant bucket access.

Choose / compare. Versioning recovers an overwritten object; replication maintains another copy; AWS Backup and Object Lock address different retention/recovery needs.

Exam clue. Recover overwritten data → version ID; copy existing objects under a replication policy → Batch Replication.

Trap. Replication can copy unwanted changes and is not an independent historical backup. Storage class changes can alter recovery time and cost.

Example

aws s3api list-object-versions --bucket example-orders --prefix invoices/
# Retrieve an explicitly selected version (replace placeholders)
aws s3api get-object --bucket example-orders --key invoices/42.pdf \
  --version-id VERSION_ID recovered.pdf

Investigate, remediate & verify

Evidence. For 403: inspect principal, bucket/access-point policy, explicit denies, KMS access and endpoint restrictions. For slow transfers: check request concurrency, object sizes and network path.

Action → verification. Restore the required version or correct access/transfer settings; verify checksum, version ID, encryption and an application read. Test recovery from accidental deletion.

Analogy. Version history is a filing cabinet; replication is a second cabinet that follows configured changes.

Retain until is not delete at

Versioning + Object Lock → retain protected version → retention expires
→ version becomes eligible → configured Lifecycle action eventually deletes eligible data

Object Lock protects object versions. Retain Until Date ending makes a version deletable under the applicable policies; it does not itself schedule deletion. Legal holds and remaining controls can still block it.

Use versioning and an appropriate retention mode for the stated requirement, then Lifecycle for eligible expiration/cleanup. Include noncurrent versions and delete markers in the design. Governance bypass and compliance retention have different rules.

“Keep for five years” describes a requirement; it does not prove the existing bucket already has Object Lock configured.

Exam trigger. Cannot delete before retention + automatic cleanup afterwards → retention control plus suitable lifecycle/version rules.

Common trap. Lifecycle does not bypass an active lock, and a simple delete marker does not erase a retained version.

Official references: Object Lock · Lifecycle and Object Lock

API audit and server access logging are different evidence

Management API → CloudTrail management event
GetObject / PutObject → explicitly selected CloudTrail data events
Bucket access request → best-effort server access log delivery

S3 object-level CloudTrail data events must be explicitly configured and are charged separately; a management trail does not automatically include them.

For server access logging delivered directly to an S3 bucket there is no additional log-delivery charge; storage, access and analysis still cost money. Delivery is best effort and should not be treated as a complete immediate audit feed. Keep the source and log destination separate.

Current AWS documentation also offers CloudWatch Logs delivery with vended-log ingestion pricing. Do not generalise the S3 delivery pricing statement to every log destination.

Exam trigger. Need object API caller evidence → configure data-event coverage; compare the required completeness and costs.

Common trap. “No delivery fee” does not mean free storage or guaranteed complete real-time delivery.

Official references: CloudTrail data events · Server access logging

Physical import ends in S3, then Lifecycle

Ship device → copy on premises → return device → AWS imports to S3
→ configured Lifecycle transition → eligible S3 Glacier storage class

Snowball Edge import moves locally copied data back to AWS before the S3 import completes. A Lifecycle rule then controls eligible storage-class transitions; the device does not directly deliver objects into a Glacier-class archive.

Availability caveat: since 7 November 2025, Snowball Edge is available only to existing customers. Treat older exam scenarios accordingly; new customers should evaluate current online/physical-transfer alternatives.

Exam trigger. An eligible existing customer needs offline bulk import, then archive storage → device import to S3 plus Lifecycle.

Common trap. Shipping, import completion and a later storage-class transition are different stages.

Official references: Availability / import process

AWS references: Versioning · Lifecycle · Replication

EFS, FSx & S3 Files

Choose and operate shared storage by protocol, application semantics and recovery needs.

Flow. Application file call → configured mount/identity → shared filesystem → result.

• Regional EFS provides shared NFS access through mount targets in selected AZs; permit NFS and resolve the mount DNS name. EFS One Zone has a different resilience boundary.
• FSx offerings serve specific filesystem workloads, such as Windows SMB, Lustre, ONTAP and OpenZFS. Match protocol, deployment model, throughput and snapshots/backup support. For supported Windows workloads, file version recovery can involve configured shadow copies; distinguish file-level versions from whole-filesystem backups.
• S3 Files provides file access to S3 data through a managed filesystem; inspect its access, consistency and storage-class behaviour rather than treating an object bucket as an ordinary block disk.
• Use lifecycle and throughput settings deliberately. Storage Gateway supports hybrid access patterns; DataSync moves supported data, rather than replacing the live application filesystem.

Choose / compare. Shared Linux files across AZs → regional EFS; Windows-specific SMB/AD requirements → suitable FSx. Choose object APIs when file semantics are unnecessary.

Need	Candidate	Check before choosing
Shared Linux NFS	Regional EFS	Mount targets, NFS access, throughput and lifecycle.
Specific SMB / Lustre / ONTAP / OpenZFS semantics	Appropriate FSx offering	Protocol, identity, deployment/backup model.
File access over S3 data	S3 Files	Supported access/consistency and object storage-class behaviour.
Per-instance block disk	EBS	Same-AZ attachment; not general cross-AZ file sharing.

Exam clue. Multiple instances need the same persistent files across AZs → a regional shared filesystem.

Trap. EBS is not a general cross-AZ shared filesystem. An S3 Glacier object may require restoration before S3 Files can read it.

Example

# NFS example with amazon-efs-utils installed; mount target/network access required
sudo mount -t efs -o tls fs-0123456789abcdef0:/ /mnt/shared

Investigate, remediate & verify

Evidence. Check mount target placement, DNS, NFS/SMB security rules, client identity, throughput mode, storage latency and application access pattern.

Action → verification. Correct mounts/access or throughput, test concurrent access from both AZs and perform a supported backup/restore test.

Analogy. EBS is a machine’s disk; a shared filesystem is a network filing room; S3 is an object repository.

AWS references: EFS mounting · FSx · S3 Files

Auto Scaling & elasticity

Reconcile a group’s running capacity with desired capacity across configured AZs.

Flow. Metric / schedule → scaling policy → desired capacity → instance reconciliation → target health.

• Min/max constrain desired capacity. Scaling policies change desired capacity; the ASG launches or terminates instances to reconcile actual capacity. Launches still depend on subnet IPs, quotas and available capacity.
• Target tracking follows a proportional utilisation metric; step scaling uses alarm severity. Scheduled actions handle known times; predictive scaling uses supported forecast patterns.
• Enable ELB health checks when the group must replace application-unhealthy targets. Use health-check grace periods and instance warm-up appropriately; they solve different timing problems.
• Lifecycle hooks allow controlled launch/termination work. Instance refresh rolls out launch-template changes; configure healthy percentages, checkpoints and rollback.

Choose / compare. ASG manages instance count/health replacement; ALB distributes requests. A single ASG is regional and can span AZs, not Regions.

Try the related local exercise: capacity

Exam clue. Predictable morning surge → scheduled scaling; changing utilisation → target tracking with a suitable metric.

Trap. Min=1 permits a single instance and does not ensure AZ redundancy. Low average CPU can hide a hot instance or a downstream bottleneck.

Example

# Example: actual 3, desired 5; ChangeInCapacity +3 → desired 8 (if max permits)
aws autoscaling describe-scaling-activities --auto-scaling-group-name orders-asg

Investigate, remediate & verify

Evidence. Inspect scaling activities, suspended processes, desired versus InService capacity, launch-template version, subnet free IPs, health type and warm-up.

Action → verification. Repair the failing launch/health dependency, then verify capacity reaches desired and the new targets pass application checks under load.

Analogy. The ASG is the staffing manager; the load balancer allocates incoming work.

Scale-in protection: target count can differ from actual

Policy lowers desired 4 → 3 → every member protected → actual remains 4
Remove selected protection → ASG can converge to desired

Desired capacity is a target. Scale-in protection can prevent the selected termination without preventing the target from decreasing. Inspect Activity history and actual member states.

Scale-in protection does not prevent unhealthy replacement. Group metrics must be enabled to publish the group series; use instance metrics for the individual machine.

Metric	Meaning
GroupDesiredCapacity	Target capacity
GroupInServiceInstances	In-service count
GroupPendingInstances	Launching count
GroupTotalInstances	Total, including in-service, pending and terminating

aws autoscaling describe-scaling-activities --auto-scaling-group-name orders

Exam trigger. Desired fell but no instance was removed → inspect scale-in protection and scaling activity.

Common trap. An in-service count is not a guarantee that every application is healthy; health/replacement is a separate process.

Official references: Protection · Group metrics

AWS references: Scaling policies · Health checks

Load balancing & target health

Accept traffic on listeners and route it to registered targets using rules and health information.

Flow. Client → listener → matching rule → target group → selected target → response.

• ALB routes HTTP/HTTPS by host/path and other supported rules; NLB handles supported transport-layer requirements. Internet-facing frontends can reach private backend targets.
• ALB cross-zone is on at load-balancer level; target-group settings can disable it. With cross-zone and equivalent targets, 2 in AZ A plus 8 in B means roughly 10% per target, not 50% per AZ.
• Health checks use configured port, path, timeout, matcher and thresholds. A service can work directly yet fail its health check. If all targets are unhealthy, ALB can fail open.
• Deregistration delay drains connections. Sticky sessions, routing algorithm and differing response times can create unequal request counts.

Choose / compare. Need HTTP routing → ALB. Need instance replacement → ASG with the relevant health checks. Need cross-Region entry/failover → DNS or Global Accelerator as appropriate.

Try the related local exercise: capacity · network

Exam clue. Requests fail only through the load balancer → compare health configuration, target rules and frontend/backend security.

Trap. Cross-zone distributes eligible traffic, not guaranteed equal request counts. An ALB is regional; it does not span Regions.

Example

aws elbv2 describe-target-health --target-group-arn TARGET_GROUP_ARN
# Illustration: browser → HTTPS:443 listener → /orders rule → HTTP:8080 target

Investigate, remediate & verify

Evidence. Inspect target-health reason, ALB versus target 5xx, TargetResponseTime and access logs. Check listener rule, target port, SG references and health endpoint dependencies.

Action → verification. Correct the first failing boundary; verify repeated healthy checks, request success and latency. Do not make the health endpoint lie to hide a broken dependency.

Analogy. The receptionist routes visitors; the building manager replaces a broken office.

Health status is periodic; HTTP status is a request outcome

Periodic probes → target health → eligible routing
Separate request → selected target → HTTP result

ALB does not run a fresh health check before every request. It uses periodically evaluated target health. With healthy targets available it normally avoids unhealthy ones; all registered targets unhealthy can cause fail-open routing.

Unhealthy does not automatically mean HTTP 503. No registered targets/all targets unused can produce an ALB 503; a backend application can independently return its own 503. Read target-health reasons and ALB versus target status evidence.

ASG uses enabled ELB health checks to replace the failed instance; it does not simply restart that application. One failed AZ is not necessarily every target failing: inspect healthy targets, cross-zone settings and whether there is one load balancer or several.

Exam trigger. Separate health state, routing eligibility, actual request status and ASG replacement.

Common trap. A periodic health result can lag a new failure; all-unhealthy fail-open is not a guarantee of successful responses.

Official references: ALB health · ALB HTTP errors · ASG health

AWS references: Health checks · Cross-zone

RDS, Aurora & database recovery

Operate relational availability, read scaling, connections, performance and recovery.

Flow. Application → chosen writer/read endpoint → SQL result; replication and historical recovery are separate paths.

• A traditional Multi-AZ DB instance has a synchronous standby for failover, not read traffic. A Multi-AZ DB cluster has readable instances; Aurora has its own replicated storage and reader architecture.
• Read replicas generally replicate asynchronously; route reads to their endpoints and monitor lag. Aurora Serverless v2 adjusts supported database capacity within configured limits; it does not remove query tuning.
• Use CloudWatch Database Insights to analyse DB load, waits and SQL. Older study material calls out Performance Insights. RDS Proxy pools/manages connections; it does not repair inefficient SQL.
• Automated backups support PITR within configured retention, up to 35 days for supported RDS DB instances. Manual snapshots persist until deleted. Restore creates a new database resource; plan endpoint cutover and KMS access.

Choose / compare. Host/AZ failure → Multi-AZ; read pressure with lag tolerance → read replicas; accidental logical change → PITR/snapshot restore.

Capability	Primarily solves	Important limit
Traditional Multi-AZ instance	Host/AZ failover	One standby is not a reader.
Multi-AZ DB cluster / Aurora deployment	Availability with readable instances	Inspect the specified deployment/endpoint model.
Read replica	Read scaling	Asynchronous lag; application selects read endpoint.
PITR / snapshot restore	Historical recovery	New resource; validate and plan cutover.
RDS Proxy	Connection management	Does not fix inefficient SQL or transaction locks.

Try the related local exercise: recovery

Exam clue. Deleted valid rows but database remains healthy → PITR, not a standby that replicated the deletion.

Trap. Failover is not historical recovery. A successful restore API response does not mean the new endpoint is ready or validated.

Example

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier orders-db \
  --target-db-instance-identifier orders-recovered \
  --restore-time 2026-11-09T01:25:00Z

Investigate, remediate & verify

Evidence. Compare CPU, FreeableMemory, storage latency/free space, connections, replica lag and DB-load waits. Check events and pending modifications/maintenance windows.

Action → verification. Tune SQL/indexes or the limiting resource; test failover with reconnect logic. Restore to an isolated DB, validate records and redirect traffic only after checks.

Analogy. A standby replaces a failed shop; a backup recovers the ledger from before a bad entry.

MySQL replica: endpoint, writes & message limits

Application writes → source endpoint → asynchronous replication → replica
Reporting reads → replica’s own endpoint

Each RDS instance has its own endpoint. MySQL read replicas normally reject application writes with read_only enabled. Setting read_only=0 permits writes, but conflicting changes can stop replication; a replica is not a second independently writable primary.

A replica-specific index is a documented special case requiring read_only=0 while it is created. Do not generalise that exception into permission for arbitrary application writes.

max_allowed_packet bounds an individual logical MySQL message, such as a statement, row or replication event. It is neither database capacity nor total transaction/write volume. A large message can break replication when the replica’s configured value is lower; matching source/replica parameter values removes that mismatch.

# Read-only diagnostic SQL; connect to the intended instance endpoint
SHOW VARIABLES LIKE 'read_only';
SHOW VARIABLES LIKE 'max_allowed_packet';

Exam trigger. Replication stopped with a packet-size error → compare parameter groups and the failing logical message.

Common trap. A lower limit need not fail immediately: the problematic message must arrive. A MySQL logical message is not one Ethernet/TCP packet.

Official references: RDS replication troubleshooting · MySQL logical packets

AWS references: Multi-AZ · PITR · Database Insights · Backup retention

DynamoDB scaling & recovery

Operate a managed key-value database by access pattern, partition pressure and recovery policy.

Flow. Key-based request → table / index capacity → result; recovery creates a new table.

• On-demand manages request capacity; provisioned mode uses configured RCU/WCU with optional Auto Scaling. Auto Scaling reacts to usage and is not instantaneous.
• A hot partition key can throttle even when table totals appear low. Inspect throttling reason, key distribution and GSI capacity; a GSI with insufficient write capacity can back-pressure table writes.
• DAX accelerates supported eventually consistent reads with a compatible client; strong reads bypass its cache to DynamoDB. Global tables replicate across Regions; they do not provide historical undo.
• Enable PITR for supported continuous recovery and use on-demand/AWS Backup snapshots for retention requirements. Restore produces a new table; recheck dependent settings and application routing.

Choose / compare. Variable unpredictable traffic → consider on-demand; predictable demand → provisioned plus scaling. Correct hot keys before blindly increasing total capacity.

Exam clue. Throttles despite low aggregate utilisation → inspect partitions/indexes, not only table totals.

Trap. TTL deletion is asynchronous; it is not a precise scheduler. Replication does not preserve every previous valid value.

Example

aws dynamodb describe-continuous-backups --table-name Orders
aws dynamodb describe-table --table-name Orders

Investigate, remediate & verify

Evidence. Inspect consumed/provisioned capacity, throttles by table/index, latency, failed conditions and Contributor Insights hot-key evidence where enabled.

Action → verification. Adjust capacity or access pattern, verify per-key success and tail latency; test restore and switch the application to the validated new table.

Analogy. A warehouse can have free space overall while one busy loading bay is overloaded.

AWS references: Capacity · PITR

ElastiCache & cache operations

Reduce repeated database work while managing freshness, eviction and failure behaviour.

Flow. Read → cache hit, or miss → database → cache population; write/invalidation follows the selected strategy.

• Valkey/Redis OSS shards partition data; replicas copy their shard asynchronously and support reads/failover in suitable configurations. More replicas do not spread primary writes across shards.
• Node-based Memcached provides a simpler distributed cache without Redis OSS-style primary/replica failover. Serverless and node-based models differ in scaling, controls and pricing; inspect the chosen deployment model.
• Cache-aside populates on a miss; TTL expires entries without refreshing them. Write-through updates database/cache in a coordinated application workflow; invalidation removes the cached value after a database change.
• Track hit rate, evictions, memory, engine CPU, connections and replication lag. A cache outage can suddenly push the entire read load onto the database.

Choose / compare. HTTP objects at the edge → CloudFront; DynamoDB-compatible cache → DAX; custom sessions/computed values → ElastiCache.

Exam clue. Read-heavy repeated values with acceptable staleness → caching; write pressure → examine shards and workload, not just replicas.

Trap. TTL expiration does not refresh data, and database/cache writes are not automatically atomic.

Example

# Cache-aside pseudocode
value = cache.get("product:42")
if value is None:
    value = database.read(42)
    cache.set("product:42", value, ttl=60)

Investigate, remediate & verify

Evidence. Check whether misses, hot keys, memory pressure or a node failure preceded database load. Compare DB and cached values before assuming a stale response is a DB issue.

Action → verification. Tune TTL/invalidation, memory or shard capacity; test failover and cold-cache load. Use bounded retries and protect the source database.

Analogy. A desk copy saves trips to the archive, but someone must decide when that copy is too old.

AWS references: ElastiCache · Caching strategies · Engine comparison

AWS Backup & disaster recovery

Schedule protected recovery points, manage retention/copies and prove that recovery works.

Flow. Protected resource → recovery point → optional copy → restore → application/data validation.

• Backup plans select resources by explicit assignment or tags; check roles, supported resource settings and job outcomes. Copy to another account/Region when the recovery requirement calls for it.
• Vault Lock protects retention with governance/compliance semantics; compliance mode becomes immutable after its grace period. Choose deliberately before committing retention controls.
• Restore testing exercises supported restores and validation. An available recovery point says little about application readiness, permissions, dependencies or actual RTO.
• Backup/restore, pilot light, warm standby and active/active trade ongoing cost against recovery work. RTO is tolerable outage; RPO is tolerable lost time of data. Both require measurement.

Choose / compare. Choose the least costly tested procedure that meets both objectives; replication/failover handles availability but can replicate corruption.

Try the related local exercise: recovery

Exam clue. Keep recoverable history outside the workload account → controlled cross-account backup copies and tested access.

Trap. Replication is not a backup. No universal RTO belongs to a DR label; recovery time depends on the actual tested procedure.

Example

aws backup list-backup-jobs --by-state FAILED
aws backup list-recovery-points-by-backup-vault --backup-vault-name orders-vault

Investigate, remediate & verify

Evidence. Inspect backup/copy/restore job status, last recoverable timestamp, vault/account/Region, encryption grants, retention and application dependency order.

Action → verification. Restore into isolation, validate business records and integrations, time the full cutover and clean up test resources. Record the demonstrated RTO/RPO.

Analogy. A spare building is useful only if the recovery team has the keys and has practised opening it.

AWS references: Backup plans · Restore testing · Vault Lock · DR strategies

CloudFormation & CDK lifecycle

Maintain declared resources through reviewed stack changes and controlled failure recovery.

Flow. Template (optionally CDK synthesis) → reviewed stack operation → resource events → health verification.

• CDK synthesises templates and assets; CloudFormation provisions the stack. Change sets preview supported changes and replacements; they do not guarantee an update will succeed.
• Read stack events from the first relevant failure. UPDATE_ROLLBACK_FAILED requires repairing the rollback cause and continuing rollback. Skipping resources is a last resort and leaves reconciliation work.
• Drift detection compares supported resource properties to the template; it does not automatically repair drift or inspect every property. DeletionPolicy and UpdateReplacePolicy protect different deletion/replacement moments.
• StackSets distribute stacks across accounts/Regions with permissions, concurrency and failure-tolerance controls. Parameters are inputs; conditions choose resources/properties; DependsOn orders dependencies.

Choose / compare. Need repeatable infrastructure → a stack; preview a change → change set; distribute the template → StackSets; share an existing supported resource → RAM.

Try the related local exercise: stack

Exam clue. Stack stuck in UPDATE_ROLLBACK_FAILED → fix cause, then continue-update-rollback.

Trap. Deleting a failed production stack is not a routine recovery step. A change set is a preview, not an executed deployment.

Example

aws cloudformation describe-stack-events --stack-name orders
# After fixing the specific rollback cause:
aws cloudformation continue-update-rollback --stack-name orders

Investigate, remediate & verify

Evidence. Inspect resource status reason, service role, quotas, subnet IP capacity, name collisions, missing exports and replacement dependencies. Distinguish update failure from rollback failure.

Action → verification. Fix the prerequisite, continue rollback where appropriate, review the next change set and verify stack status plus application health. Reconcile any skipped resource before another update.

Analogy. The template is the agreed building plan; drift is a room changed outside that plan.

IAM, stack policy, termination protection or Retain?

Caller IAM → UpdateStack → separate stack-policy check → resource changes / failure

A stack policy is a separate JSON document attached to the stack. It restricts updates to existing logical resources even when IAM permits UpdateStack. Update:Modify, Update:Replace and Update:Delete describe update actions; Update:* covers all three.

A prohibited change fails the update; CloudFormation does not silently skip it and report success. An authorised operator can supply a temporary override for an intentional protected update. Other resources may already have changed before a later permission failure; rollback can fail or be disabled.

Requirement	Control
Restrict existing-resource updates	Stack policy
Block deletion of the entire stack	Stack termination protection
Keep a resource when deleting its stack	DeletionPolicy: Retain
Authorise/restrict direct AWS API actions	IAM policies

# Separate stack-policy excerpt, not template YAML
{"Statement":[{"Effect":"Allow","Action":"Update:*","Principal":"*","Resource":"*"},
 {"Effect":"Deny","Action":"Update:Replace","Principal":"*","Resource":"LogicalResourceId/Database"}]}

Exam trigger. Protect a database during stack updates → stack policy; first identify which operation must be blocked.

Common trap. A stack policy is neither an IAM permission grant nor protection against direct service API calls.

Official references: Stack policies

Regional stacks, account-wide names

Sydney stack creates a named IAM role → another Region tries the same name → conflict
Alternative: generate a unique name OR explicitly reference the one owned resource

IAM role/user names are account-wide, not shared across every AWS account. CloudFormation stacks are Regional: a second stack does not silently adopt an existing role with the same RoleName.

Omit optional physical names, or include Region/stack identifiers. Intentional sharing needs one owner and an ARN input/reference; importing a resource is a separate explicit workflow.

S3 buckets are Regional too, but traditional general-purpose bucket names share a namespace across accounts/Regions within a partition. Current S3 also supports optional account-Regional namespaces with a prescribed name suffix.

# Template excerpt for a NEW role, not a reference to an existing role
RoleName: !Sub "${AWS::StackName}-${AWS::Region}-app"
# For intentional reuse, take an ExistingRoleArn parameter instead.

Exam trigger. Same template fails only in the second Region with AlreadyExists → check account-wide physical names.

Common trap. Referencing an ARN does not create a second resource. A late create failure does not prove earlier resources were never created.

Official references: Named IAM roles · S3 namespaces

AWS references: Rollback recovery · Drift · StackSets

Images & deployment operations

Promote tested machine/container artifacts and update an existing deployment safely.

Flow. Build → test → registry / AMI distribution → controlled rollout → health gate.

• EC2 Image Builder automates build, test and distribution of AMIs/container images. An AMI is regional; copying encrypted images requires compatible KMS permissions.
• ECR stores images; ECS/EKS run containers. Check image URI/digest, pull permissions, platform architecture, registry connectivity, task/pod events, probes and resource limits.
• Use immutable digests for repeatable releases. Rolling changes existing capacity in batches; blue/green retains another environment during cutover. Account for database compatibility and rollback.
• Git records changes; Terraform plans/applies its managed resources with protected remote state and locking. Avoid two IaC tools independently owning the same resource.

Choose / compare. Image creation/distribution → Image Builder/ECR; workload rollout → the existing ASG/ECS/EKS/deployment service. Operate the chosen pipeline rather than redesigning one for this exam.

Exam clue. Same fault on every replacement instance → investigate the image/template/config, not repeated manual instance repair.

Trap. An uploaded image is not a running task. A mutable latest tag makes rollback provenance harder to prove.

Example

aws ecs describe-services --cluster orders --services orders-api
aws ecr describe-images --repository-name orders-api

Investigate, remediate & verify

Evidence. For failed deployment, start at events and the first unhealthy dependency: subnet IP exhaustion, image pull, permissions, startup command, health probe or application config.

Action → verification. Correct the dependency and redeploy a pinned artifact with a controlled rollout; verify new revision, healthy count, error rate and rollback readiness.

Analogy. The image is a sealed installation kit; deployment decides where and when that kit runs.

AMI ≠ working disk ≠ Launch Template

Working EBS → snapshot
AMI = boot metadata + snapshot references
Launch Template = AMI ID + instance/network/storage settings
Launch → fresh EBS volumes from snapshots → new instance

Boot metadata includes architecture, root-device mappings, virtualisation type and boot mode. An EBS-backed AMI refers to snapshots; it is not the live volume still attached to the source instance.

ASG launches normally create new root volumes from the image’s snapshots. Reattaching an existing data disk is a different explicit workflow. A replacement AMI can be created from a running/stopped instance or a suitable retained root snapshot with matching boot settings.

Exam trigger. Need repeatable replacement instances → usable image plus launch configuration, not a plan to move one root disk between every launch.

Common trap. A snapshot is disk data; it does not alone specify every boot setting or the desired EC2 instance type.

Official references: EBS-backed AMIs · Launch Templates

Image consistency and deregistration recovery

Coordinate application writes → flush/freeze or allow reboot → capture image → test boot AND data
Deregistered AMI → matching pre-existing Recycle Bin rule? → restore within retention

Durable captured blocks do not automatically prove application consistency. Allowing the image-creation reboot helps flush buffered state; transactional applications can need their own quiesce/backup coordination. “Disable No reboot” means allow reboot.

An accidentally deregistered eligible EBS-backed AMI can be recovered through Recycle Bin when a matching retention rule already applied and retention has not expired. Otherwise investigate retained snapshots or a surviving instance; reconstruct with correct boot settings.

Exam trigger. Before-image consistency requirements and recoverable historical artifacts change the recovery answer.

Common trap. “Deregistered means never recoverable” is outdated. A retention rule created after the deletion does not retroactively save an unretained image.

Official references: Image capture · Deregister / Recycle Bin

AZ, account and Region are separate sharing boundaries

Another AZ: same Regional AMI
Another account: AMI launch permission + eligible encryption access
Another Region: copy image, then share/use the destination copy

Sharing the AMI permits use of its backing snapshots for launching without separately sharing those snapshots. Copying a shared AMI can require additional read permissions for its backing storage.

Encrypted sharing needs a customer-managed KMS key with suitable cross-account permissions. An image encrypted under the default AWS-managed aws/ebs key cannot simply be shared cross-account. Copy/re-encrypt under an appropriate customer-managed key when required.

Another account and Region involves both sharing/access permissions and a destination-Region copy. Same-account cross-Region copying is not prohibited merely because the source used the AWS-managed aws/ebs key; use an appropriate destination-Region encryption key.

A KMS multi-Region key has distinct Regional primary/replica resources. Ordinary customer-managed keys are not global, and Region copying is a separate boundary from cross-account key sharing.

Exam trigger. Launching a shared image and copying it have different backing-snapshot permission requirements.

Common trap. Cross-account use does not imply cross-Region copying; name the changed boundary first.

Official references: Sharing images · Copying images · Cross-Region image copies

Baked agent: installed is not sending

AMI with agent/config → fresh instance → automatic startup + IAM + endpoints → telemetry

The image supplies the installed CloudWatch Agent and configuration to each launch. ASG does not independently install software merely because it launches the AMI.

Publishing still needs startup, a valid instance role, correct configuration/dimensions and endpoint access. Validate a new instance’s own log/metric stream, not only the old source instance’s telemetry.

# Linux diagnostic example
systemctl status amazon-cloudwatch-agent
# Check agent logs, instance-role permissions and HTTPS endpoint reachability.

Exam trigger. Agent baked into image but new instance has no guest metrics → check startup, permissions and connectivity.

Common trap. EC2 basic metrics can exist while memory/disk-space or application logs are missing.

Official references: CloudWatch Agent

AWS references: Image Builder · ECS troubleshooting · ECR

Systems Manager operations

Inventory, connect to, patch, configure and automate managed resources.

Flow. Authorised operator / event → runbook → scoped API or managed-node operation → recorded outcome.

• Managed nodes need an agent where applicable, instance/service permissions and network connectivity. Session Manager avoids opening inbound SSH/RDP; configure session logging and access explicitly.
• Run Command performs supported commands; Automation runbooks coordinate operational steps/API calls with optional approvals. State Manager maintains desired associations; Patch Manager handles patch baselines/operations.
• Maintenance Windows schedule controlled maintenance. Parameter Store holds configuration and SecureString values; Secrets Manager adds supported secret rotation workflows.
• Limit automation concurrency and error thresholds. Multi-account/Region execution needs trusted roles and target access; an automation service role is separate from a node’s role.

Choose / compare. One command on managed nodes → Run Command; a repair procedure with branching/approval → Automation; ongoing desired setup → State Manager.

Exam clue. Repeat a repair with approvals and auditability → Automation runbook.

Trap. The console showing a node does not prove it is currently online. A successful command exit code is not an application health test.

Example

aws ssm describe-instance-information
# Example runbook; review its steps and target before execution
aws ssm start-automation-execution --document-name AWS-RestartEC2Instance \
  --parameters InstanceId=i-0123456789abcdef0

Investigate, remediate & verify

Evidence. For an offline node, inspect agent service/version, instance role, DNS/proxy, time, and outbound HTTPS to required endpoints. No inbound SSH rule is required for Session Manager.

Action → verification. Restore management connectivity, target a safe tag group, dry-run/test where supported, then verify command/runbook output and actual service health.

Analogy. A managed workshop: access, tool inventory, maintenance schedule and repeatable repair instructions.

Agent management versus offline EC2Rescue

Online: agent + node IAM + outbound HTTPS → SSM
Offline rescue: Automation → temporary helper → detached root EBS → repair → reattach

Ordinary agent-based management requires a working agent, credentials/permissions and outbound endpoint connectivity. Automation is broader: its runbooks can call AWS APIs without executing inside the impaired OS.

AWSSupport-ExecuteEC2Rescue can orchestrate an offline workflow using temporary helper resources and the impaired instance’s root EBS volume. Review the runbook’s prerequisites, permissions, backup and stop/restart behaviour. This is not an agent command somehow running inside an unreachable OS.

Use repair when preserving/fixing this instance matters. An ASG generally replaces an unhealthy instance; guard against that replacement interfering with intentional repair or maintenance.

Exam trigger. Agent unreachable and root-volume repair required → appropriate offline rescue runbook, not repeated Run Command.

Common trap. An installed agent is not evidence it is currently running or connected.

Official references: EC2Rescue runbook · Automation

AWS references: Automation · Session Manager · Patch Manager

Multi-account operations

Apply approved governance and share or deploy resources across account and Region boundaries.

Flow. Baseline → StackSet instances; existing supported resource → RAM share; access → IAM plus guardrails.

• Organizations organises accounts/OUs; SCPs restrict applicable member-account permissions and never grant access. IAM Identity Center provides workforce federation and permission-set access.
• Control Tower establishes/governs a landing zone; Service Catalog distributes approved products. RAM shares supported existing resources, such as subnets, without cloning every resource.
• StackSets deploys template instances; regional settings and service availability still matter. Track execution roles, delegated administration, organisational units and excluded accounts.
• Use tags, Cost Explorer and Cost and Usage Reports to identify waste and ownership; check Compute Optimizer/Trusted Advisor recommendations against workload requirements. Savings Plans are discounts, not capacity guarantees.

Choose / compare. Replicate infrastructure → StackSets; share a resource → RAM; limit allowed operations → SCP; grant a workforce session → Identity Center plus permission policies.

Exam clue. Same baseline in many accounts/Regions → StackSets; share existing subnets → RAM.

Trap. An SCP allow does not grant an IAM permission. Cost optimisation must preserve availability and recovery constraints.

Example

aws cloudformation list-stack-instances --stack-set-name baseline
aws organizations list-policies-for-target --target-id ACCOUNT_ID \
  --filter SERVICE_CONTROL_POLICY

Investigate, remediate & verify

Evidence. When one account fails, compare OU/SCP inheritance, role trust, service-linked roles, Region enablement, quotas and target resource policies.

Action → verification. Repair the smallest applicable control, test with a least-privilege session and verify both allowed and intentionally denied operations across the affected accounts.

Analogy. Account policies set the building rules; IAM grants individual access cards.

StackSets: one template, separate target stacks

Common template → StackSet → selected account × Region stacks → per-target status

Each selected account–Region combination receives its own stack/resources. Region order and account concurrency control rollout; console, CLI/API and IaC can configure it.

StackSets replicate one template definition, with supported parameter overrides. They are not a general dependency orchestrator for unrelated templates. Check target roles, capabilities and resource naming before broad rollout.

Target account	Sydney	Melbourne
Development	Own stack/resources	Own stack/resources
Production	Own stack/resources	Own stack/resources

aws cloudformation list-stack-instances --stack-set-name baseline

Exam trigger. Apply the same baseline to many account–Region targets → StackSets.

Common trap. A single StackSet operation does not create one global stack or one shared copy of every resource.

Official references: StackSets

AWS references: SCPs · RAM · Identity Center

IAM access investigation

Separate authentication, role trust and permission to perform an action on a resource.

Flow. Principal → trusted session → action/resource/context evaluation → allowed or denied operation.

• Identity policies grant actions to identities; resource policies grant supported resource access. Trust policies control role assumption. Cross-account access generally needs trust/resource permission and caller-side permission as applicable.
• Explicit deny wins. Permissions boundaries, session policies and SCPs limit permissions; they do not independently grant them. Resource-policy evaluation has principal-specific exceptions: inspect the actual principal/session.
• Use roles with temporary credentials and MFA/federation for people. IAM Access Analyzer identifies supported external/unused access; the policy simulator helps test policies but is not a full live request.
• Inspect conditions such as source ARN/account, requested Region, tags, VPC endpoint and MFA. A valid credential does not bypass a missing network route.

Choose / compare. Cannot assume role → check caller permission and target trust; session exists but action denied → inspect action/resource, limits, conditions and relevant resource policy.

Try the related local exercise: access

Exam clue. A user authenticated successfully yet receives AccessDenied → investigate authorisation, not a password reset.

Trap. An execution role controls what code calls; it does not automatically allow a service to invoke that code. A network filter cannot grant IAM access.

Example

aws sts get-caller-identity
aws sts decode-authorization-message --encoded-message ENCODED_MESSAGE
# Requires sts:DecodeAuthorizationMessage; inspect returned decision context.

Investigate, remediate & verify

Evidence. Start with sts get-caller-identity, exact denied action/resource and CloudTrail error. Decode an encoded authorisation message with STS when present and authorised.

Action → verification. Correct narrowly scoped policies, then retry the precise operation and test a prohibited operation. Avoid attaching AdministratorAccess as an investigation shortcut.

Analogy. Trust admits a visitor; permissions specify rooms; guardrails limit the entire visit.

Cross-account S3 copy: keep one identity with both permissions

Finance credentials → CopyObject(destination Finance, source HR/Audit)
Same credentials must pass source GetObject AND destination PutObject

Direct access can combine Finance identity-policy permissions with HR/Audit bucket policies granting the Finance principal source reads. Identity policies attach to users/groups/roles; bucket policies attach to buckets.

AssumeRole returns a different role session. It does not union the original Finance user’s permissions with the HR role’s permissions. A role needs trust for assumption and permissions for the actual source/destination operations.

This example assumes same-partition general-purpose buckets and isolates policy evaluation. Object ownership, explicit denies, organisation controls and any SSE-KMS permissions can add requirements.

# Excerpt: run with the intended Finance profile; review all policies first
aws s3api copy-object --profile finance --bucket finance-archive \
  --key audit/report.csv --copy-source audit-source/report.csv

Exam trigger. Copy across accounts while retaining existing Finance writes → grant direct source access to that Finance identity.

Common trap. Assuming a source-account role does not automatically carry the original identity’s destination write permission.

Official references: Copy permissions · Role session permissions

AWS references: Policy evaluation · Access Analyzer

Config & continuous compliance

Record supported resource configuration changes and evaluate configured compliance rules.

Flow. Supported resource configuration → recorder → rule evaluation → safe remediation → re-evaluation.

• A recorder captures supported resource types in its configured scope; rules evaluate recorded configuration or periodic conditions. An aggregator collects multi-account/Region views; it does not replace source recorders.
• Conformance packs group rules and remediation definitions. Automatic remediation requires configured permissions and safe assumptions; stale evaluations can trigger inappropriate action.
• CloudTrail records the API actor, while Config records the resource’s configuration history. Artifact supplies AWS compliance documents, not continuous auditing of your workload.
• Implement supplied classification and compliance requirements through tags, resource selection, encryption and approved Regions/services; do not invent the organisation’s policy.

Choose / compare. Need history/compliance of a resource property → Config; need who changed it → CloudTrail.

Exam clue. Continuously identify unencrypted supported resources → Config rule/conformance pack.

Trap. An aggregator is a view, not automatic recording or repair. A compliant rule result only proves that rule’s evaluated condition.

Example

aws configservice describe-compliance-by-config-rule \
  --compliance-types NON_COMPLIANT
aws configservice describe-configuration-recorder-status

Investigate, remediate & verify

Evidence. Check recorder status, resource support/scope, delivery errors, rule triggers, evaluation timestamp and remediation execution output.

Action → verification. Correct the resource through managed configuration, re-evaluate and verify COMPLIANT plus the actual setting. Adjust permissions/preconditions to prevent remediation loops.

Analogy. A property inspection log, compared with a checklist at each relevant change.

AWS references: Config · Conformance packs

KMS, encryption & secrets

Control cryptographic key use separately from access to encrypted data.

Flow. Encrypted data key → authorised KMS Decrypt → recovered data key → local/service data decryption.

• SSE-S3 uses S3-managed keys; SSE-KMS uses KMS-protected data keys. A customer-managed KMS key offers policy/lifecycle control. SSE-C supplies a key to S3 over HTTPS; client-side encryption happens before upload.
• Envelope encryption protects large data locally with a data key; KMS protects that key. GenerateDataKey returns plaintext and encrypted representations; the application stores the encrypted one and protects/clears plaintext.
• A KMS key policy is essential; IAM permission only works when the key policy permits that mechanism. Cross-account key use needs appropriate key-policy and identity permissions. Check key Region, state, grants and encryption context.
• Secrets Manager stores and rotates supported credentials; Parameter Store SecureString protects named configuration. Rotation must update dependent applications and connectivity correctly.

Choose / compare. Object read allowed but SSE-KMS decryption denied → check key access as well as S3. Key rotation does not require re-encrypting every object and does not fix an access policy.

Mode	Key / encryption responsibility	Operational check
SSE-S3	S3 manages keys; S3 encrypts	S3 permissions and resulting object mode.
SSE-KMS	KMS-protected data key; S3 encrypts	Object access plus applicable KMS policy/state/context.
SSE-C	Customer sends key over HTTPS; S3 encrypts	Customer retains key; S3 does not persist it; no inherent KMS dependency.
Client-side encryption	Client encrypts before upload	Client key recovery/libraries; S3 receives ciphertext.

Try the related local exercise: access

Exam clue. S3 GetObject permission succeeds but encrypted object remains unreadable → KMS policy/state/context investigation.

Trap. KMS permissions do not grant S3 access; S3 permissions do not automatically grant KMS use. GenerateDataKeyWithPlaintext is not an API.

Example

aws kms describe-key --key-id KEY_ARN
aws kms get-key-policy --key-id KEY_ARN --policy-name default
# Inspect policy; do not print secrets or plaintext data keys into logs.

Investigate, remediate & verify

Evidence. Inspect the exact KMS error, CloudTrail key operation, key ARN/state, key policy, caller IAM policy, grants and encryption context. A disabled/deleting key can make data unavailable.

Action → verification. Restore approved key access/state, retry a controlled decrypt/read and verify expected denies. Test a rotated secret with the dependent service before marking rotation complete.

Analogy. Access to the locked cabinet and permission to use its key are separate checks.

Encrypted ASG launches: authorise the service-linked role

AMI + encrypted snapshot → ASG service-linked role → KMS authorisation → fresh encrypted volume
Application instance profile acts later, after the instance boots.

For a customer-managed key in the ASG account, grant the ASG service-linked role the documented key-use and grant-creation permissions. Giving only the instance application role decrypt access does not authorise image launch.

For a key owned by another account, AWS’s ASG workflow requires the key policy plus an explicit KMS grant for the ASG service-linked role. An authorised principal creates that grant; this is not a cross-account AssumeRole flow.

Copying/re-encrypting the image under a key in the consuming account is an alternative, not mandatory. A question that omits key ownership is missing the deciding condition; do not silently assume another account.

A missing launch-key permission can surface as generic Client.InternalError. Check the ASG service-linked role (normally AWSServiceRoleForAutoScaling), source key ownership and scaling activity. EC2/EBS creates a new virtual volume; data keys encrypt blocks and KMS keys protect those data keys. Exact KMS operations depend on source-snapshot encryption.

Key owner	Relevant control	Not sufficient
Same ASG account	Documented key policy for ASG service-linked role	Only the application instance profile
Different account	Key policy + explicit grant for ASG service-linked role	AssumeRole alone or AMI launch permission alone

Exam trigger. Encrypted ASG launch fails before application startup → inspect the service-linked role, key owner, policy and required grant.

Common trap. A role trust policy, an application-role Allow and a KMS grant are different controls.

Official references: AWS ASG key policy and grant examples

AWS references: KMS policies · Data keys · Secrets rotation

ACM & encrypted connections

Maintain trusted certificates and TLS configuration at the actual termination point.

Flow. Domain validation → suitable ACM certificate → correct listener/endpoint → validated TLS connection.

• ALB HTTPS listeners need a suitable certificate in the load balancer’s Region. A CloudFront viewer certificate from ACM must be in us-east-1.
• Check SAN/hostname match, expiry, validation status, chain and listener security policy. Eligible ACM-managed renewal relies on continued validation and service use.
• Viewer-to-edge TLS and edge/load-balancer-to-origin TLS are separate connections. Encrypting one leg does not prove the backend leg is protected.

Choose / compare. Need certificate lifecycle → ACM; need encryption keys for stored data → KMS. DNS validation proves domain control, not application health.

Exam clue. Browser certificate mismatch → hostname/certificate/listener investigation before changing IAM.

Trap. A valid certificate in the wrong Region cannot be attached to the ALB. CloudFront’s viewer certificate Region is a special requirement.

Example

openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null
# Diagnostic command; inspect certificate dates, chain and hostname separately.

Investigate, remediate & verify

Evidence. Inspect the certificate actually served with SNI, DNS record, listener binding, validation records and origin hostname/trust.

Action → verification. Attach/renew the correct certificate and policy, then test hostname validation and both connection legs. Retain DNS validation records for managed renewal.

Analogy. A certificate is a verified identity document for a particular connection endpoint.

AWS references: ACM · CloudFront certificates

Security findings & classification

Interpret the finding type, prioritise impact and verify the relevant corrective control.

Flow. Specialist assessment → finding → prioritised investigation → corrective control → reassessment.

• GuardDuty detects threats from supported data sources; Inspector assesses supported workload vulnerabilities/exposure; Macie discovers sensitive S3 data.
• Security Hub aggregates/prioritises supported findings and security posture checks. Config evaluates configuration compliance. Trusted Advisor provides supported advisory checks; availability depends on plan/feature.
• Apply the supplied data classification to access, encryption, retention and logging. A classification label without enforcement does not protect data.
• Current guide terminology includes AWS Security Agent; its docs now describe it as part of AWS Continuum. It supports application security review/threat modelling/penetration testing, not a replacement for runtime threat detection.

Choose / compare. Vulnerable package → Inspector; suspicious activity → GuardDuty; sensitive S3 content → Macie; aggregate findings → Security Hub.

Exam clue. Central view of findings from several supported security services → Security Hub.

Trap. A suppressed or archived finding is not proof of remediation. AWS Artifact reports describe AWS controls, not your instance’s patch status.

Example

# Inspector example: list findings for inspection, then filter to the affected resource
aws inspector2 list-findings --max-results 10

Investigate, remediate & verify

Evidence. Read resource/account/Region, evidence, severity, last observation and workflow status. Confirm the affected running artifact and possible exposure before dismissing a finding.

Action → verification. Patch/isolate/restrict according to the approved runbook; rescan and verify runtime version, connectivity and finding state. Preserve investigation evidence.

Analogy. Different inspectors check different hazards; the central register does not perform every inspection.

AWS references: Security Hub · Inspector · Security Agent / Continuum

VPC routes, subnets & filters

Provide address space, routing and traffic controls for VPC-associated workloads.

Flow. Source → route → applicable filters → target listener → permitted return path.

• A VPC is regional; a subnet belongs to one AZ. Plan non-overlapping CIDRs, free subnet IPs and routes. A public subnet has an internet-gateway route; an instance also needs appropriate addressing and filters for IPv4 internet access.
• Route tables select paths; longest-prefix matching matters. Security groups are stateful allow filters on ENIs; NACLs are stateless ordered allow/deny filters at subnet boundaries.
• IPv4 private egress commonly uses NAT; an egress-only internet gateway handles outbound-initiated IPv6 internet connections. For zonal NAT deployments, align AZ paths to avoid a dependency on another AZ and unnecessary transfer.
• Peering is non-transitive and needs routes on both sides. Transit Gateway connects supported networks through attachments and associated/propagated route tables. These paths still need security controls.

Choose / compare. An IAM denial needs policy analysis; a timeout needs DNS/routes/filters/target checks. A route does not grant application authorisation.

Control	Mechanism	Return path
Security group	Stateful; allow rules on ENIs	Allowed established-flow return is tracked.
NACL	Stateless; ordered allow/deny at subnet	Explicit request and ephemeral return rules.
Route table	Destination-prefix path selection	Destination must have a valid return route too.
DNS	Name → address / endpoint	A correct answer does not prove TCP connectivity.

Try the related local exercise: network

Exam clue. Request arrives but response is blocked with stateless filtering → inspect ephemeral return-port rules.

Trap. A NAT gateway does not accept unsolicited inbound internet connections. An internet-gateway route alone does not assign a public IP.

Example

# Return path illustration, not firewall syntax
browser:54321 → ALB:443
ALB:443 → browser:54321
# NACLs must permit the relevant destination ports in both directions.

Investigate, remediate & verify

Evidence. Trace DNS → source subnet route → gateway/attachment → destination route → SG/NACL → listener → return path. Check overlapping CIDRs and subnet address exhaustion.

Action → verification. Correct the specific route/filter/address issue, test from the affected source and verify both request and response. Restrict the fix to required peers/ports.

Analogy. Routes are roads; firewalls are gates; DNS is the address book.

Same VPC: a route is not permission

App ENI → subnet route table’s local path → DB ENI
                      then applicable SG / NACL checks → database port

A VPC is Regional; a subnet occupies one AZ. Each subnet has one associated route table, while a table can serve several subnets. Tables automatically have local routes for the VPC CIDRs; separate same-VPC subnets normally already have a routing path.

That path does not authorise the connection. A typical EC2 → RDS connection needs the DB security group to allow the database port from the app security group, plus permitted NACL/return traffic. SGs apply to ENIs/resources; NACLs apply at subnet boundaries.

IPv4 and IPv6 CIDRs are separate address spaces. IPv6 assignment is optional; an EC2 instance does not automatically receive IPv6 merely because it exists in a VPC.

Exam trigger. Same-VPC SQL timeout with a valid local route → check DB ingress, NACLs and the listener before adding routing infrastructure.

Common trap. Different subnets do not, by themselves, mean private instances or blocked inter-subnet routing.

Official references: Route tables · Security controls

New versus default security controls

Route exists → verify the actual rules → test request AND return traffic

These are initial defaults, not a substitute for inspecting the current configuration. The default security group’s self-reference covers resources assigned to that group; it is not a blanket inbound allow from the whole VPC.

Control at creation	Inbound	Outbound
New custom SG	No allow rules	All outbound initially
Default SG	From resources using itself	All outbound initially
Default NACL	Allow traffic	Allow traffic
New custom NACL	Deny until configured	Deny until configured

Exam trigger. A newly created custom NACL can block a routed connection before any application code runs.

Common trap. “Default security group” and “new custom security group” have different initial inbound rules.

Official references: Default SG · Default NACL

IGW, NAT and egress-only IGW

Direct IPv4: public IPv4/EIP + IGW route + filters
Private IPv4: private instance → public NAT → IGW
Outbound-only IPv6: IPv6 instance → egress-only IGW

For direct IPv4 internet access, an IGW route alone is insufficient: the instance also needs public IPv4 addressing and suitable rules. A public NAT gateway lets private IPv4 clients initiate connections and receive replies.

An egress-only IGW is IPv6-only: it permits outbound-initiated flows and their replies while preventing new internet-initiated connections. It does not translate IPv4 or assign IPv6 addresses.

Exam trigger. Outbound-only IPv6 requirement → egress-only IGW; private IPv4 egress → suitable NAT path.

Common trap. A public subnet route does not automatically attach a public address to every instance.

Official references: Egress-only IGW · Internet gateway

Public address does not prove public-internet transit

AWS public IP → AWS global network → AWS public IP (documented exceptions)
Private IP + configured peering routes → private-address path

Current AWS documentation says AWS-originating/AWS-destined public-IP traffic stays on its global network, except traffic to/from China Regions and the European Sovereign Cloud Region.

Inter-Region peering supplies private addressing/routes over the AWS backbone. Merely creating peering does not reroute calls still addressed to public IPs. Routes, permissions, addressing and TLS remain separate checks.

Exam trigger. Need private addressing → private connectivity/routes; do not use an outdated public-IP transit explanation.

Common trap. Edge locations and Direct Connect are not automatically inserted into an ordinary EC2-to-EC2 request.

Official references: VPC network behaviour

AWS references: Routes · SG vs NACL · NAT

Endpoints & private connectivity

Reach supported services privately with the correct endpoint and DNS/routing model.

Flow. Signed service request → gateway route or interface ENI → AWS service; permissions remain separate.

• Gateway endpoints support S3 and DynamoDB using route-table entries and service prefix lists; they do not create application-subnet ENIs and have no additional endpoint charge.
• Interface endpoints use PrivateLink ENIs in selected subnets/AZs with security groups and optional private DNS. They typically charge hourly and for data processing.
• An endpoint policy limits applicable access; it does not replace IAM, resource or KMS policies. S3 supports gateway and interface models with different reachability/use cases.
• Troubleshoot existing Site-to-Site VPN/Client VPN and hybrid routes with tunnel status, BGP/static routes, DNS forwarding and filters. Consider Transit Gateway/peering path and return routing; do not assume transitive peering.

Choose / compare. Private EC2 to S3/DynamoDB in the same Region/VPC context → gateway endpoint is often sufficient; supported private API access via ENIs → interface endpoint.

Endpoint	Network representation	Key decision
Gateway	Route-table prefix-list target	S3/DynamoDB; no additional endpoint charge; not a transitive hybrid doorway.
Interface	PrivateLink ENIs + SGs in selected subnets	Supported APIs/private DNS; hourly and processing charges.

Try the related local exercise: network

Exam clue. No NAT needed for private S3 access from the workload VPC → suitable S3 gateway endpoint.

Trap. Gateway endpoints are not transitive through peering/TGW for remote clients. Registering an endpoint does not authorise every API operation.

Example

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-0123456789abcdef0
# Gateway: S3 prefix-list route; interface: HTTPS → private ENI.

Investigate, remediate & verify

Evidence. Check service/Region, private DNS, VPC DNS settings, endpoint SG:443, route-table association, endpoint policy and caller/resource permissions.

Action → verification. Correct routing/DNS/access, test the service API from the private workload and confirm the actual endpoint path. Compare endpoint and NAT costs for traffic volume and AZ placement.

Analogy. A private doorway still needs a working road, the correct address and an access card.

AWS references: S3 gateway endpoints · Interface endpoints · VPN troubleshooting

Route 53 & DNS operations

Resolve names and choose DNS answers according to the configured routing and health policy.

Flow. Name query → appropriate resolver/zone → routing policy → DNS answer; application traffic follows separately.

• Public hosted zones answer internet DNS; private hosted zones require appropriate VPC association/resolution. Check delegation, record type/name and split-horizon behaviour.
• Failover supports primary/secondary answers; weighted splits DNS answers; latency selects suitable regional endpoints. Health checks and EvaluateTargetHealth affect eligible answers, subject to policy behaviour.
• Route 53 Resolver inbound/outbound endpoints and forwarding rules support hybrid name resolution. Allow DNS traffic and avoid forwarding loops; log queries to investigate actual names/responses. Current documentation calls the VPC service Route 53 VPC Resolver; the exam guide also uses the older Resolver name.
• DNS Firewall filters supported Resolver queries by domain rules. WAF filters HTTP requests, Shield addresses DDoS protection and Network Firewall filters network traffic; their boundaries differ.

Choose / compare. Name fails but IP works → DNS investigation. Static global IP entry and supported endpoint failover → Global Accelerator may fit better than DNS changes.

Exam clue. Only on-premises clients cannot resolve a private AWS name → inspect Resolver inbound path and conditional forwarding.

Trap. DNS supplies an address; the application request is a separate connection. Weighted DNS does not guarantee a precise per-request percentage.

Example

dig api.example.com
dig @VPC_RESOLVER_IP internal.example.com
# Use a real reachable resolver IP; compare answer, status and TTL.

Investigate, remediate & verify

Evidence. Use dig from the affected network; inspect authoritative answers, TTL/cache, hosted-zone association, Resolver rules, endpoint SGs and health-check results.

Action → verification. Repair delegation/record/forwarding, then verify from public and private clients after appropriate cache expiry. DNS failover is not instant active-connection migration.

Analogy. An address book can choose a branch, but it does not carry the visitor to that branch.

AWS references: Routing policies · Resolver · DNS Firewall

CloudFront & Global Accelerator

Operate global delivery with the right cache, origin and failover behaviour.

Flow. Viewer → CloudFront cache hit or configured origin; Global Accelerator is an alternative traffic-entry pattern.

• CloudFront caches eligible HTTP content at edge locations. Behaviours choose origins by path; a cache key distinguishes query strings/headers/cookies that genuinely change the response.
• An origin group supplies primary/secondary failover for GET, HEAD and OPTIONS under configured failure conditions; it does not merge responses. TTL changes cannot fix a missing language/tenant cache-key dimension.
• CloudFront Functions handles lightweight supported viewer transformations; Lambda@Edge supports broader request/response processing. Dynamic content alone does not require edge code.
• Global Accelerator provides static anycast IP entry and routes supported TCP/UDP application traffic to healthy endpoints over the AWS network; it is not an HTTP object cache.

Choose / compare. Cache HTTP responses/static S3 images → CloudFront; stable global IPs and endpoint routing → Global Accelerator. Compare transfer, request, invalidation and accelerator charges.

Capability	Choose for	Common mistake
CloudFront behaviours / origins	Path-based HTTP content sources and caching	Treating every origin as a failover target.
CloudFront origin group	Configured primary/secondary read-request failover	Assuming general POST replay or merged responses.
CloudFront Functions / Lambda@Edge	Required supported custom request/response work	Assuming dynamic content always requires edge code.
Global Accelerator	Static anycast entry + supported endpoint routing	Treating it as an HTTP object cache.

Exam clue. Wrong language served from cache → cache key; need a stable global anycast entry → Global Accelerator.

Trap. Forwarding a parameter to the origin and including it in the cache key are distinct choices. Origin failover is not general write-request replay.

Example

# Conceptual cache keys
/reviews?lang=en → /reviews|lang=en
/reviews?lang=ja → /reviews|lang=ja
# Include lang in cache policy if it changes the origin response.

Investigate, remediate & verify

Evidence. Inspect DNS, viewer/origin TLS, behaviour match, cache policy, origin request policy, status/error caching, origin health and relevant access/WAF logs.

Action → verification. Correct the policy/origin rather than repeatedly lowering TTL; invalidate when appropriate, then test cache hit/miss and response correctness for distinct request variants.

Analogy. CloudFront is a local copy desk; Global Accelerator is a globally advertised entrance to the application.

Origin Shield consolidates cache misses

Viewer → edge → Regional edge cache → selected Origin Shield → origin
                                (applicable bypass/routing exceptions)

Origin Shield is an additional AWS-managed CloudFront caching layer in a selected Region, not an ElastiCache cluster you deploy. It consolidates eligible origin-bound misses from caching layers.

Choose the supported Shield Region with the lowest latency to the origin. Weighted DNS can distribute traffic but does not inherently consolidate repeated misses or improve cache reuse.

Exam trigger. Many cache locations request the same uncached object → evaluate Origin Shield for origin-load reduction.

Common trap. The typical cache hierarchy has exceptions; do not promise every request always traverses every cache layer.

Official references: Origin Shield

S3 REST origin versus website custom origin

Preferred private origin: CloudFront OAC → signed S3 REST request → restrictive bucket policy
Website endpoint: CloudFront custom origin → HTTP website request

OAC is preferred over legacy OAI for supported S3 REST origins. S3 website endpoints are custom origins: neither OAC nor OAI applies, and the website endpoint supports HTTP only.

A configured secret Referer header checked by a bucket policy is a limited website-origin workaround. Headers can be spoofed; this is not equivalent to authenticated OAC access. For robust CloudFront-only access, use the REST endpoint with appropriate OAC and bucket restrictions.

Exam trigger. Private S3 content accessible only through a distribution → REST origin + OAC + scoped bucket policy.

Common trap. Changing an origin label does not turn a website endpoint into a REST endpoint or add HTTPS support.

Official references: OAC / OAI restrictions · Website endpoint differences · Referer limitations

Endpoint location versus SigV4 signing Region

CloudFront (global) → request signed for Sydney
                         bucket now in Singapore → 400 AuthorizationHeaderMalformed

The origin endpoint directs the request; the SigV4 authorisation scope authenticates it and includes a Region. S3 must accept that signing Region. It is not merely a routing field in a JSON body.

Deleting a bucket and recreating its name in another Region can leave stale origin/signing information in a distribution. Confirm the actual bucket Region, update/re-save the CloudFront origin and allow deployment to finish, then retest.

CloudFront distributions are global and access keys do not have a home Region. An explicit wrong-Region S3 response proves an HTTP exchange occurred; it is different from a network timeout.

# Illustrative credential scope, not credentials or an executable request
Credential=<access-key-id>/<date>/ap-southeast-2/s3/aws4_request
# Compare the Region with what the actual S3 bucket expects.

Exam trigger. S3 explicitly says the signing Region is wrong → investigate origin metadata and request scope, not CloudFront’s supposed home Region.

Common trap. The bucket was deleted/recreated, not moved in place. Broader bucket permissions do not repair a malformed signing scope.

Official references: AWS wrong-signing-Region recovery

AWS references: Cache keys · Origin failover · Global Accelerator

Network evidence & protection

Identify the failing hop with configuration analysis, flow records and measured network health.

Flow. Configuration model / flow record / live probe → evidence → targeted check → real traffic verification.

• VPC Flow Logs describe supported IP traffic metadata and ACCEPT/REJECT decisions; they are not packet payload captures and are not instantaneous.
• Reachability Analyzer models supported configuration paths without sending packets. A reachable model does not prove the application is listening or healthy.
• CloudWatch Internet Monitor observes internet-path performance for configured resources; Network Synthetic Monitor probes supported hybrid paths for latency/loss. Network Flow Monitor provides supported workload flow/performance visibility.
• Use ALB/CloudFront access logs for HTTP status and timing, WAF logs for rule decisions and container logs for application/network startup faults. Audit WAF, Shield, DNS Firewall and Network Firewall at their own inspection boundaries.

Choose / compare. Configuration block → Reachability Analyzer; actual accepted/rejected IP flow → Flow Logs; internet/hybrid degradation → the relevant CloudWatch network monitor.

Exam clue. Need to locate a configured network block without probing production → Reachability Analyzer.

Trap. Flow Logs ACCEPT is not HTTP 200. A trace gap can be sampling/instrumentation rather than a network failure.

Example

# Illustrative Flow Log excerpt, simplified
srcaddr=10.0.11.20 dstaddr=10.0.21.30 dstport=5432 protocol=6 action=REJECT
# Inspect relevant SG/NACL configuration; record alone does not identify the exact rule.

Investigate, remediate & verify

Evidence. Correlate source/destination IPs, ports, protocol, direction and time. Interpret ACCEPT as filter acceptance, not business success; verify route symmetry and DNS separately.

Action → verification. Repair the first proven failing dependency, retest actual connectivity/application response and compare before/after latency, loss and log outcomes.

Analogy. A road map, a traffic register and a timed test drive answer different questions.

AWS references: Flow Logs · Reachability Analyzer · Network Synthetic Monitor

Health & assisted investigation

Use service health and assisted analysis as evidence within an accountable operational process.

Flow. Incident → affected scope → connected evidence → reviewed hypothesis → approved repair → verification.

• AWS Health provides relevant service/account event information; compare affected Region/resources with your own telemetry rather than assuming every failure is AWS-wide.
• AWS DevOps Agent correlates connected operational evidence and deployment context to investigate incidents and recommend improvements. Scope integrations/roles and validate conclusions against logs and metrics.
• Kiro assists with code/configuration and troubleshooting workflows. Review generated commands and changes; an assistant recommendation is not a verified root cause or an approved production change.
• Monitor AI workloads as workloads: access, model/API quotas, errors, latency, cost and sensitive logging. Bedrock being in scope does not turn SOA-C03 into model-training certification.

Choose / compare. Suspected AWS service disruption → AWS Health plus resource telemetry; cross-signal investigation → assisted tooling with least-privilege evidence access.

Exam clue. Current guide names Kiro/DevOps Agent: know their investigation/automation role, not an invented replacement for monitoring.

Trap. The June 2026 guide revision matters; older SOA-C02 service lists omit newer capabilities. Validate service names/features against current docs.

Example

# Investigation checklist (conceptual)
symptom → affected account/Region/AZ → evidence → hypothesis
→ approved action → user-visible verification → prevention

Investigate, remediate & verify

Evidence. Check the affected scope, linked telemetry, permissions and recent changes. Identify what evidence supports each hypothesis and what test would disprove it.

Action → verification. Execute the approved bounded repair, verify user-visible recovery and record evidence. Treat recommendations as inputs to change control, not automatic proof.

Analogy. An experienced assistant can propose a diagnosis; measurements and a recovery test establish the outcome.

Quota recommendation or application investigation?

Trusted Advisor check status → EventBridge us-east-1 → SNS
Application telemetry → trace map / older ServiceLens → investigate dependency

Trusted Advisor evaluates supported environment checks across cost, security, resilience, performance, operational excellence and quotas. Service-limit checks flag 80% yellow and 100% red; results are snapshots, not live throughput measurements.

Kinesis shard-count quota is distinct from IncomingBytes/IncomingRecords and throughput-exceeded metrics. Trace correlation needs configured/instrumented telemetry; it does not invent a latency target.

Trusted Advisor events are best effort in us-east-1. Current documentation requires Business Support+, Enterprise Support or Unified Operations for this EventBridge integration; older exam material uses earlier plan names.

Question	Use	Evidence
Which dependency is slow?	Trace map / ServiceLens terminology	Instrumented request spans, logs, metrics
Are supported quotas nearly used?	Trusted Advisor / Service Quotas	Configuration/usage and supported check
Are records being throttled?	Kinesis CloudWatch metrics	Per-shard/stream throughput and errors

Exam trigger. Quota utilisation warning → supported quota check; slow checkout dependency → metrics/logs/traces.

Common trap. A shard-count quota increase does not itself fix a hot partition key or per-shard throughput throttling.

Official references: Trusted Advisor · Quota criteria · Events / plan eligibility

AWS references: AWS Health · DevOps Agent · Kiro