Question anatomy: finding the real requirement

Lesson 1 of 4 in Exam Readiness.

Every SCS-C03 item is the same machine. A setting (company, accounts, architecture), an event or need, zero to three constraints, and a question sentence carrying the qualifier. Then four or five options, of which several genuinely work.

The difference from an associate exam is where the decisive information hides. On a specialty security item the architecture paragraph is usually scenery, and the answer turns on a clause you can miss while skimming: "without granting standing access", "the application cannot be modified", "across all accounts", "even an administrator must not be able to", "no long-lived credentials". Train the habit: read the question sentence first, then re-read the body hunting for the clauses that activate it.

Then kill options in the order that costs least thought. First the factually impossible — in-place RDS encryption, an SCP that grants a permission, a root user overriding Object Lock in compliance mode. Then the over-privileged, because least privilege is the default bias. Then anything that changes the application when the stem forbade it, or works per account when the stem said organization-wide, or detects when the stem said ensure. What survives, you compare on the qualifier.

The dissection protocol — about twenty seconds, before you read any option closely

Read the question sentence first
The last sentence tells you what is being asked and how it will be judged. Reading it first turns the architecture paragraph from a puzzle into context.
Underline the qualifier and the constraints
MOST / LEAST / BEST, plus the hard filters: "without changing the application", "no long-lived credentials", "across all accounts", "must not be able to", "in real time", "least operational overhead".
Name the control plane
Identity, network, data, detection, or organization? Naming it halves the option list before you compare anything — a network answer to an identity question is already dead.
Kill impossible, over-privileged, and app-changing options
Three fast eliminations in order: can it even be done on AWS; does it grant more than asked; does it require a code change the stem forbade.
Does the ask name one control or several?
Pick the narrowest survivor that meets the qualifier
Between two working options, the exam takes the narrower, more managed, more central one — unless a clause in the stem explicitly overrides that.
Build a set from different layers
Multiple response, and especially "defense in depth": the correct set covers different layers and often cooperates — one control enables, the other scopes. Count the required answers off the stem and fill every slot.

Specimen A — cross-account read, and the clause that decides it

The item. A data-science team working in account B must read objects from a bucket in account A. Security requires that the access be auditable, revocable in one place, and that no long-lived credentials exist. Which solution meets the requirements with the LEAST operational overhead?

A. Create an IAM user in account A with an access key and give the key to the team. B. Create a role in account A whose trust policy trusts the team's role in account B, grant it s3:GetObject on the required prefix, and have the team assume it. C. Make the bucket public and restrict access by the team's office IP range. D. Copy the objects into a bucket in account B every night.

The dissection. The deciding clause is "no long-lived credentials exist" — it kills A outright, which is otherwise the simplest-sounding answer and the one a tired reader picks. C is the public-bucket trap: an IP condition is not an identity control, and "public" fails on contact with any security requirement. D works and is genuinely used in the real world, but it duplicates regulated data, doubles the surface to protect, and does not make the original access revocable in one place.

B is the key, and the exam expects you to know it has two halves: the trust policy on the role in account A and permission on the team's role in account B to call sts:AssumeRole. Cross-account access always needs permission on both sides — an item that offers you only one half is offering you a distractor.

Specimen B — “always encrypted” is a prevention word (Select TWO)

The item. A company must ensure that EBS volumes created anywhere in the organization are always encrypted. Select TWO actions that meet the requirement.

A. Enable EBS encryption by default in every account and Region. B. Attach an SCP to the organization root denying ec2:CreateVolume unless the request specifies encryption. C. Create an AWS Config rule that flags unencrypted volumes. D. Run a nightly Lambda function that encrypts any unencrypted volume in place. E. Create a CloudWatch alarm on CreateVolume API calls.

The dissection. "Must ensure… always" is prevention language, and "anywhere in the organization" puts the answer in the organization plane. A + B is the set, and notice how the two cooperate: the account setting makes encryption the default, and the SCP makes the opt-out impossible even for an account administrator who turns the default off.

C and E detect; the unencrypted volume already exists. D is the factual trap — you cannot encrypt an EBS volume in place; the supported route is a snapshot, an encrypted copy, and a restore. One wrong pick makes the whole item zero, which is why the exact-set grading punishes "C looks helpful too".

Specimen C — “the application must not be modified”

