SCS-C03 Practice Set: Security Foundations and Governance
Security Foundations and Governance is a recurring theme in the AWS Security – Specialty (SCS-C03) exam. It carries about 14% of the exam score. The 5 questions below come with a full explanation of why each option is right or wrong.
AWS Security – Specialty (SCS-C03) · Security Foundations and Governance · 5 questions with answers and explanations
🧭 What these questions look for
Governance works at the organization level here: finding resources shared outside the organization, stopping vulnerable images before they reach a registry, keeping compliance evidence, weighing managed against custom guardrails, and removing root credentials from member accounts. Strong answers use a central, continuous mechanism. Watch for options that confuse AWS's own compliance reports with evidence about your own resources.
Tips for this set
• Ask where in the lifecycle a control acts. Scanning an image after it is pushed is not the same as failing the build before the image gets there.
• Managed Control Tower guardrails reduce upkeep but are fixed rules, while custom SCPs cover company-specific needs. Questions comparing them often expect a combination rather than one winner.
• External access analysis depends on the zone of trust you set, and centralized root access management lets rare root-only tasks run without keeping root credentials in member accounts.
📊 About this set
Exam: SCS-C03 · 65 questions · 170 minutes · passing score 750
This set: 3 applied, 2 advanced · 4 scenario, 1 trade-off
Topics: AWS IAM Access Analyzer, Amazon S3, AWS KMS, Amazon Inspector, AWS CodeBuild, Amazon ECR, AWS Config, AWS Control Tower, AWS Organizations, AWS STS
Question 1 of 5
A security engineer wants to identify any S3 buckets, IAM roles, KMS keys, or Lambda functions that grant access to principals outside the organization's AWS Organizations boundary, in order to review and remove unintended external trust relationships. Which AWS feature should they use?
Show answer
✅ Answer: B
Difficulty: applied · Topic: AWS IAM Access Analyzer, Amazon S3, AWS KMS
Zone of trust and external access
IAM Access Analyzer's external access analyzer reads resource-based policies and reports every resource that a principal outside a chosen zone of trust can reach. The zone of trust is either the current account or the whole AWS Organization.
• It uses automated reasoning over the policy logic, so it finds access granted through wildcards and conditions, not just literal account IDs.
• Supported resources include S3 buckets, IAM role trust policies, KMS keys, Lambda functions and layers, SQS queues, Secrets Manager secrets and several snapshot types.
• Each finding names the resource, the external principal (for example account 444455556666 or *) and the actions allowed.
Example
A role whose trust policy lets account 444455556666 call sts:AssumeRole produces a finding when that account is outside the organization. You then either archive it as intended or remove the trust statement, and the finding resolves on the next scan.
Why each option works or fails
• ✗ A. Trusted Advisor checks: its security checks cover a small, fixed set of items such as open S3 bucket permissions or exposed access keys; it does not analyze role trust policies, KMS key policies or Lambda resource policies against an organization boundary.
• ✓ B. Access Analyzer with an org or account zone of trust (correct): it is the feature built to list resources shared outside that boundary across S3, IAM roles, KMS keys and Lambda, which is exactly the review the engineer needs.
• ✗ C. Macie: Macie discovers sensitive data inside S3 objects and reports bucket-level exposure for S3 only; it does not evaluate IAM role trust relationships, KMS keys or Lambda permissions.
• ✗ D. Config aggregators: an aggregator only collects configuration and compliance data from many accounts and Regions into one view; without rules or queries it flags nothing, and it has no reasoning engine for external principals.
Question 2 of 5
A company builds container images in AWS CodeBuild and pushes them to Amazon ECR, where Amazon Inspector scans them. The security team now wants the build itself to fail when an image has critical vulnerabilities, before the image is ever pushed to a registry. Which approach fits?
Show answer
✅ Answer: B
Difficulty: applied · Topic: Amazon Inspector, AWS CodeBuild, Amazon ECR
Registry scanning versus pipeline scanning
Amazon Inspector scans images after they are in ECR (enhanced scanning, on push and continuously). That is valuable, but by then a vulnerable image already exists in the registry and could be pulled.
Amazon Inspector in CI/CD
Inspector also scans inside the pipeline:
• the Inspector SBOM Generator (inspector-sbomgen) builds a software bill of materials from a local image, directory or archive,
• the inspector-scan:ScanSbom API returns vulnerabilities with severities for that SBOM,
• plugins exist for Jenkins and TeamCity; in CodeBuild you call the tools from buildspec.yml.
Example
inspector-sbomgen container --image app:1.4 -o sbom.json, then aws inspector-scan scan-sbom --sbom file://sbom.json, and exit non-zero if any finding is CRITICAL, so the push step never runs.
Why each option works or fails
• ✗ A. Enhanced scanning on push: this scans only after the image is in the registry, which violates the requirement that vulnerable images never be pushed.
• ✓ B. Inspector SBOM scan in the build (correct): it evaluates the image before it is pushed and returns severities the build can act on, so a critical vulnerability stops the pipeline.
• ✗ C. Lifecycle expiration: lifecycle rules act on age or count, not on scan findings, and the image would already be in the registry.
• ✗ D. Lambda code scanning: that feature scans Lambda function code, not CodeBuild builds or the container images they produce.
Question 3 of 5
A company wants to continuously evaluate its own AWS resources against rule sets aligned to compliance frameworks such as PCI DSS, and keep the compliance history as evidence for its own audits. Which service fits?
Show answer
✅ Answer: C
Difficulty: applied · Topic: AWS Config
Automating audit evidence
Preparing for audits by taking screenshots is slow and error-prone. AWS Config records resource configurations and evaluates them against rules continuously. A conformance pack bundles many Config rules (and optional remediation actions) into one deployable unit.
• AWS publishes sample conformance pack templates aligned to frameworks such as PCI DSS, HIPAA, NIST 800-53 and the CIS AWS Foundations Benchmark, and you can write your own.
• Packs can be deployed across an organization from the management or delegated administrator account.
• Config keeps the compliance timeline of each resource, so you can show when it was compliant during the audit period.
Example: a PCI DSS conformance pack flags an unencrypted EBS volume the day it is created and shows the auditor when it was fixed.
Availability note: AWS Audit Manager, which mapped evidence to framework controls, has been closed to new customers since April 30, 2026; AWS points new users to Config conformance packs.
Why each option works or fails
• ✗ A. AWS Artifact: it provides AWS's own compliance reports and agreements, not evidence about the customer's environment.
• ✗ B. Amazon Detective: it builds a behavior graph from logs and findings to investigate security incidents, not to evaluate resources against compliance rules.
• ✓ C. Config conformance packs (correct): they continuously check the company's own resources against framework-aligned rule sets and keep the compliance history that serves as audit evidence.
• ✗ D. AWS Shield: it protects against DDoS attacks and has no compliance evaluation or evidence features.
Question 4 of 5
A security team is choosing between maintaining a large custom library of hand-written SCPs versus adopting AWS Control Tower's preventive and detective guardrails for baseline governance across 150 accounts. What is a key tradeoff they should weigh?
Show answer
✅ Answer: D
Difficulty: advanced · Topic: AWS Control Tower, AWS Organizations
Managed controls versus hand-written SCPs
AWS Control Tower controls are a library of preventive (SCP-based), detective (Config rule) and proactive (CloudFormation hook) rules that AWS writes, tests and updates, and that you turn on per OU from the console or API. They give fast, consistent coverage across many accounts and show compliance in one dashboard, but each control is fixed: you choose from what exists and cannot rewrite its logic.
Custom SCPs can express anything the SCP language allows, such as company-specific Region lists, tag rules or exceptions for break-glass roles. The price is that your team must write, test, version and update them as new services and actions appear.
They combine
Control Tower OUs are normal Organizations OUs, so you can attach your own SCPs alongside the ones Control Tower manages (within the SCP-per-target quota). A common approach: baseline with Control Tower controls, then add a few custom SCPs for gaps.
Why each option works or fails
• ✗ A. Cannot coexist: you can attach your own SCPs to Control Tower-managed OUs; you only avoid editing the SCPs Control Tower created, to prevent drift.
• ✗ B. Custom SCPs update themselves: it is the reverse; custom SCPs change only when your team edits them, while AWS maintains its managed controls.
• ✗ C. Custom SCPs never help: managed controls cannot cover every organization-specific rule, so custom SCPs are still needed for special requirements.
• ✓ D. AWS-maintained but opinionated, combine with custom SCPs (correct): this is the real tradeoff between lower maintenance and flexibility, and the two approaches work side by side.
Question 5 of 5
A security team wants to remove the root user credentials (password, access keys, MFA devices) from all member accounts in the organization. Occasionally a team locks itself out with a bucket policy that denies everyone, and the security team must then fix it as the root user of that account without keeping any long-term root credentials. Which approach meets the requirement?
Show answer
✅ Answer: A
Difficulty: advanced · Topic: AWS Organizations, AWS STS, Amazon S3
Centralized root access
AWS Organizations can manage root access for member accounts:
• Root credentials management lets the management account (or a delegated administrator) remove and audit member account root credentials. New accounts created afterward can be made without root credentials.
• Root sessions let those administrators call sts:AssumeRoot on a member account to get short-lived credentials that are limited to one privileged task. The AWS-managed root task policies include unlocking an S3 bucket policy (S3UnlockBucketPolicy), unlocking an SQS queue policy, and managing root credentials.
Why it fits
The team never holds a root password, MFA device or access key in the member accounts. The privileged action needed here is available as a scoped, logged, short session.
Why each option works or fails
• ✓ A. (correct): With centralized root access management, credentials are removed and the security team gets a short, single-task root session through AssumeRoot to remove the locking bucket policy.
• ✗ B. Role that overrides a deny: an explicit deny in a resource policy cannot be overridden by a role's allow, which is the reason the bucket was locked out in the first place.
• ✗ C. Vault of root credentials: this keeps long-term root credentials in every account, which is exactly what the requirement removes, and each account's root MFA would still need maintenance.
• ✗ D. SCP for the root user: an SCP cannot grant permissions to root, and recovery through the account email keeps the root password in use, so neither meets the requirement.
🎯 Key ideas from this set
• To find resources reachable from outside the account or organization, use IAM Access Analyzer's external access analyzer, not general best-practice or data-discovery tools.
• To stop vulnerable images before the registry, scan the SBOM in the pipeline with Inspector; ECR scanning happens after push.
• Continuous, framework-aligned compliance evidence about your own resources → Config conformance packs; AWS's reports come from Artifact.
• Control Tower controls cut maintenance but are fixed rules; custom SCPs fill company-specific gaps, and most organizations use both.
• Use centralized root access management and sts:AssumeRoot for the rare root-only tasks, so member accounts hold no long-term root credentials.
🔗 Keep practicing on this blog
• All SCS-C03 practice sets
• Every exam on this blog
📚 Keep studying SCS-C03
More SCS-C03 questions: https://hyunhp.github.io/cert-bank/#exam=SCS-C03
Study guide: https://hyunhp.github.io/cert-bank/study.html#exam=SCS-C03
These are original practice questions, not real exam questions, and cert-bank is not affiliated with any certification vendor.
Original practice questions written for this blog, not exam dumps.
Comments
Post a Comment