How security questions are built
Lesson 3 of 3 in The SCS-C03 Exam.
A specialty security item is built to defeat skimming. The architecture arrives first, the event or need second, and the requirement that decides the answer is usually in the last sentence — sometimes in five words of it. "A company runs a multi-account organization… GuardDuty reports… The security team must investigate the affected instance without granting standing administrative access." Everything before those last six words is scenery; those six words eliminate three options.
So read the stem backwards: question sentence first, then the body for the clauses that activate it. Four habits do most of the work.
Respect the qualifier. MOST, LEAST, and BEST are not decoration. The options are usually all feasible — the qualifier picks among feasible things. "MOST secure" votes for the narrower control; "LEAST operational overhead" votes for managed and automated; "MOST cost-effective" tolerates a little more operational work.
Default to least privilege. Between two options that both solve the problem, the exam takes the narrower one essentially every time: a scoped resource ARN over a wildcard, a condition key over a broader action, a short role session over an access key, a read-only role over an administrator.
Prefer managed and automated over hand-rolled. An EventBridge rule invoking a Systems Manager Automation document beats a cron job on an EC2 instance running a script. A Config rule with automatic remediation beats a weekly report someone reads. If one option is a custom Lambda reimplementation of a service that already exists, it is the distractor.
Treat "without changing the application" and "least operational overhead" as decisive. They are not softeners; they are filters. "Without changing the application" kills every answer that asks developers to adopt a new SDK, re-sign requests, or handle new credentials — and it is the reason answers land on ALB and CloudFront settings, VPC endpoints, Secrets Manager rotation with the existing cache, or TLS policy changes instead.
Which detection service does this question want?
Interactive decision tree — outcomes:
- Amazon Macie
Looks inside objects in Amazon S3 and tells you what the data is — PII, credentials, financial identifiers — with managed and custom data identifiers. It discovers and classifies; it does not block, redact, or remediate. "Discover", "classify", "sensitive data at rest" are its words.
- Amazon GuardDuty
Continuous threat detection from account and network telemetry — and the exam-critical detail: it analyses sources such as CloudTrail management events, VPC Flow Logs, and DNS logs without requiring you to enable and store those logs yourself. Runtime monitoring extends it into EC2, ECS, and EKS workloads. "Compromised credentials", "crypto-mining", "unusual API activity", "malware" land here.
- Amazon Inspector
Continuous vulnerability management: known CVEs in EC2 instances, container images in ECR, and Lambda functions, scanned automatically as inventory changes. It answers "what is unpatched", never "what is happening".
- Network Access Analyzer (or Inspector network reachability findings)
Reachability analysis finds network paths that exist — the open door nobody has walked through. The SCS-C03 exam guide names identifying unnecessary network access alongside Verified Access and Inspector network reachability findings. Reach for it when the stem says "identify unintended access" rather than "detect an attack".
- AWS Config
Records the configuration state of resources over time and evaluates them against rules, with automatic remediation and organization-wide conformance packs. "Was this bucket encrypted last Tuesday?" and "auto-fix any security group that opens 22 to the world" are Config questions.
- AWS Security Hub
The aggregation and standards layer: collects findings from GuardDuty, Inspector, Macie, Config, Access Analyzer and partners across every account through a delegated administrator, scores them against security standards, and prioritises. It mostly does not generate findings — "centrally aggregate", "single pane", "against standards" are its phrases.
- IAM Access Analyzer
Reasons about policies rather than traffic: which resources are shared outside your account or organization, whether a policy grants more than intended, which permissions a role actually used, and — with policy generation — a least-privilege policy derived from CloudTrail activity. "Unintended external access" and "right-size this role" point here.
- AWS CloudTrail
The record of API calls — identity, action, parameters, time, source IP. An organization trail that member accounts cannot stop, delivered to a locked archive account, is the standard answer to "we must be able to prove who did this". CloudTrail Lake adds managed, queryable retention. Remember the split: CloudTrail records calls, Config records state.
- Amazon Security Lake
A purpose-built security data lake that centralises logs from AWS services, on-premises systems, and third-party sources and normalises them into OCSF so one query crosses all of them. Reach for it when the requirement is long retention plus analysis across heterogeneous sources, often with Athena or OpenSearch Service on top.
- Amazon Detective
Takes a finding and builds the graph around it — which role, which instance, which IP, over what period — so you can establish scope, impact, and root cause. It comes after detection and aggregation, and the exam guide names it exactly where root cause analysis is asked for.
That tree exists because of the signature difficulty of this exam: the overlap trap. A well-written specialty item gives you two services that both work. Macie and GuardDuty will both "help with an S3 data exposure". Config and Security Hub will both "report non-compliant resources". A service control policy and an IAM policy will both "stop the developers deleting the trail". Only one fits the clause in the stem, and knowing the services is not enough — you have to know the deciding clause for each pair.
| The pair | Why both look right | The clause that decides it |
|---|---|---|
Macie vs GuardDuty | Both appear in any scenario about S3 and sensitive data. | What the data is → Macie (discover and classify PII at rest). What is happening to it → GuardDuty (anomalous access patterns, exfiltration behaviour). "Which buckets hold passport numbers" is Macie; "someone is downloading the bucket from Tor" is GuardDuty. |
Config vs Security Hub | Both say "non-compliant resources" and both run organization-wide. | One resource's configuration, history, and automatic remediation → Config. Findings from many services, scored against standards, aggregated across accounts in one view → Security Hub (delegated admin). If the answer must fix the resource, it is Config remediation; if it must report centrally, it is Security Hub. |
Inspector vs GuardDuty | Both "find security problems in compute". | Known vulnerability in software that is installed → Inspector (CVEs in instances, ECR images, Lambda). Behaviour at runtime → GuardDuty (including Runtime Monitoring for EC2, ECS, EKS). "Before deployment" or "unpatched" is Inspector; "is being used to" is GuardDuty. |
SCP vs IAM policy | Both deny the action in the scenario. | An SCP caps what principals in member accounts can do and never grants anything; it does not apply to the management account. An IAM policy grants and denies within one account. "Even an account administrator must not be able to…" and "across all accounts in the OU" are SCP phrases. If one identity needs the permission and another must not, it is an IAM policy. |
Secrets Manager vs Parameter Store | Both store a string encrypted with KMS and both integrate with IAM. | Built-in, scheduled rotation (with supported-database integration), cross-account access through a resource policy, replication to other Regions → Secrets Manager, at a price per secret. Free standard-tier configuration values, hierarchies, no managed rotation → Systems Manager Parameter Store. The word "rotate" decides it; the words "cost" and "configuration" push the other way. |
CloudTrail vs Config | Both are "the audit service". | CloudTrail records API calls — who did it. Config records configuration state — what it looked like. "Which principal changed it" is CloudTrail; "what was the setting at 14:00" is Config. Most real investigations use both, but exam items pick one. |
Detective vs Security Hub | Both sit downstream of findings. | Security Hub aggregates and prioritises many findings. Detective investigates one — graphing behaviour over time to produce scope and root cause. The phrase "root cause" is close to a guarantee that the answer is Detective. |
WAF vs Shield Advanced | Both are "the DDoS answer". | WAF inspects layer-7 requests — SQL injection, bad bots, rate limiting, geo rules, the OWASP Top 10. Shield Advanced adds enhanced DDoS protection, cost protection, and the response team, and it is not automatic — you subscribe and then protect specific resources. Application-logic attacks are WAF; volumetric attacks with a support requirement are Shield Advanced. |
Interactive sorting exercise: Drag each requirement phrase onto the service it implies. These are the exact phrasings the exam reuses.
“Without changing the application”
A hard filter, not a preference. It eliminates every option that requires new SDK calls, re-signed requests, a new credential-handling path, or a code deploy — and it is why the keys so often sit in the infrastructure instead: a TLS policy on the load balancer, a CloudFront behaviour or response header policy, a VPC endpoint so existing calls take a private path, an interface endpoint policy, Secrets Manager rotation that keeps the same secret name, a WAF rule in front of unchanged code.
“Least operational overhead”
Votes for whatever AWS runs for you: Fargate over managing instances, Systems Manager Patch Manager over a patching script, Config automatic remediation over a weekly review, Secrets Manager rotation over a rotation Lambda you wrote, Security Hub standards over a custom scoring job, Firewall Manager over configuring WAF per account, Control Tower controls over hand-written SCPs. Watch for the pairing with cost: if the stem says cost-effective and low overhead, the answer is usually serverless rather than "cheapest possible".
“Centrally” / “across all accounts” / “for the organization”
Switches the whole answer into the organization plane: an organization trail rather than a per-account trail, a delegated administrator for GuardDuty, Security Hub, Macie, Inspector, Detective and Access Analyzer rather than per-account enablement, SCPs and RCPs rather than IAM policies, Config aggregators and conformance packs rather than single-account rules, Firewall Manager rather than per-account WAF, CloudFormation StackSets rather than per-account stacks, RAM rather than copying resources. If an option would require someone to repeat work in every account, it loses.
“Immediately” / “in real time” vs “periodically”
Timing decides between services that otherwise match. Real-time or near-real-time wants an event-driven path — EventBridge on a finding, a Lambda or Systems Manager Automation triggered by it, GuardDuty rather than a scheduled scan, CloudWatch alarms and metric filters rather than a report. "Periodic", "quarterly", or "for the auditor" allows Audit Manager assessments, Config snapshots, Athena queries over archived logs, or Trusted Advisor reviews.
“MOST secure” vs “MOST cost-effective”
The same scenario flips answer on this one word. "MOST secure" takes customer managed KMS keys over AWS managed keys, CloudHSM over KMS when single-tenant FIPS 140-3 Level 3 custody is demanded, Object Lock in compliance mode over governance mode, private endpoints over public ones with IP conditions, and short sessions over convenient ones. "MOST cost-effective" tolerates AWS managed keys, Parameter Store instead of Secrets Manager, S3 lifecycle to cheaper tiers, and sampling instead of full logging — provided no stated requirement forbids it.
Key terms: Overlap trap, Requirement qualifier, Least privilege, Stem, Distractor