AWS Security – Specialty (SCS-C03) — Free Sample Questions
Test your security expertise with 30 free sample questions for the AWS Certified Security Specialty exam. These questions cover real-world scenarios: incident response, encryption key management, network isolation, and compliance automation.
Exam Domains
- Threat Detection and Incident Response (14%) — GuardDuty findings, Security Hub, automated remediation, forensic isolation
- Security Logging and Monitoring (18%) — CloudTrail, VPC Flow Logs, DNS logs, centralized log architecture
- Infrastructure Security (20%) — WAF rules, Shield Advanced, Network Firewall, private endpoints, security groups vs. NACLs
- Identity and Access Management (16%) — cross-account roles, permission boundaries, session policies, ABAC
- Data Protection (18%) — KMS key policies, CMK vs. AWS-managed, envelope encryption, S3 Object Lock, Macie
- Management and Security Governance (14%) — Organizations SCPs, Config conformance packs, AWS Audit Manager
What Makes SCS-C03 Challenging
Security Specialty questions present complex scenarios involving multiple services and require you to identify the most secure AND operationally feasible solution. Common patterns:
- Choosing between KMS key types (symmetric, asymmetric, HMAC) for specific use cases
- Designing least-privilege policies that still permit required cross-account access
- Automating incident response with EventBridge → Lambda → SSM Automation
- Implementing encryption in transit and at rest across a multi-service architecture
Preparation Approach
- Master KMS: key policies, grants, key rotation, multi-Region keys
- Build a mental model of the GuardDuty → Security Hub → EventBridge → remediation pipeline
- Understand IAM in depth: policy evaluation logic, condition keys, permission boundaries
- Practice network security: WAF managed rules, Network Firewall rule groups, PrivateLink
Full Preparation
Continue with 600 SCS-C03 questions in 30 quizzes and 2 full-length practice exams with detailed explanations.
All 30 Free Sample Questions
Question 1
A security team needs to monitor all S3 buckets across 50 AWS accounts in an organization for sensitive data exposure. Which solution provides centralized detection with minimal operational overhead?
- Create Config rules in each account to check S3 bucket policies and aggregate results manually
- Enable Amazon Macie in the organization's delegated administrator account with member accounts added — Correct answer
- Use CloudWatch Events in each account to monitor S3 API calls and forward to a central account
- Deploy Lambda functions in each account to scan S3 buckets and send results to a central SNS topic
Explanation:
- Why correct: Amazon Macie can be enabled at the organization level with a delegated administrator account. This provides centralized management and automated sensitive data discovery across all member accounts' S3 buckets. Macie uses machine learning to identify PII, credentials, and other sensitive data with minimal configuration.
- Why A is wrong: AWS Config rules can evaluate bucket-level settings (e.g., encryption, public access) but cannot scan the actual contents of S3 objects for sensitive data such as PII or credentials. Config checks resource configuration, not data classification.
- Why C is wrong: CloudWatch Events can monitor S3 API calls (e.g., PutObject, GetObject) but does not analyze the contents of objects for sensitive data. Building content-inspection logic on top of CloudWatch Events would require significant custom development.
- Why D is wrong: Lambda-based scanning requires writing and maintaining custom data classification code, managing invocations at scale across 50 accounts, and handling permissions and error handling. Macie provides all of this out of the box with no custom code.
Question 2
A security engineer needs to configure CloudWatch Logs agent on EC2 instances across multiple accounts to send application logs to a central logging account. What is the most secure approach for cross-account log delivery?
- Send logs to S3 first, then copy to central account
- Use CloudWatch Logs cross-account subscription filters
- Use IAM user credentials stored on each instance
- Configure CloudWatch Logs agent with an IAM role that assumes a role in the central logging account — Correct answer
Explanation:
- Why correct: The CloudWatch unified agent on EC2 instances can be configured with a `role_arn` that assumes a cross-account IAM role in the central logging account. This role grants write permissions to CloudWatch Logs in the central account. The agent uses temporary credentials obtained via STS AssumeRole, following AWS security best practices (no long-term credentials on instances).
- Why A is wrong: Sending logs to S3 first and then copying to the central account adds unnecessary complexity, latency, and storage cost. Direct delivery via IAM role assumption is more efficient and secure.
- Why B is wrong: CloudWatch Logs cross-account subscription filters are a valid mechanism for forwarding logs, but they require logs to first land in CloudWatch Logs in the source account before being forwarded. This means logs exist in two places, and the question asks about configuring the agent itself for cross-account delivery. Role assumption allows the agent to write directly to the central account.
- Why C is wrong: Storing IAM user access keys on EC2 instances is a security anti-pattern. Long-term credentials can be compromised, don't rotate automatically, and violate the principle of using IAM roles for EC2. IAM instance roles with temporary credentials are always preferred.
Question 3
A security team enabled both GuardDuty and Security Hub in the same AWS region. GuardDuty is generating findings visible in the GuardDuty console, but none of those findings appear in Security Hub. What is the most likely cause?
- The Security Hub service-linked role lacks permission to read GuardDuty findings
- GuardDuty findings must be exported to S3 before Security Hub can ingest them
- Security Hub and GuardDuty are deployed in different regions
- The GuardDuty integration has not been enabled in Security Hub — Correct answer
Explanation:
- Why correct (D): Even when both GuardDuty and Security Hub are enabled in the same account and region, the GuardDuty integration must be explicitly accepted within Security Hub under the Integrations page. Until the integration is enabled (or if it was previously disabled), Security Hub will not receive or display GuardDuty findings.
- Why A is wrong: Security Hub uses a service-linked role that automatically has the necessary permissions to receive findings from integrated services. No additional IAM configuration is needed once both services are enabled and the integration is accepted.
- Why B is wrong: GuardDuty publishes findings directly to Security Hub through a native service integration — no S3 export or intermediate storage is required. The integration uses AWS internal APIs to deliver findings in the AWS Security Finding Format (ASFF).
- Why C is wrong: The question states both services are in the same region. However, even if they were in different regions, findings would not flow between them—Security Hub aggregates findings on a per-region basis, and cross-region aggregation requires a separate finding aggregation configuration.
Question 4
An organization has enabled GuardDuty, Security Hub, and CloudTrail across 100 accounts. Security analysts need to query all security events for the past year using SQL. What is the most efficient architecture?
- Send all logs to OpenSearch Service
- Use CloudWatch Logs Insights across all accounts
- Store logs in RDS for SQL queries
- Use CloudTrail Lake for CloudTrail events and Security Lake for GuardDuty/Security Hub findings — Correct answer
- Export all logs to S3 and use Athena
Explanation:
- Why D is correct: CloudTrail Lake is a managed, immutable, SQL-queryable event data store purpose-built for CloudTrail events, supporting up to 7 years of retention with no need to manage S3 buckets or partitions. Security Lake aggregates findings from GuardDuty, Security Hub, and other AWS and third-party sources, normalizes them to OCSF (Open Cybersecurity Schema Framework), and stores them in S3 where Athena can query with SQL. Together they cover all three event sources (CloudTrail, GuardDuty, Security Hub) with native SQL and optimized multi-account aggregation.
- Why A is wrong: OpenSearch Service uses its own query DSL (not SQL by default) and requires building custom ingestion pipelines, index management, and cluster sizing. For a pure SQL requirement across 100 accounts, purpose-built services like CloudTrail Lake and Security Lake are operationally simpler.
- Why B is wrong: CloudWatch Logs Insights supports a proprietary query syntax (not standard SQL) and is optimized for near-real-time operational troubleshooting. Retaining a full year of security events in CloudWatch Logs across 100 accounts would be significantly more expensive than CloudTrail Lake or Security Lake backed by S3.
- Why C is wrong: RDS is a relational database designed for transactional workloads. It lacks native log ingestion, would require custom ETL pipelines, and is not cost-effective or scalable for petabyte-scale security log querying.
- Why E is wrong: Exporting all logs to S3 and querying with Athena is viable but requires manual effort to set up and maintain partitioning, table definitions, and separate S3 delivery for each source. CloudTrail Lake and Security Lake handle ingestion, normalization, and partitioning automatically, making them more efficient for this use case.
Question 5
A company hosts a customer-facing application behind an Application Load Balancer and CloudFront. After a recent volumetric DDoS attack caused unexpected Auto Scaling costs and the security team struggled to mitigate the attack without AWS expertise, management asks the security engineer to improve their DDoS incident preparedness. Which action BEST addresses both concerns?
- Enable AWS WAF on CloudFront with a rate-based rule to throttle requests during attacks
- Subscribe to AWS Shield Advanced for DRT access during incidents and DDoS cost protection — Correct answer
- Configure CloudWatch Alarms on ALB request metrics to notify the team when traffic spikes
- Deploy a Network Firewall in front of the ALB to inspect and drop malicious packets
Explanation:
- Why correct: AWS Shield Advanced directly addresses both stated concerns. It provides 24/7 access to the AWS DDoS Response Team (DRT), who can assist during active attacks — solving the lack of AWS expertise. It also provides DDoS cost protection, which credits back scaling charges (such as Auto Scaling, CloudFront, or ALB) incurred during a DDoS event — solving the unexpected cost problem. Shield Advanced also adds near-real-time attack visibility and health-based detection for protected resources.
- Why A is wrong: AWS WAF with rate-based rules can help mitigate application-layer (Layer 7) DDoS traffic, but it does not provide expert incident response assistance from AWS during an attack, nor does it offer cost protection for scaling charges caused by volumetric attacks. It addresses only part of the problem.
- Why C is wrong: CloudWatch Alarms provide detection and notification but offer no mitigation capability, no expert support, and no cost protection. Alerting the team is useful but does not address the core issues of lacking expertise and absorbing scaling costs.
- Why D is wrong: AWS Network Firewall inspects traffic at Layers 3-7 within a VPC, but it is positioned behind CloudFront, not in front of it. It does not provide DDoS cost protection or access to the DRT. It also adds infrastructure cost and operational complexity without addressing the two specific concerns raised.
Question 6
A security analyst is investigating a GuardDuty finding that flagged an EC2 instance for communicating with a known command-and-control server. The analyst needs to understand the sequence of events that led to the compromise, including which IAM principal launched the instance, what API calls were made, and how network traffic patterns changed. Which approach provides the MOST efficient root cause analysis?
- Use Amazon Detective to examine the finding group and behavior graph for the affected resources — Correct answer
- Query each individual CloudTrail, VPC Flow Log, and GuardDuty data source separately using Athena
- Review the instance's associated S3 bucket policies to determine how it was compromised
- Create a CloudWatch dashboard showing the instance's CPU utilization metrics
Explanation:
- Why correct: Amazon Detective finding groups cluster related GuardDuty findings and automatically correlate them with associated CloudTrail API calls, VPC Flow Logs, and resource interactions in a behavior graph. This lets the analyst trace the full chain of events — from the IAM principal that launched the instance, through the API calls made, to the C2 communication — in a single consolidated view, rather than manually querying multiple log sources.
- Why B is wrong: Querying each data source separately in Athena requires writing custom queries, manually joining results across different log schemas, and building the correlation logic yourself. While technically possible, it is significantly slower and more error-prone than Detective's automated correlation, making it inefficient for root cause analysis.
- Why C is wrong: S3 bucket policies define access permissions for S3 resources. They have no relevance to determining how an EC2 instance was compromised or what sequence of events led to C2 communication.
- Why D is wrong: CloudWatch CPU utilization metrics show resource performance data, not security-relevant events. High CPU could be a symptom of compromise (e.g., cryptomining), but metrics alone cannot reveal the root cause, the attacker's actions, or the sequence of events.
Question 7
A security engineer confirms that an IAM role has been compromised and is being used to make unauthorized API calls including S3 data access and new EC2 instance launches. The engineer has already detected and verified the compromise. What should be the NEXT step?
- Contain the blast radius by revoking the role's active sessions and attaching a deny-all inline policy, then proceed to eradication — Correct answer
- Immediately delete the compromised IAM role and all resources it provisioned during the compromise
- Begin eradication by rotating all credentials across every IAM principal in the account before containing the compromised role
- Proceed directly to recovery by restoring affected S3 objects from versioned backups while the compromised role remains active
Explanation:
- Why correct: After detection and confirmation, the next phase in the incident response lifecycle is containment. Revoking active sessions (using an inline deny policy with an aws:TokenIssueTime condition) invalidates the role's existing temporary credentials, while a deny-all policy prevents new API actions. This contains the blast radius without destroying evidence needed for root cause analysis, and follows the proper sequence: Detection → Containment → Eradication → Recovery → Lessons Learned.
- Why B is wrong: Deleting the IAM role destroys forensic evidence (inline policies, trust relationships, last-used data) needed for root cause analysis. Containment should restrict access without eliminating the principal. Additionally, deleting the role does not revoke already-issued temporary credentials — they remain valid until they expire.
- Why C is wrong: Rotating all credentials account-wide is an eradication step, not containment. Jumping directly to eradication before containment risks the attacker pivoting to other principals while the broad rotation is still in progress. Containment must come first to stop the active threat.
- Why D is wrong: Recovering resources while the compromised role remains active allows the attacker to re-compromise or further exfiltrate restored data. The incident response lifecycle requires containment and eradication before recovery to prevent reinfection.
Question 8
A financial services company is required by trade compliance regulations to prevent users in certain sanctioned countries from accessing their CloudFront-distributed web application. The solution must block requests at the edge before they reach the origin. What is the MOST appropriate CloudFront feature?
- VPC routing tables
- CloudFront geographic restrictions (geo-blocking) — Correct answer
- IAM policies
- Security groups
Explanation:
- Why correct: CloudFront geographic restrictions (geo-blocking) allow you to configure a whitelist or blacklist of countries. Requests originating from blocked countries receive an HTTP 403 (Forbidden) response at the edge before reaching the origin. This enforces data sovereignty and trade compliance requirements directly at the CloudFront edge locations, which is the earliest possible enforcement point for geographic restrictions.
- Why A is wrong: VPC routing tables control network traffic routing within and between VPCs and subnets. They operate at the network layer within the AWS infrastructure and have no visibility into the geographic origin of internet requests arriving at CloudFront edge locations.
- Why C is wrong: IAM policies control access to AWS APIs and resources (for example, who can modify the CloudFront distribution). They do not filter end-user HTTP requests based on geographic origin.
- Why D is wrong: Security groups are stateful firewalls attached to ENIs (such as EC2 instances or ALBs) within a VPC. They filter traffic by IP address and port but operate at the origin level, not at the CloudFront edge, and cannot determine the geographic origin of a request.
Question 9
A company deploys containerized microservices to Amazon ECS. The security team requires all container images in Amazon ECR to be scanned for known vulnerabilities, with continuous monitoring that rescans images as new CVEs are published. Which TWO scanning options should they evaluate? (Select TWO)
- ECR basic scanning, which uses the open-source Clair engine to scan for CVEs when images are pushed — Correct answer
- Amazon Macie integration, which inspects container image layers for embedded sensitive data
- ECR enhanced scanning, which integrates with Amazon Inspector for continuous vulnerability monitoring — Correct answer
- AWS Config rules that automatically scan container image layers for package vulnerabilities
- Amazon GuardDuty container image scanning, which performs static analysis of ECR images at rest
- AWS Trusted Advisor checks that evaluate container image security configurations
Explanation:
- Why correct: Amazon ECR provides two native scanning options. ECR basic scanning uses the open-source Clair engine to perform CVE scans when images are pushed to the repository. ECR enhanced scanning integrates with Amazon Inspector for continuous, automated vulnerability monitoring — it rescans images when new CVEs are published, not just on push. Enhanced scanning provides richer findings including CVSS scores and remediation guidance.
- Why B is wrong: Amazon Macie discovers and classifies sensitive data in Amazon S3 buckets (such as PII, financial data, and credentials). It does not inspect container image layers or integrate with ECR for vulnerability scanning.
- Why D is wrong: AWS Config evaluates AWS resource configurations against desired settings (e.g., whether ECR scanning is enabled). It does not perform the actual vulnerability scanning of container image contents.
- Why E is wrong: Amazon GuardDuty monitors runtime threats (VPC Flow Logs, DNS logs, CloudTrail events, and runtime activity). It does not perform static analysis of container images stored in ECR. GuardDuty Runtime Monitoring detects threats in running containers, not in stored images.
- Why F is wrong: AWS Trusted Advisor provides account-level recommendations across cost, performance, security, and fault tolerance categories. It does not scan individual container images for software vulnerabilities.
Question 10
A security engineer is troubleshooting connectivity issues for an application running in a VPC. The application can initiate outbound HTTPS connections but external clients cannot reach it on port 443, despite an inbound allow rule in the security group. The engineer suspects a NACL issue. Understanding the differences between security groups and NACLs is critical. What are the key differences? (Select THREE)
- Security groups are stateful; NACLs are stateless — Correct answer
- Both are stateless and require explicit return traffic rules
- Security groups operate at the ENI level; NACLs operate at the subnet level — Correct answer
- Security groups support allow rules only; NACLs support both allow and deny rules — Correct answer
- Security groups are applied per subnet and NACLs are applied per instance, giving NACLs more granular control
- Both enforce rules identically but security groups apply to EC2 and NACLs apply to Lambda
Explanation:
- Why A is correct: Security groups are stateful — if inbound traffic is allowed, the return traffic is automatically permitted regardless of outbound rules. NACLs are stateless — both inbound and outbound rules must explicitly allow traffic, including return traffic on ephemeral ports.
- Why C is correct: Security groups are attached to Elastic Network Interfaces (ENIs), controlling traffic at the instance/resource level. NACLs are associated with subnets and evaluate all traffic entering or leaving the subnet.
- Why D is correct: Security groups can only specify allow rules (all traffic is denied by default). NACLs support both allow and deny rules with numbered priority ordering, which is useful for explicitly blocking specific IP ranges.
- Why B is wrong: Security groups are stateful, not stateless. Only NACLs are stateless and require explicit rules for return traffic.
- Why E is wrong: This reverses the actual scope of each control. Security groups are applied at the ENI (instance/resource) level, providing more granular control. NACLs are applied at the subnet level, affecting all resources in the subnet. This is a common misconception that confuses which control operates at which layer.
- Why F is wrong: Both security groups and NACLs operate on network traffic regardless of compute service. Lambda functions in a VPC are also subject to security groups and NACLs.
Question 11
A company deploys EC2 instances across multiple accounts using AWS CloudFormation. The security team must continuously verify that all deployed instances meet security requirements, including the absence of known vulnerabilities and the correct network exposure posture. Which TWO services should the team use together to achieve this? (Select TWO)
- Amazon Inspector for vulnerability and network reachability assessment — Correct answer
- AWS CloudTrail for API activity logging
- Amazon GuardDuty for threat detection
- AWS Trusted Advisor for general best-practice checks
- AWS Systems Manager Inventory for instance metadata collection
- AWS Config rules for continuous configuration compliance monitoring — Correct answer
Explanation:
- Why correct: (A) Amazon Inspector continuously scans EC2 instances for known software vulnerabilities (CVEs) and evaluates network reachability to identify unintended exposure such as ports accessible from the internet. (F) AWS Config rules continuously monitor resource configurations against defined baselines — for example, verifying that security groups do not allow unrestricted ingress or that instances use approved AMIs. Together, Inspector provides vulnerability and network exposure assessment while Config provides configuration compliance monitoring.
- Why B is wrong: AWS CloudTrail records API calls for auditing who changed what and when. It does not assess whether current resource configurations comply with security requirements or scan for vulnerabilities.
- Why C is wrong: Amazon GuardDuty detects active threats (reconnaissance, compromised instances, malicious IP communication) by analyzing flow logs and DNS queries. It does not validate that infrastructure configurations match security baselines or scan for software vulnerabilities.
- Why D is wrong: AWS Trusted Advisor checks for cost optimization, performance, fault tolerance, and some basic security best practices (e.g., open security groups, MFA on root). It does not provide continuous compliance monitoring or vulnerability scanning at the depth Inspector and Config provide.
- Why E is wrong: AWS Systems Manager Inventory collects metadata about instances (installed applications, OS versions, network configuration) but does not evaluate compliance against security requirements or scan for CVEs. It is a data-collection tool, not a validation tool.
Question 12
A financial services company must comply with a policy requiring IAM access keys to be rotated every 90 days. The security team wants an automated solution that identifies stale keys, creates replacements, and deactivates old keys without manual intervention. Which approach meets these requirements with the LEAST operational overhead?
- Use an AWS Config managed rule to detect keys older than 90 days and send SNS notifications for manual rotation
- Generate an IAM credential report monthly and email it to team leads for manual review and action
- Store the access keys in AWS Secrets Manager and enable automatic rotation with a managed rotation schedule
- Deploy a Lambda function triggered by an Amazon EventBridge scheduled rule to identify keys older than 90 days, create new keys, update dependent services, and deactivate old keys — Correct answer
Explanation:
- Why correct: A Lambda function triggered on a schedule by Amazon EventBridge can use IAM APIs to list access keys, check their age, create replacement keys, update dependent services, and deactivate old keys. This provides fully automated, end-to-end rotation without manual intervention.
- Why A is wrong: AWS Config can detect non-compliant keys using the access-keys-rotated managed rule, but it only identifies violations and sends notifications. It does not perform the actual key rotation, so manual action is still required.
- Why B is wrong: Generating a credential report and emailing it is a detective control that still requires manual rotation. It does not meet the requirement of automating key rotation without manual intervention.
- Why C is wrong: AWS Secrets Manager supports automatic rotation for secrets such as database credentials, but it does not natively support automatic rotation of IAM user access keys. A custom Lambda function would still be needed.
Question 13
After a company merger, the security team inherits 50 AWS accounts with unknown access configurations. They need to quickly identify two things: (1) which S3 buckets, IAM roles, and KMS keys are shared with external accounts, and (2) which IAM roles have permissions that have not been used in over 90 days. Which two IAM Access Analyzer capabilities address these requirements? (Select TWO)
- Unused access analysis to identify permissions granted but not exercised within a specified period — Correct answer
- AWS CloudTrail log aggregation and real-time alerting for API call anomalies
- VPC Flow Log analysis to detect unauthorized network access patterns
- AWS Config conformance pack evaluation for CIS benchmark compliance
- External access findings to identify resources accessible from outside the account or organization — Correct answer
- Amazon GuardDuty threat intelligence feeds for compromised credential detection
Explanation:
- Why correct (A and E): IAM Access Analyzer provides two distinct analysis capabilities. External access findings use automated reasoning to identify resources (S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues, Secrets Manager secrets) that are accessible from outside the account or organization—directly addressing requirement (1). Unused access analysis examines CloudTrail logs over a configurable period (up to 180 days) to identify permissions, roles, and access keys that are granted but never exercised—addressing requirement (2). Together, these capabilities enable the security team to rapidly assess the inherited accounts for over-permissive and externally exposed access.
- Why B is wrong: CloudTrail records API calls but does not natively aggregate and analyze permission findings the way IAM Access Analyzer does. CloudTrail is a data source that Access Analyzer consumes, not a replacement for its analysis capabilities.
- Why C is wrong: VPC Flow Logs capture network-level traffic metadata (source/destination IPs, ports, protocol). They do not analyze IAM permissions or identify externally shared resources.
- Why D is wrong: AWS Config conformance packs evaluate resource configuration compliance against rule sets (like CIS benchmarks), but they do not perform IAM permission analysis for unused access or external sharing at the depth that Access Analyzer provides.
- Why F is wrong: Amazon GuardDuty detects threats such as compromised credentials and anomalous behavior, but it does not analyze IAM permission grants or identify resources shared with external accounts.
Question 14
A financial services company must grant external auditors time-limited, read-only access to resources across three AWS accounts. Corporate policy requires MFA for all external access, and auditors must not be able to exceed the intended read-only scope even if the IAM role's identity policy is later misconfigured. What three components are required? (Select THREE)
- An IAM role in each target account with a trust policy that includes a condition for aws:MultiFactorAuthPresent — Correct answer
- Auditors use STS AssumeRole with a short DurationSeconds value and provide an MFA token code — Correct answer
- Root account credentials shared with auditors under a non-disclosure agreement
- A permission boundary attached to each auditor role that caps allowed actions to read-only operations — Correct answer
- Permanent IAM users with read-only policies created directly in each target account
- A single cross-account role with no MFA condition and the maximum 12-hour session duration
Explanation:
- Why A is correct: The IAM role trust policy must include a Condition block requiring aws:MultiFactorAuthPresent: true. This ensures only MFA-authenticated principals can assume the role, meeting the corporate MFA requirement for external access.
- Why B is correct: Auditors call STS AssumeRole with SerialNumber and TokenCode parameters to satisfy the MFA condition. Setting a short DurationSeconds (e.g., 1 hour instead of the maximum 12 hours) limits the credential validity window, providing time-limited access as required.
- Why D is correct: Permission boundaries set the maximum permissions a role can grant, regardless of what identity policies are attached. Even if someone later misconfigures the role's policy to allow write actions, the permission boundary caps it at read-only. This provides defense-in-depth against configuration drift.
- Why C is wrong: Root account credentials should never be shared. Root accounts cannot be scoped to read-only access and bypass most IAM controls including permission boundaries. This violates AWS security best practices and the principle of least privilege.
- Why E is wrong: Permanent IAM users are long-lived credentials, not time-limited access. They require credential rotation management, do not leverage STS temporary credentials, and create ongoing access that persists after the audit engagement ends.
- Why F is wrong: A 12-hour session with no MFA condition directly violates both requirements: MFA enforcement and minimized credential exposure. Maximum session duration increases the blast radius if credentials are compromised.
Question 15
A company is replacing its traditional VPN with AWS Verified Access to implement a zero-trust model for internal web applications. The security architect needs to understand which factors Verified Access evaluates before granting access to an application. Which THREE factors does Verified Access evaluate? (Select THREE)
- Network context and request metadata such as IP address and signing algorithm — Correct answer
- Only the source IP address without additional context
- Only static username and password credentials
- User identity verified through an external identity provider (IdP) such as IAM Identity Center or an OIDC provider — Correct answer
- Device security posture and compliance status from a device trust provider — Correct answer
- Physical proximity of the user to the nearest AWS Region
Explanation:
- Why correct (A, D, E): AWS Verified Access implements zero-trust principles by evaluating multiple signals before granting access. It verifies user identity through an external IdP (IAM Identity Center or OIDC-compatible providers), assesses device security posture from integrated trust providers (such as CrowdStrike, Jamf, or JumpCloud), and evaluates contextual data including network context and request metadata. Access is granted only when all policy conditions across these factors are satisfied.
- Why B is wrong: Verified Access goes far beyond source IP checks. A zero-trust model by definition does not trust based on network location alone. Verified Access evaluates identity, device posture, and context together — source IP may be one input but is never the sole evaluation factor.
- Why C is wrong: Static username/password authentication alone does not meet zero-trust requirements. Verified Access integrates with full-featured identity providers that support MFA and rich identity claims, not simple password-only authentication.
- Why F is wrong: AWS Verified Access does not evaluate the physical proximity of the user to an AWS Region. Trust decisions are based on identity verification, device compliance, and request context — not geographic distance to infrastructure.
Question 16
A media production company stores video project files on Amazon EFS. Editors actively work on projects for approximately two weeks, after which the files are rarely accessed but must remain available for at least one year. Storage costs are growing rapidly. The team wants to reduce costs without requiring application changes or manual file management. What should the security engineer recommend?
- Configure EFS Lifecycle Management to transition files to the EFS Infrequent Access storage class after 14 days — Correct answer
- Create a scheduled Lambda function that copies files from EFS to Amazon S3 Glacier after 14 days and deletes the EFS copies
- Increase the EFS throughput mode from bursting to provisioned to reduce the per-GB effective cost
- Create a second EFS file system using the One Zone storage class and migrate older files to it monthly
Explanation:
- Why correct: EFS Lifecycle Management automatically transitions files not accessed within a configured period (7, 14, 30, 60, or 90 days) to the EFS Infrequent Access (IA) storage class, which costs significantly less than EFS Standard. Files are transparently moved back to Standard on next access. This requires no application changes and no manual file management—matching all stated requirements.
- Why 'Lambda function copying to S3 Glacier' is wrong: While this could reduce storage costs, it moves files off EFS entirely. Applications expecting files on the EFS mount point would break, violating the requirement for no application changes. It also introduces operational complexity with a custom Lambda function to maintain.
- Why 'provisioned throughput mode' is wrong: Provisioned throughput provides consistent throughput independent of storage size, but it does not reduce storage costs. In fact, provisioned throughput adds an additional hourly charge on top of storage costs. It is a performance feature, not a cost-optimization feature.
- Why 'second EFS file system in One Zone' is wrong: One Zone storage reduces costs by storing data in a single Availability Zone, but migrating files between file systems would require application changes to reference new mount points and would need manual or scripted file management—violating both stated constraints.
Question 17
A company stores database credentials for an Amazon RDS PostgreSQL instance and a third-party payment API key in AWS Secrets Manager. The security team must implement automatic rotation for both. Which TWO rotation approaches should they use? (Select TWO)
- Use Secrets Manager managed rotation with a built-in Lambda template for the RDS PostgreSQL credentials — Correct answer
- Write a custom Lambda rotation function for the third-party API key that calls the vendor's key regeneration API — Correct answer
- Configure RDS to rotate its own database credentials independently of Secrets Manager
- Use AWS Systems Manager Parameter Store rotation for the third-party API key
- Store the third-party API key in KMS instead of Secrets Manager for automatic rotation
- Manually update both credentials on a monthly schedule using a cron job
Explanation:
- Why correct (A): Secrets Manager provides built-in managed rotation templates (Lambda functions) for supported databases including Amazon RDS, Amazon Aurora, Amazon DocumentDB, and Amazon Redshift. These templates handle the full credential rotation lifecycle automatically.
- Why correct (B): For secret types not natively supported (such as third-party API keys), Secrets Manager supports custom Lambda rotation functions where you implement the rotation logic yourself, including calling the external service's API to regenerate credentials.
- Why C is wrong: RDS does not rotate credentials independently. Database credential rotation must be orchestrated through Secrets Manager, which coordinates updating both the secret value and the database password atomically.
- Why D is wrong: Systems Manager Parameter Store does not provide native secret rotation capabilities. Secrets Manager is the AWS service purpose-built for automatic credential rotation.
- Why E is wrong: KMS manages encryption keys, not application credentials like API keys. KMS has its own key rotation mechanism but it does not rotate secrets stored as key-value pairs.
- Why F is wrong: Manual rotation via cron jobs is error-prone, lacks the atomic two-phase rotation that Secrets Manager provides, and does not integrate with IAM for secure credential retrieval.
Question 18
A company hosts a web application behind an Application Load Balancer (ALB). The security team requires that all traffic from clients to the ALB and from the ALB to backend EC2 instances is encrypted using TLS 1.2 or higher. Which TWO configurations are required to meet this requirement? (Select TWO)
- Configure the ALB HTTPS listener with an ELBSecurityPolicy-TLS13-1-2-2021-06 security policy — Correct answer
- Enable VPC Flow Logs to monitor encrypted traffic patterns
- Use security groups to restrict inbound traffic to port 443 only
- Configure the ALB target group to use HTTPS protocol with TLS-enabled backend instances — Correct answer
- Enable AWS WAF on the ALB with a managed rule group
- Enable ALB access logging to an S3 bucket
Explanation:
- Why A is correct: The ALB HTTPS listener with a TLS 1.2+ security policy (such as ELBSecurityPolicy-TLS13-1-2-2021-06) encrypts client-to-ALB traffic and enforces the minimum TLS version, rejecting connections from clients attempting older protocols.
- Why D is correct: Configuring the ALB target group to use HTTPS ensures the ALB establishes a new TLS connection to backend EC2 instances, encrypting ALB-to-backend traffic. Without this, the ALB forwards traffic to backends in plaintext even if the frontend listener uses HTTPS.
- Why B is wrong: VPC Flow Logs capture network metadata (source IP, destination IP, ports, bytes) but do not encrypt traffic or enforce TLS. They are a monitoring tool, not an encryption mechanism.
- Why C is wrong: Security groups restrict which IPs and ports can communicate but do not enforce encryption or TLS version. An application could accept unencrypted traffic on port 443 if misconfigured at the application layer.
- Why E is wrong: AWS WAF inspects HTTP requests for threats such as SQL injection and XSS. It does not enforce TLS encryption between the ALB and backend instances.
- Why F is wrong: Access logging records request metadata to S3 for auditing. It does not encrypt traffic or enforce TLS versions.
Question 19
An enterprise runs 80 AWS accounts under AWS Organizations. After a junior administrator accidentally closed a development account — causing a week of recovery effort — the cloud governance team needs a preventive control to stop unauthorized account closures while still allowing authorized ones. Which approach BEST prevents this from recurring?
- Create an IAM policy in each member account denying the organizations:CloseAccount action for all IAM principals
- Enable AWS CloudTrail to log account closure events and configure Amazon SNS alerts to notify the governance team
- Apply an SCP at the organization root that denies the organizations:CloseAccount action, with a condition exempting a specific governance IAM role in the management account — Correct answer
- Configure AWS Config rules to detect account closure attempts and trigger automatic remediation via Systems Manager
Explanation:
- Why correct: An SCP with a Deny effect on the organizations:CloseAccount action, applied at the organization root, prevents anyone in any member account — or even the management account unless explicitly exempted — from closing accounts. Adding a condition to exempt a specific governance role ensures the control doesn't block legitimate, authorized account closures. SCPs are preventive controls that are evaluated before IAM policies, making this approach reliable and tamper-proof from member accounts.
- Why A is wrong: IAM policies in member accounts cannot deny the organizations:CloseAccount action because account closure is performed via the Organizations API from the management account, not from within the member account itself. This approach doesn't address the correct attack surface.
- Why B is wrong: CloudTrail logging and SNS alerts are detective controls — they notify after the fact. The question asks for a preventive control. By the time the alert fires, the account may already be in the process of closing (accounts enter a 90-day suspended state).
- Why D is wrong: AWS Config rules are detective controls that evaluate compliance, not preventive controls that block actions. Config could detect a closed account but cannot prevent the closure from happening.
Question 20
A company with 200 AWS accounts in AWS Organizations needs centralized firewall management. The security team must ensure consistent WAF rules on all CloudFront distributions, Shield Advanced protection on critical resources, and uniform security group standards across all VPCs. Which THREE policy types does AWS Firewall Manager support to meet these requirements? (Select THREE)
- AWS WAF policies to deploy web ACLs across accounts and resources — Correct answer
- Security group audit and usage policies to enforce security group standards — Correct answer
- Amazon Inspector policies to schedule vulnerability scans across accounts
- AWS Config conformance pack policies to deploy compliance rules organization-wide
- AWS Shield Advanced policies to enable DDoS protection on specified resources — Correct answer
- VPC Network ACL policies to enforce subnet-level access controls
Explanation:
- Why correct: AWS Firewall Manager supports WAF policies (deploying and managing web ACLs on CloudFront, ALBs, and API Gateways across accounts), security group policies (auditing existing groups against baselines and enforcing common security group configurations across VPCs), and Shield Advanced policies (enabling DDoS protection on specified resource types across the organization). All three policy types are applied automatically to both existing and new resources.
- Why C is wrong: Amazon Inspector has its own organizational scanning capabilities managed through a delegated administrator account. Inspector is not managed through Firewall Manager policies.
- Why D is wrong: AWS Config conformance packs are deployed through AWS Config's own multi-account management or through CloudFormation StackSets. Firewall Manager manages firewall and security group policies, not Config rules.
- Why F is wrong: Firewall Manager does not manage VPC Network ACLs. Firewall Manager supports WAF, Shield Advanced, security groups, AWS Network Firewall, Route 53 Resolver DNS Firewall, and third-party firewall policies—but not NACLs.
Question 21
A company needs to ensure all EC2 instances have Systems Manager agent installed. What Config rule detects this?
- Only manual checks
- No detection capability
- ec2-instance-managed-by-systems-manager managed rule — Correct answer
- No Config rule available
Explanation:
- Why correct: Config managed rule "ec2-instance-managed-by-systems-manager" checks if instances are managed by Systems Manager (agent installed and reporting). Identifies non-compliant instances. Enables automated remediation. This ensures Systems Manager coverage.
- Why A is wrong: Config provides managed rule for Systems Manager agent.
- Why B is wrong: Config rule provides automated continuous checking.
- Why D is wrong: Config rule specifically detects Systems Manager agent status.
Question 22
A DevOps team deploys infrastructure using CloudFormation templates across 50 AWS accounts. Recent audits found templates that created S3 buckets without server-side encryption and security groups with overly permissive ingress rules. The team needs automated pre-deployment validation to catch these issues before templates reach production. Which TWO tools should they use? (Select TWO)
- AWS Trusted Advisor checks integrated into the deployment pipeline
- CloudFormation Guard with custom policy rules that enforce encryption and restrict security group ingress — Correct answer
- Amazon Inspector to scan CloudFormation templates for security vulnerabilities
- AWS Config rules to evaluate templates before deployment
- Manual peer review of all CloudFormation templates before each deployment
- cfn-lint with rules to validate template syntax, best practices, and resource property correctness — Correct answer
Explanation:
- Why correct (B, F): CloudFormation Guard (cfn-guard) is a policy-as-code tool that validates CloudFormation templates against custom rules before deployment. You can write rules such as 'all S3 buckets must have server-side encryption enabled' or 'no security group allows 0.0.0.0/0 ingress on port 22.' cfn-lint validates template syntax, resource property correctness, and best practices (e.g., detecting deprecated resource types or invalid property values). Together they catch both security policy violations (Guard) and template errors (cfn-lint) before any resources are deployed.
- Why A is wrong: AWS Trusted Advisor evaluates the state of deployed resources against best practices. It cannot validate CloudFormation templates before deployment—it only works with resources that already exist in your account.
- Why C is wrong: Amazon Inspector assesses running EC2 instances and container images for software vulnerabilities and network exposure. It does not analyze CloudFormation templates or IaC code.
- Why D is wrong: AWS Config evaluates the compliance of deployed resources against rules. Config rules run after resources are created, not before. It cannot inspect or reject templates prior to deployment.
- Why E is wrong: Manual peer review does not scale across 50 accounts with hundreds of templates. It is slow, error-prone, and cannot consistently catch all security misconfigurations.
Question 23
A security team uses CloudTrail Lake to investigate potential account compromise. They need to identify IAM users who made API calls from IP addresses never previously associated with the organization. Which CloudTrail Lake query approach is MOST effective?
- Create a CloudTrail Lake query that lists all API calls in the last 24 hours sorted by timestamp for manual review
- Write a SQL query that joins recent API activity against a baseline of known IP addresses, filtering for events from unrecognized source IPs grouped by user identity — Correct answer
- Export CloudTrail Lake data to S3 and use a Python script to parse the JSON logs for unknown IP addresses
- Use CloudTrail Lake's built-in anomaly detection feature to automatically flag unknown IP addresses
Explanation:
- Why correct (B): CloudTrail Lake supports SQL queries that can aggregate, filter, and join event data. You can query eventData to compare sourceIPAddress values against known baselines, group by userIdentity, and filter for unrecognized IPs. This leverages CloudTrail Lake's native SQL capability for targeted threat hunting.
- Why A is wrong: Listing all API calls sorted by timestamp provides raw data without analytical filtering, requiring manual review of potentially millions of events. This does not identify anomalous IP addresses.
- Why C is wrong: Exporting data to S3 and using external scripts adds unnecessary complexity. CloudTrail Lake's SQL engine can perform this analysis natively without data export.
- Why D is wrong: CloudTrail Lake does not have a built-in anomaly detection feature. It provides a SQL-based query engine; anomaly detection logic must be written as SQL queries or handled by other services like GuardDuty.
Question 24
A healthcare organization stores patient records across Amazon S3, Amazon EBS, and Amazon RDS. The CISO requires a ransomware resilience strategy that addresses detection, backup immutability, and automated response. Which THREE components should be included? (Select THREE)
- Enable Amazon GuardDuty with Malware Protection to detect ransomware activity on EC2 instances — Correct answer
- Configure AWS Backup Vault Lock in compliance mode with cross-account copy rules to an isolated backup account — Correct answer
- Deploy Amazon Inspector to continuously scan EC2 instances for software vulnerabilities
- Store all backup recovery points in the same AWS account as production to simplify access during recovery
- Enable AWS CloudTrail management events in the primary Region only
- Create an EventBridge rule that triggers a Step Functions workflow to automatically isolate compromised instances and capture forensic snapshots — Correct answer
Explanation:
- Why correct: Amazon GuardDuty with Malware Protection (A) provides agentless ransomware detection by scanning EBS volume replicas when suspicious activity is detected—this covers the detection pillar. AWS Backup Vault Lock in compliance mode (B) makes recovery points immutable so even a compromised administrator or root user cannot delete them—this covers backup immutability. An EventBridge rule triggering a Step Functions workflow (F) enables automated isolation and evidence capture without human intervention—this covers automated response. Together these three address all three pillars the CISO requires.
- Why C is wrong: Amazon Inspector scans for software vulnerabilities and unintended network exposure, which is useful for preventive patching but does not detect active ransomware, provide backup immutability, or automate incident response. It addresses vulnerability management, not the three pillars specified.
- Why D is wrong: Storing backups in the same account as production means that if the production account credentials are compromised (a common ransomware tactic), the attacker can also delete the backups. Cross-account isolation is a best practice for ransomware resilience.
- Why E is wrong: Enabling CloudTrail in only the primary Region leaves blind spots—an attacker could operate in other Regions without detection. Additionally, CloudTrail alone is a logging service, not a detection or response mechanism. It needs to feed into a detection service like GuardDuty or a SIEM to be actionable.
Question 25
A company's public-facing web application behind Amazon CloudFront is experiencing SQL injection attempts and cross-site scripting (XSS) attacks. The security team needs to implement protections quickly with minimal custom rule development. Which TWO actions should they take? (Select TWO)
- Associate an AWS WAF web ACL with the CloudFront distribution and enable the AWS Managed Rules Core Rule Set (CRS) — Correct answer
- Enable the AWS Managed Rules SQL Database rule group on the same web ACL — Correct answer
- Configure CloudFront to block all HTTP POST requests to prevent injection attacks
- Write custom AWS WAF regex rules to detect every known SQL injection pattern individually
- Enable CloudFront Origin Access Control to prevent injection attacks at the origin
- Deploy a self-managed web application firewall on Amazon EC2 instances behind CloudFront
Explanation:
- Why correct: The Core Rule Set (CRS) provides baseline protection against common web threats including XSS, local file inclusion, and path traversal. The SQL Database managed rule group specifically targets SQL injection patterns such as suspicious query strings and injection attempts. Both are AWS Managed Rules that can be enabled in minutes with no custom rule authoring, meeting the requirement for minimal development effort.
- Why C is wrong: Blocking all POST requests would break core application functionality (form submissions, API calls, login). SQL injection can also occur via GET parameters and headers, so this approach is both destructive and incomplete.
- Why D is wrong: Writing individual regex rules for every known SQL injection pattern is extremely labor-intensive and error-prone — the opposite of minimal custom development. AWS Managed Rules already cover these patterns and are maintained by AWS threat researchers.
- Why E is wrong: Origin Access Control restricts which entities can access the origin (e.g., S3 bucket), but it does not inspect request content for injection attacks. It solves a different problem (origin access restriction, not payload inspection).
- Why F is wrong: Deploying a self-managed WAF on EC2 adds significant operational overhead (patching, scaling, rule updates) and cost. AWS WAF natively integrates with CloudFront and is the operationally simpler choice.
Question 26
A company uses AWS CloudFormation to deploy infrastructure through a CI/CD pipeline. The security team wants to automatically prevent any template from deploying Amazon S3 buckets without server-side encryption or Amazon RDS instances without encryption at rest. The solution must be integrated into the pipeline and fail the build if non-compliant resources are detected. Which approach should the security engineer implement?
- Configure AWS Config rules for s3-bucket-server-side-encryption-enabled and rds-storage-encrypted, then use auto-remediation to enable encryption after resources are deployed
- Create an SCP in AWS Organizations that denies s3:CreateBucket and rds:CreateDBInstance when encryption parameters are not present in the API request
- Write CloudFormation Guard rules that check for encryption properties on S3 and RDS resources, and add a Guard validation step in the pipeline that fails the build on violations — Correct answer
- Use CloudFormation drift detection to identify S3 buckets and RDS instances that do not match the expected encrypted configuration after deployment
Explanation:
- Why correct (C): CloudFormation Guard is a policy-as-code tool that validates CloudFormation templates against custom rules before deployment. By writing Guard rules that require encryption properties on S3 and RDS resources and integrating 'cfn-guard validate' as a pipeline step, non-compliant templates are caught at build time before any resources are created. This is a preventive, shift-left control that maps directly to Skill 6.2.1.
- Why A is wrong: AWS Config rules evaluate resources after they are deployed (detective control). While Config can trigger auto-remediation to enable encryption, the resources exist in a non-compliant state temporarily. This does not fail the build pipeline or prevent the deployment, which is what the question requires.
- Why B is wrong: SCPs can enforce encryption conditions at the API layer using condition keys like aws:RequestTag, but they operate at runtime when the API call is made, not at the template validation stage during the build. SCPs also cannot inspect CloudFormation template contents. While SCPs are a valid guardrail, they do not provide build-time validation integrated into the CI/CD pipeline.
- Why D is wrong: CloudFormation drift detection compares the current state of deployed resources against the stack template to find out-of-band changes. It runs after deployment and cannot analyze templates for security misconfigurations before resources are created. It solves a different problem entirely.
Question 27
A company is migrating workloads to AWS and needs on-premises servers to resolve private hosted zone records in Route 53 (e.g., db.internal.example.com), while AWS workloads must resolve on-premises Active Directory DNS names (e.g., dc1.corp.local). Which configuration enables bidirectional DNS resolution across the hybrid environment?
- Configure Route 53 public hosted zones and allow on-premises DNS servers to query them over the public internet
- Deploy Route 53 Resolver inbound endpoints so on-premises DNS can forward queries to AWS, and outbound endpoints with forwarding rules so AWS can resolve on-premises domains — Correct answer
- Replace all on-premises DNS servers with Route 53 Resolver and migrate all zones to Route 53
- Configure VPC DHCP option sets to point all EC2 instances to the on-premises DNS servers only
Explanation:
- Why correct: Route 53 Resolver inbound endpoints create ENIs in the VPC that on-premises DNS servers can forward queries to, enabling them to resolve AWS private hosted zone records. Outbound endpoints allow Route 53 Resolver to forward queries matching specified domains (via forwarding rules) to on-premises DNS servers. Together they provide full bidirectional hybrid DNS resolution.
- Why A is wrong: Public hosted zones are publicly resolvable and would not resolve private hosted zone records (e.g., private DNS names). Private hosted zones require Resolver inbound endpoints for on-premises resolution.
- Why C is wrong: Replacing all on-premises DNS servers is operationally impractical and unnecessary. Active Directory relies on its own DNS for domain controller location (SRV records), and Route 53 cannot serve as an AD-integrated DNS server.
- Why D is wrong: Pointing all EC2 instances to on-premises DNS servers would only solve one direction (AWS → on-premises) and would bypass Route 53 private hosted zones entirely, breaking AWS-side private DNS resolution.
Question 28
A financial services company requires that AWS administrators can only perform privileged operations (such as modifying security groups and IAM policies) during business hours (8 AM to 6 PM UTC). This must be enforced centrally across all member accounts in the AWS Organization. Which approach enforces this time-based constraint?
- Add a Deny statement in an SCP with a condition using aws:CurrentTime to block requests outside the 08:00-18:00 UTC window, and attach it to the organization root — Correct answer
- Create a permissions boundary that removes all IAM actions after 6 PM UTC by setting the boundary policy's expiration timestamp
- Configure IAM Identity Center session duration to 10 hours starting at 8 AM UTC so sessions automatically expire at 6 PM
- Use aws:TokenIssueTime in an SCP condition to deny any STS token issued before 8 AM UTC
Explanation:
- Why correct (A): The aws:CurrentTime global condition key compares the date and time of each API request against specified values in ISO 8601 format. An SCP with a Deny statement using DateGreaterThan and DateLessThan conditions on aws:CurrentTime blocks privileged actions outside the 08:00-18:00 UTC window. Because this is an SCP attached at the organization root, it overrides any permissive identity-based policies in member accounts, enforcing the restriction centrally without modifying individual account policies.
- Why B is wrong: Permissions boundaries set the maximum permissions an IAM entity can have, but they are always active once attached — they do not support scheduling or time-based activation. Permissions boundaries are static IAM policies, not temporal controls. Time-based restrictions require condition keys within policy statements, not boundary-level configurations.
- Why C is wrong: IAM Identity Center session duration controls how long a session lasts once established (e.g., 1-12 hours from authentication), not when sessions can start. A 10-hour session starting at 8 AM is not how session duration works — it counts from whenever the user authenticates. Users could authenticate at midnight and still have a valid session.
- Why D is wrong: aws:TokenIssueTime records when an STS token was created, not when the current API request is made. A token issued at 8:01 AM could be used at midnight if its session hasn't expired. This condition restricts based on credential creation time, not request time, so it does not enforce business-hours restrictions on actual API calls.
Question 29
A security operations center manages automated incident response across 50 AWS accounts using AWS Organizations. When Security Hub aggregates a critical finding, an automated workflow creates a Systems Manager OpsItem and executes a remediation runbook. The SOC manager needs a single dashboard showing all open incidents, their current remediation status, affected resources, and which runbooks have executed. Which approach provides this centralized visibility with the LEAST operational overhead?
- Build a custom Amazon QuickSight dashboard that queries CloudTrail logs for Systems Manager Automation API calls and aggregates results by account
- Use Security Hub insights to filter findings by Workflow.Status and view remediation progress in the Security Hub console
- Use Systems Manager OpsCenter with OpsItems that track status, link related resources, record runbook execution history, and provide a cross-account timeline — Correct answer
- Create Amazon CloudWatch dashboards with custom metrics published from each account's remediation Lambda functions
Explanation:
- Why correct: Systems Manager OpsCenter is purpose-built for operational incident management. When Security Hub sends findings to OpsCenter, it automatically creates OpsItems that track status (Open, In Progress, Resolved), link to the affected AWS resources (EC2 instances, IAM users, security groups), record which Automation runbooks were executed and their outcomes, and maintain a chronological timeline of all actions taken. With AWS Organizations integration, OpsCenter provides a delegated-administrator view across all member accounts from a single pane of glass.
- Why A is wrong: Building a custom QuickSight dashboard by querying CloudTrail for SSM API calls would require significant custom development and only shows raw API call data. It does not provide structured incident status, resource linking, or runbook execution tracking. This is a build-it-yourself approach when a native purpose-built solution already exists.
- Why B is wrong: Security Hub's Workflow.Status field (NEW, NOTIFIED, SUPPRESSED, RESOLVED) tracks the lifecycle of individual findings, not the status of multi-step remediation workflows. It does not link to runbook executions, show which remediation actions were taken, or provide the operational incident timeline the SOC manager needs.
- Why D is wrong: CloudWatch dashboards with custom metrics could show counts of incidents per account, but metrics are numerical aggregates — they do not track individual incident status, link to affected resources, or show which runbooks executed against which findings. This approach requires extensive custom metric publishing logic and lacks the structured incident record OpsCenter provides natively.
Question 30
A company is migrating internal corporate web applications to AWS. Employees currently access these applications through a VPN. The CISO wants to adopt a zero-trust model where access decisions consider the user's identity from the corporate IdP, device security posture (OS patch level, antivirus status), and application-specific policies — without requiring a VPN client. Which solution meets these requirements with the LEAST operational overhead?
- Deploy an Application Load Balancer with OIDC authentication integrated with the corporate IdP, and restrict security groups to the corporate IP range
- Configure AWS Client VPN with certificate-based mutual authentication and integrate with the corporate IdP for user identity verification
- Configure AWS Verified Access with an OIDC-based trust provider connected to the corporate IdP, and define access policies that evaluate both user identity and device posture claims — Correct answer
- Deploy a reverse proxy on EC2 instances behind a Network Load Balancer with custom authentication middleware that validates IdP tokens and device certificates
Explanation:
- Why correct: AWS Verified Access is purpose-built for zero-trust application access without requiring a VPN. It integrates with OIDC/SAML identity providers for user identity and evaluates device posture through trust provider integrations (e.g., CrowdStrike, Jamf). Access policies written in Cedar enforce application-level conditions. As a fully managed service, it eliminates VPN infrastructure management, directly meeting the LEAST operational overhead requirement.
- Why A is wrong: ALB with OIDC authentication verifies user identity but cannot evaluate device security posture (patch level, antivirus status). Restricting security groups to corporate IP ranges reintroduces a perimeter-based model rather than true zero-trust — it trusts the network location instead of verifying each request independently.
- Why B is wrong: Client VPN requires a VPN client installed on employee devices, which contradicts the requirement to eliminate VPN dependency. VPN provides network-level access rather than application-level zero-trust, and does not natively evaluate device posture attributes like OS patch level or endpoint protection status.
- Why D is wrong: A custom reverse proxy on EC2 could functionally meet the requirements, but introduces significant operational overhead — patching, scaling, high availability configuration, and custom code maintenance. This directly contradicts the LEAST operational overhead constraint and is unnecessary when a managed service (Verified Access) exists.
JavaScript is required to use this application.
Please enable JavaScript in your browser to access the full NestedCerts platform.
Contact: support@nestedcerts.com