Free SAA-C03 practice questions

Restrictions that must bind account administrators cannot live inside the accounts those administrators control. Service control policies are applied from AWS Organizations, above the member accounts, and set the maximum permissions available to every principal within them.

The SCP on the Development OU wins because it is enforced at a layer no Development-account principal can reach: it inherits to every account in the OU, constrains even member-account root users, and denies the CloudTrail actions at the API regardless of what IAM policies allow. The per-account IAM deny policy fails because administrators with iam:* can simply detach it. The permissions boundary fails for the same reason at a different layer: boundaries are per-identity objects managed inside the account, so an admin can strip them off. The Config rule is detective, not preventive; it tells you logging was disabled instead of stopping it, which does not satisfy a requirement that no one can perform the action.

1. Identify the requirement type: a restriction that must hold against administrators, not a grant of access.
2. Eliminate any control managed inside the member accounts (IAM policies, permissions boundaries), because admins with iam:* can modify or remove it.
3. Eliminate detective options (Config rules) because the requirement is prevention, not notification.
4. Choose an SCP attached at the OU level so it inherits to all Development accounts and binds every principal, including root.
5. Confirm the SCP uses an explicit deny for the specific CloudTrail actions, which overrides any allow anywhere.

Exam tip: When a restriction must bind administrators or root in member accounts, the answer is an SCP applied from the organization, never an IAM policy inside the account.

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

The SQS-plus-Auto-Scaling design wins on both stated requirements: SQS persists every job until a worker successfully processes and deletes it (no lost uploads), and a scaling policy driven by queue depth adds workers only while a backlog exists (cost-effective for unpredictable spikes). Peak provisioning is the classic anti-pattern the cost qualifier punishes: it keeps the fragile synchronous call path, has a hard ceiling, and bills for idle capacity every quiet hour. SNS looks similar but is push-based delivery without consumer pacing; an overwhelmed HTTP subscriber eventually exhausts retries and drops messages, so it cannot guarantee zero loss. The load balancer option redistributes the same synchronous load without adding any storage, so a fleet-wide saturation still times out and loses the job.

1. Diagnose the failure mode: synchronous calls into a saturated processing tier drop work during spikes, which is tight coupling.
2. Introduce a durable intermediary: an SQS queue holds each job until a worker finishes and deletes it, satisfying the no-loss requirement.
3. Scale the consumer on the right signal: a policy on queue backlog grows the worker Auto Scaling group during spikes and shrinks it after.
4. Apply the qualifier: pay-per-use elastic workers beat always-on peak capacity, so the queue-based design is the MOST cost-effective option that also works.

Exam tip: When spikes cause lost work between tiers, buffer with SQS and scale workers on queue depth instead of resizing the coupled tiers.

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 scenario explicitly places the IOPS demand within general purpose SSD range, so gp3 meets the requirement at the lowest cost among options that actually fit. io2 also works technically but is the classic overpriced distractor under a MOST cost-effective qualifier — you pay provisioned-IOPS prices for headroom the workload never uses. st1 fails on access pattern: HDD volumes sell sequential throughput and are poor at the random I/O a relational database generates. Instance store is the fastest storage available but is ephemeral, so it is disqualified for durable database files regardless of speed.

1. Classify the access pattern: a relational database generates small random reads and writes, which points to SSD, eliminating st1.
2. Check durability: database files must survive instance stops, eliminating ephemeral instance store.
3. Compare the stated requirement to the gp3 envelope: the scenario says the IOPS level fits within general purpose range.
4. Apply the qualifier: with gp3 sufficient, io2 is an overshoot on cost, so gp3 wins.

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.

An SCP never grants permissions. It defines the maximum permissions available to principals in the accounts it applies to, and effective access is the intersection of the SCP and the principal's IAM policies.

The user has no identity-based policy, so nothing has ever allowed the S3 actions; the request is implicitly denied regardless of how generous the SCP is. The SCP full of allows only means that if an IAM policy someday grants S3 actions, the SCP will not block them. The propagation-delay option is a fabricated mechanic and does not address the missing allow. The OU-attachment option is wrong because SCPs attach validly at the root, OU, or account level. The bucket-policy option inverts the within-account union rule: identity-based and resource-based policies each independently suffice to allow, so no bucket policy is required when an identity policy grants access.

1. Start from IAM's default: every request is implicitly denied until some policy explicitly allows it.
2. Check for an identity-based or resource-based allow for the user; here there is none.
3. Recognize that the SCP is a ceiling, not a grant: it filters allows but cannot create them.
4. Conclude the fix is attaching an identity-based policy allowing the needed S3 actions, which the SCP will then permit.

Exam tip: SCPs cap permissions; they never grant them — a principal with no IAM allow gets nothing no matter what the SCP permits.