The item. A payment service on EC2 instances in private subnets calls AWS Secrets Manager and Amazon S3. To close an audit finding, network engineering has removed the NAT gateway, and the service has stopped working. The application must not be modified. What restores it while keeping traffic off the internet?

A. Create an interface VPC endpoint for Secrets Manager and a gateway VPC endpoint for Amazon S3. B. Re-create the NAT gateway and restrict outbound traffic with a security group. C. Move the instances to a public subnet and assign Elastic IP addresses. D. Route the calls through an internet-facing Application Load Balancer.

The dissection. A is the key, and the "must not be modified" clause is why: VPC endpoints change the path, not the call — the SDK keeps using the same service endpoint names. It also matters that you know which kind: S3 and DynamoDB use gateway endpoints; almost everything else, including Secrets Manager, uses interface endpoints powered by PrivateLink.

B restores function and re-opens exactly the internet path the audit finding was about. C and D both make a private workload public, which no "keep traffic off the internet" requirement can survive. Note the shape of this item: three options work, and only one works under the constraint.

Specimen D — an administrator who is denied

The item. A developer holding the AdministratorAccess managed policy in a member account cannot create an IAM user. CloudTrail shows AccessDenied, and the error indicates an explicit deny. What is the most likely cause?

A. A service control policy attached to the account's organizational unit denies iam:CreateUser. B. The developer's policy is missing the iam:CreateUser permission. C. Amazon GuardDuty blocked the action as suspicious. D. The account has reached its IAM user quota.

The dissection. Two words do all the work: administrator and explicit deny. AdministratorAccess already allows iam:CreateUser, so B is impossible — this is the single most common misread on IAM items, because "add the missing permission" is such a natural reflex. An explicit deny means a Deny statement was evaluated, and the candidates sit outside the identity policy: an SCP on the OU, an RCP, a permission boundary, a session policy, or a resource policy.

A is the key, and the exam's favourite follow-up is the caveat: had this been the management account, an SCP would not have applied at all. C is a category error — GuardDuty detects, it does not block API calls. D would return a quota error, not an access-denied explicit deny.

Those four specimens are not four unrelated puzzles. They are four instances of a small number of distractor families, and recognising the family is faster than reasoning each option out from first principles. Learn the table below well enough that an option announces its own family as you read it.

The distractor families, in rough order of how often they appear on a security specialty item.
Family	Why it looks right	The tell
Right service, wrong mode	The service genuinely owns this problem space.	Check the timing and the direction: a nightly job for a real-time need, a batch scan for a runtime threat, governance mode where the requirement said nobody may override.
Works, but over-privileged	It solves the functional problem cleanly and in one step.	A wildcard action or resource, an administrator policy, a role trusted by an entire account rather than a specific principal. Least privilege is the standing bias.
Works, but changes the application	Often the architecturally "proper" long-term answer.	The stem said "without changing the application" or "with no code changes". Then the key lives in infrastructure: endpoints, TLS policies, headers, rotation that keeps the same secret name.
Per account when the ask was organization-wide	It is the correct mechanism — at the wrong scope.	"Across all accounts", "centrally", "for the organization". The key is the central form: organization trail, delegated administrator, conformance pack, Firewall Manager, StackSets, RAM.
Detects when the ask was prevent	Detection is cheap, visible, and feels responsible.	"Ensure", "must not be able to", "prevent". A Config rule or an alarm is the wrong half of the taxonomy; the key is an SCP, an RCP, a deny, or a setting that removes the option.
Factually impossible	It reads like a feature that surely exists.	Memorise the short list: encrypting RDS or EBS in place, an SCP that grants, anyone (including root) shortening Object Lock compliance retention, IAM alone authorising a KMS key whose policy excludes it, immediate KMS key deletion.
Human where automation was asked for	Runbooks and reviews sound diligent.	"Automatically", "without manual intervention", "least operational overhead". The key is EventBridge plus Systems Manager Automation, Step Functions, Config remediation, or managed rotation.
Treats the symptom, or escalates to AWS	It makes the alert go away.	Deleting logs, suppressing findings, raising a quota, or "contact AWS Support" to fix something on your side of the responsibility line. Never the key.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.

Key terms: Stem, Distractor, Requirement qualifier, Overlap trap, Least privilege