SAA-C03 practice exam — 555 free practice questions

A restriction that must bind account administrators cannot live inside the accounts those administrators control. Service control policies are applied from AWS Organizations and set the maximum permissions for every principal in the member accounts they reach.

The SCP on the Development OU works because it is enforced at a layer no Development-account principal can change: it is inherited by each account in the OU, restricts member-account root users too, and denies the CloudTrail actions whatever the IAM policies allow. The IAM deny policy and the permissions boundary deny the same actions, but both are IAM objects inside the account, so an administrator with full IAM permissions can detach them. The Config rule is detective: it tells the security team that logging stopped instead of stopping the action.

1. Classify the requirement: it is preventive and must bind administrators of the affected accounts.
2. Ask who controls each option: IAM policies and permissions boundaries are managed by the account's own administrators.
3. Discard detective controls such as Config rules when the requirement is to prevent an action.
4. Place the deny above the accounts: an SCP attached to the Development OU is inherited by every account in it.

Exam tip: "No one in these accounts, including admins" means an SCP on the OU; anything managed inside the account can be removed by its admins.

Inserting a queue between tiers converts a traffic spike into a durable backlog that a worker tier drains at its own pace. The tiers are decoupled, so each scales on its own signal and no work is lost while consumers catch up.

The SQS design meets both requirements: SQS keeps every job until a worker processes and deletes it (no lost renditions), and scaling the worker group on queue backlog adds capacity only while a backlog exists (cost-effective for unpredictable spikes). The load balancer plus CPU scaling option is the tempting near-twin: it does scale, but the web tier still waits on the rendition fleet, and anything that arrives while the fleet is saturated and new instances are still booting times out with nowhere to wait. Sizing the minimum capacity for the biggest spike so far keeps the same fragile call path, has a ceiling the next viral post can exceed, and bills idle capacity around the clock. SNS looks like decoupling but is push delivery without consumer pacing; overwhelmed HTTP subscribers exhaust retries and the job is dropped.

1. Diagnose the failure: synchronous calls into a saturated tier lose work during spikes, which is tight coupling.
2. Add a durable intermediary: an SQS queue stores each job until a worker finishes and deletes it.
3. Scale the consumer on the right signal: queue backlog grows the worker group during a spike and shrinks it afterward.
4. Check cost: elastic workers that follow the backlog beat a permanently peak-sized floor.

Exam tip: When spikes lose work between tiers, buffer with SQS and scale the workers on queue backlog; a load balancer spreads requests but stores none.

EBS volume selection is a ladder that starts at gp3: it is the cost-effective default for boot volumes and general databases, and you only climb to io2 when the stated requirement exceeds what gp3 can provision.

The numbers decide it. Random I/O at 9,000 IOPS rules out HDD media, and the persistence requirement rules out instance store. Between the two SSD types, gp3 can be provisioned far past this load (its IOPS and throughput are set independently of volume size) and its single-digit-millisecond latency is explicitly acceptable, so io2's higher price buys nothing the workload asks for. io2 is the tempting overshoot: it works, but MOST cost-effective means the cheapest option that meets the stated need.

1. Classify the access pattern: small random reads and writes from a relational database need SSD, which eliminates st1.
2. Check durability: data must survive stops, which eliminates instance store.
3. Compare the measured load with gp3: 200 MiB/s is above the 125 MiB/s baseline and 9,000 IOPS above the 3,000 baseline, but both are well within what gp3 can be provisioned to.
4. Check the latency requirement: single-digit milliseconds is acceptable, so io2's sub-millisecond consistency is not needed.
5. Apply the cost qualifier: gp3 is the cheapest volume that meets every stated requirement.

Exam tip: Under a cost qualifier, pick gp3 whenever it meets the stated performance — io2 is only justified when the requirement exceeds gp3.

S3 class selection maps each phase of an access pattern to the cheapest class that still meets it. Standard-IA suits data accessed roughly monthly that must stay immediately available, with a 30-day minimum storage duration and a per-GB retrieval fee.

The reports have two phases: frequent access for 30 days, then occasional access needing millisecond reads. Standard is right for phase one because IA-class retrieval fees would dominate under frequent access. Transitioning to Standard-IA at day 30 is the earliest supported IA transition, satisfies the 30-day minimum duration, and keeps millisecond access at a much lower storage price. Glacier Instant Retrieval keeps millisecond access but its retrieval fees are priced for roughly quarterly access, so a-few-times-per-month reads make it more expensive than Standard-IA. Glacier Flexible Retrieval fails the millisecond requirement outright because restores are asynchronous. Staying in Standard for two years over-delivers: it meets every requirement but is not the cheapest option that does.

1. Split the lifecycle into phases: frequent access for 30 days, then a-few-times-per-month access with millisecond reads for two years.
2. Assign Standard to the frequent phase, since any IA or Glacier class would charge retrieval fees on every download.
3. For the second phase, require millisecond access, which eliminates Glacier Flexible Retrieval.
4. Compare Standard-IA and Glacier Instant Retrieval at the stated frequency: monthly access favors Standard-IA because Glacier Instant Retrieval retrieval fees are tuned for quarterly access.
5. Verify the trap: the 30-day transition satisfies Standard-IA's 30-day minimum duration, so no minimum-duration penalty applies.

Exam tip: Monthly access with millisecond reads is the Standard-IA pattern; quarterly access is Glacier Instant Retrieval's.

Service control policies are guardrails: they define the maximum permissions available to principals in member accounts, but they never grant permissions. An action succeeds only if an identity-based or resource-based policy allows it and every applicable SCP permits it.

The user has no identity-based policy, so nothing grants the S3 action and the request is implicitly denied. The SCP's allow statements only mean that S3 and EC2 are not filtered out; they do not give anyone access. The propagation explanation is wrong because SCP changes apply within minutes and would not grant access anyway. SCPs attached directly to accounts are valid. Bucket policies are not needed for a same-account principal to list buckets; an identity-based policy is.

1. Note that the user has no IAM policies at all.
2. Recall that an SCP sets a ceiling and never grants a permission.
3. With no allow anywhere, the default implicit deny applies.
4. Fix: attach an identity-based policy (preferably to a group) that allows the needed S3 actions.

Exam tip: An SCP allow is permission to be granted, not a grant; someone still has to write an IAM policy.