AWS 1: Detection: 142 practice questions
48 hours only — 15% off every course with code SAVE15. Browse courses →48h · 15% off all courses · code SAVE15 →
Certifications Tools Flashcards Career Paths Exam Guides Blog Pricing For Teams About
Check readiness — free →

AWS 1: Detection: 142 practice questions

AWS 142 questions 12 shown free

12 of the 142 1: Detection questions in the Certsqill AWS bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS? Take the free 5-min readiness check →

1. Enable GuardDuty Runtime Monitoring for ECS on Fargate: Which design best satisfies these requirements?

Easy
A healthcare platform runs immutable Amazon ECS tasks on AWS Fargate and stores protected health information in Amazon S3. GuardDuty permissions and Fargate prerequisites are already configured. The security team requires runtime process and network visibility, S3 data classification, and centralized investigation of findings. New tasks must be covered automatically. Which design best satisfies these requirements?
  1. Enable GuardDuty Runtime Monitoring for ECS on Fargate, Macie automated discovery, and Security Hub aggregation. ✓
    GuardDuty Runtime Monitoring covers ECS on Fargate using its managed security-agent model, Macie classifies eligible S3 data, and Security Hub centralizes supported findings. Macie automated discovery samples rather than exhaustively scanning every object.
  2. Enable GuardDuty Runtime Monitoring for EKS, Macie automated discovery, and Security Hub aggregation across accounts and Regions.
    The workload is ECS on Fargate, not EKS. GuardDuty does not support EKS clusters running on Fargate, and this option selects the wrong runtime coverage.
  3. Enable Inspector for supported workloads, Macie automated discovery, and Security Hub aggregation across accounts.
    Inspector can assess supported software and workloads, but it does not provide Fargate runtime process and network visibility.
  4. Enable CloudTrail S3 data events, Inspector workload assessment, Macie automated discovery, and Security Hub aggregation across the organization.
    CloudTrail S3 data events record API activity, and Inspector assesses supported workloads; neither supplies process and network visibility inside Fargate tasks.
The trap
Confuses workload vulnerability assessment with runtime detection. Confuses ECS on Fargate with EKS on Fargate. Mistakes API auditing and vulnerability assessment for runtime telemetry.

Use GuardDuty Runtime Monitoring for ECS on Fargate, Macie for S3 classification, and Security Hub for centralized findings.

2. Create a grouped Metrics Insights alarm by InstanceId: Which design is best?

Easy
A multi-account analytics environment monitors Amazon EC2 instances in one AWS Region. Cross-account observability is already configured for the monitoring account, and CloudWatch Agent memory metrics are consistently published. Security engineers want one fleet-wide alert when any instance exceeds 80 percent memory utilization for two consecutive evaluation periods. Instances are created and terminated by Auto Scaling, and the alert must identify individual contributing instances without manually maintaining alarms. Which design is best?
  1. Create one alarm on the fleet's average CWAgent memory for two periods and notify operations when the average exceeds 80 percent.
    An average can conceal an overloaded instance and cannot identify individual contributors exceeding the threshold.
  2. Create a grouped Metrics Insights alarm by InstanceId at 80% for two periods. ✓
    A grouped multi-time-series alarm evaluates each instance separately, adapts as Auto Scaling changes membership, and identifies contributing instances.
  3. Create separate CWAgent memory alarms for every current instance, then add alarms manually whenever Auto Scaling launches another instance.
    Static per-instance alarms require ongoing maintenance and do not automatically cover changing Auto Scaling membership.
  4. Create an anomaly-detection alarm on the fleet's aggregate CWAgent memory, notify operations, and investigate instances manually after the aggregate alarm fires.
    An aggregate anomaly alarm does not enforce the specified 80-percent per-instance threshold or provide automatic contributor identity.
The trap
It assumes fleet membership remains static or manually manageable. It confuses aggregate monitoring with contributor-level monitoring. It replaces a defined per-instance threshold with aggregate anomaly detection.

Use a grouped Metrics Insights alarm to evaluate each instance dynamically and identify contributors.

3. Use Security Hub central configuration with separate: Which design best meets these requirements?

Medium
A financial services organization has 40 AWS accounts and operates in three enabled Regions. The security operations team needs centrally managed Security Hub standards and controls for existing and newly created production accounts, while development accounts require a different control policy. Production administrators must not override the settings. AWS Organizations and a delegated Security Hub administrator are already available. Which design best meets these requirements?
  1. Configure Security Hub separately in each account and Region, then ask administrators to copy the settings.
    Local configuration relies on account administrators and does not centrally prevent production drift or reliably cover new accounts and Regions.
  2. Use Security Hub central configuration with separate policies assigned to production and development OUs. ✓
    Central configuration applies different policies to OUs across the home and linked Regions, covers accounts assigned to those OUs, and prevents centrally managed production administrators from overriding settings.
  3. Use central configuration for all accounts, but designate production accounts as self-managed so administrators can adjust controls locally when needed.
    Self-managed production accounts can override local settings, contradicting the requirement for centrally enforced production configuration.
  4. Use central configuration with one policy for all accounts, including production and development.
    A single policy cannot provide the required different control settings for production and development accounts.
The trap
Treats procedural consistency as centralized enforcement. Overlooks the differentiated-policy requirement. Confuses central enablement with non-overridable management.

Security Hub central configuration supports OU-specific policies, linked Regions, new-account coverage, and prevention of production configuration drift.

4. Create a repository-dimensioned metric filter for failed: Select TWO actions.

Medium
A software delivery platform centralizes Standard-class application logs in CloudWatch Logs. Each deployment emits structured events containing repository, branch, and result fields. Security requires an alarm whenever failed deployments occur in any repository, and a dashboard must show failure counts by repository. The build fleet publishes CloudWatch Agent memory metrics and changes as instances are created or terminated. The platform also needs contributor-level notifications for memory saturation. An EventBridge rule can route Metrics Insights contributor state-change events to an SNS topic. Select TWO actions.

Select two. More than one option is correct — every correct one is ticked below.

  1. Create static memory alarms for every current instance, update that alarm set after fleet changes, and send their ordinary alarm notifications to the contributor notification topic.
    Static alarms require manual updates and do not automatically follow instances created or terminated after deployment.
  2. Create a repository-dimensioned metric filter for failed events and alarm on the resulting metric. ✓
    A metric filter on the Standard log group can publish repository-dimensioned failure metrics for alarms and dashboards.
  3. Schedule a CloudWatch Logs Insights query that groups deployment failures by repository and display its results on the dashboard.
    The query supports analysis and dashboard display but does not create the required metric alarm for newly ingested failures.
  4. Create one un-dimensioned failure metric and alarm on it, then use a separate Logs Insights query to reconstruct repository counts for the dashboard.
    The alarm can detect aggregate failures, but this design does not provide repository-dimensioned metrics for the required dashboard breakdown.
  5. Create a Metrics Insights alarm grouped by instance for CloudWatch Agent memory metrics, and route contributor state changes through the configured EventBridge rule to SNS. ✓
    A grouped multi-time-series alarm follows changing instance membership and emits contributor state-change events that the stated rule can notify through SNS.
The trap
Confuses log analysis with an alarm metric. Loses the required repository metric identity. Uses fixed alarms for a dynamic fleet and omits contributor events.

Use a repository-dimensioned log metric and a grouped Metrics Insights alarm with contributor-event routing.

5. Associate automatic SSM remediation with production Config: Which design is best?

Medium
An enterprise SaaS provider operates accounts in multiple AWS Regions. AWS Config is enabled in all target accounts and Regions, production resources are evaluated by a Config rule, and the target Regions support Config remediation. An approved maintenance window and downtime consent exist for replacing affected volumes. An approved custom SSM Automation document already snapshots, copies, encrypts, and replaces an affected volume, with its execution role configured. Automatic remediation must remain disabled in the sandbox OU. Which design is best?
  1. Associate automatic SSM remediation with production Config rules only. ✓
    The approved custom Automation document provides the auditable replacement workflow, while limiting the association to production leaves the sandbox OU disabled.
  2. Schedule a Lambda function to apply encryption in place to every detected production volume during maintenance windows.
    An existing EBS volume cannot be converted through a simple in-place encryption operation; replacement is required.
  3. Suppress production findings in Security Hub and document sandbox exceptions while leaving unencrypted volumes unchanged.
    Suppression manages findings but does not remediate unencrypted EBS volumes.
  4. Send Config events to SNS and require operators to create encrypted replacement volumes manually for production findings.
    SNS provides notification, but manual replacement is neither automatic nor the required repeatable Config remediation workflow.
The trap
Confuses finding management with corrective automation. Assumes EBS encryption can be applied directly to an existing volume. Mistakes notification and manual procedures for automatic remediation.

Associate automatic SSM remediation with production Config rules only.

6. Send VPC Flow Logs: Which design best satisfies the evidence requirements?

Medium
A media company investigates suspected data exfiltration from workloads in several VPCs. Investigators need source and destination network metadata, DNS names queried, and object-level access to a specific S3 bucket. They do not need packet payloads. Logs must be retained centrally, protected against deletion, and queryable by analysts. The company already operates a security account with an S3 bucket in compliance-mode Object Lock, and delivery permissions and analyst access are configured. Which design best satisfies the evidence requirements?
  1. Send VPC Flow Logs and CloudTrail management events to CloudWatch Logs with retention configured.
    This omits Resolver query logs and S3 object-level events, and does not use the immutable central S3 store.
  2. Send Resolver query logs and application logs to the locked bucket without enabling S3 data events.
    Without CloudTrail S3 data events, object-level bucket activity is not captured; application logs cannot supply it reliably.
  3. Send VPC Flow Logs, Resolver query logs, and CloudTrail S3 data events to the locked central S3 bucket. ✓
    These sources provide network metadata, DNS queries, and S3 object activity, while Object Lock protects retained objects from deletion.
  4. Enable packet capture, CloudTrail management events, and S3 access logging, then retain all outputs in the locked central bucket.
    This combination does not provide the specified supported set of VPC flow metadata, Resolver queries, and CloudTrail S3 data events.
The trap
It confuses management events with data events. It assumes downstream logs replace omitted AWS data-plane telemetry. It substitutes packet capture and management logs for service-specific evidence.

Use VPC Flow Logs, Resolver query logs, and CloudTrail S3 data events in the locked bucket.

7. Add an advanced selector for all S3 object data events: What change is required?

Medium
An organization uses AWS Organizations with a hybrid identity deployment. The security team found this CloudTrail configuration in the management account: a multi-Region organization trail logs management events, but the trail has no advanced event selector for S3 objects. A production role performed an unexpected GetObject operation, and the team needs future object-level evidence for S3 objects in every enabled Region and member account. The organization has already configured the destination S3 bucket policy and encryption permissions. What change is required? Exhibit: `Trail: org-audit | IsOrganizationTrail: true | IsMultiRegionTrail: true | DataEvents: none`
  1. Enable AWS Config recording for S3 buckets and supported bucket resources.
    AWS Config records supported resource configuration changes, not individual S3 object API operations such as GetObject.
  2. Add an advanced selector for all S3 object data events. ✓
    S3 object operations are data events and must be explicitly selected. Selecting the S3 object resource type on the existing multi-Region organization trail provides coverage for enabled Regions and member accounts.
  3. Enable CloudTrail Insights events on the existing organization trail.
    Insights detects unusual API-call rates or error patterns; it does not enable S3 object-level data-event logging.
  4. Add an advanced selector for Lambda Invoke data events.
    Lambda invocation data events are supported, but they do not record S3 GetObject operations.
The trap
Chooses a valid data-event type that does not meet the S3 evidence requirement. Confuses anomaly detection with data-event selection. Confuses configuration history with object API activity.

Select all required S3 object data events on the existing organization trail.

8. Create separate scoped Security Lake subscribers: Select TWO actions.

Medium
A centralized security operations team must retain normalized security events from AWS accounts, on-premises infrastructure, and a third-party firewall. The on-premises and firewall producers already emit the required OCSF records in Parquet and deliver them through configured Security Lake custom sources. Analysts require query access to selected Regions, while an incident-response SaaS tool needs notification when new objects arrive. Data must remain owned by the organization, use an open schema, and support configurable retention and replication. The team wants to minimize custom parsing and avoid granting the SaaS tool unrestricted bucket access. Select TWO actions.

Select two. More than one option is correct — every correct one is ticked below.

  1. Create separate scoped Security Lake subscribers: a query subscriber for analysts and a data-access subscriber for SaaS object notifications. ✓
    Security Lake supports separate subscriber access methods. Each subscriber can be limited to the required sources and Regions, allowing analyst queries and SaaS notifications without unrestricted bucket access.
  2. Enable Security Lake for the required accounts and Regions while retaining the configured OCSF custom sources. ✓
    Security Lake provides organization-owned S3-backed storage, OCSF and Parquet normalization, configurable retention and replication, and collection across the configured accounts and Regions.
  3. Centralize raw logs in S3 and grant the SaaS tool full bucket read access for notifications and queries.
    Raw S3 storage alone does not provide the required managed normalization, and full bucket access violates the least-privilege integration requirement.
  4. Use CloudTrail organization trails alone and expose their S3 destination through an S3 access point.
    CloudTrail covers AWS API activity, not the stated on-premises and third-party sources or the required unified OCSF lake.
  5. Forward every source through Kinesis Data Streams and implement custom Lambda parsers for a proprietary schema.
    This is executable, but it adds custom normalization and uses a proprietary schema despite the requirements to minimize parsing and use an open schema.
The trap
Assumes organization trails are a universal security-data ingestion layer. Chooses custom processing despite the managed normalization requirement. Treats bucket storage and broad access as a substitute for Security Lake subscribers.

Enable the configured Security Lake deployment and create separate scoped query and notification subscribers.

9. Create a CloudWatch Logs data-protection policy: Which design best meets these requirements?

Medium
A regulated research workload stores application audit logs in CloudWatch Logs. Investigators must find requests containing possible patient identifiers, but analysts normally must not view the unmasked values. The security team needs an alarm when sensitive data is detected and must search only newly ingested events after a policy change. Logs are in both Standard and Infrequent Access classes. Which design best meets these requirements?
  1. Create Standard-class metric filters for patient identifiers and allow unrestricted Logs Insights searches.
    Metric filters are unavailable for Infrequent Access log groups, and unrestricted searches expose unmasked values.
  2. Create a CloudWatch Logs data-protection policy, then search all events and alarm on ordinary log-content filters.
    The policy can mask the data, but ordinary metric filters do not provide the required cross-class detection design and do not replace the supported LogEventsWithFindings metric.
  3. Create a CloudWatch Logs data-protection policy for the patient identifiers, alarm on AWS/Logs LogEventsWithFindings, restrict logs:Unmask to approved investigators, and query only events ingested after policy activation. ✓
    Data protection masks configured identifiers in Standard and Infrequent Access groups, emits LogEventsWithFindings for alarming, and permits cleartext viewing only to principals with logs:Unmask. Detection and masking apply to events ingested after activation.
  4. Export the log groups to S3, query them with Athena, and restrict result access to approved investigators.
    This does not provide CloudWatch Logs data-protection masking or the service-generated detection metric for both log classes.
The trap
Moves analysis elsewhere without satisfying the CloudWatch protection and alarm requirements. Ignores both the log-class limitation and access-control requirement. Uses a generic log-content alarm instead of the service-generated findings metric.

Use data protection, LogEventsWithFindings, restricted unmask access, and a post-activation query range.

10. Use Security Lake for OCSF normalization and query: Which design best fits?

Medium
An incident response team receives application, VPC Flow Logs, Route 53 Resolver query logs, and security findings from many accounts. Formats differ by source, and responders need to correlate a suspicious source IP across DNS queries, network flows, and findings. The application and third-party producers already provide any required custom Security Lake data in OCSF Parquet, and all stated sources are configured for collection. The team wants a managed normalized store for security events while retaining the ability to run SQL-style investigations. Responders need cross-source search rather than separate dashboards. Which design best fits?
  1. Use Route 53 Resolver query logging and ignore VPC Flow Logs because DNS identifies every network connection.
    Resolver logs capture DNS queries but do not describe every network connection; omitting flow logs loses required correlation data.
  2. Use CloudTrail Lake channels to ingest selected external events and query them as one store.
    CloudTrail Lake can receive supported external events through channels, but this workflow does not provide the configured VPC Flow Logs, Resolver logs, findings, and custom OCSF normalization as the requested unified Security Lake dataset.
  3. Use CloudWatch Logs Insights separately against each source log group and manually compare results.
    Separate searches require manual correlation and do not provide the requested managed common schema across sources.
  4. Use Security Lake for OCSF normalization and query its S3-backed data with Amazon Athena. ✓
    Security Lake provides the configured cross-source normalized store, while Athena performs SQL investigations across its S3-backed data.
The trap
Overstates DNS visibility. Assumes parallel searches equal normalized correlation. Uses a supported external-event feature as a universal replacement for Security Lake source collection.

Use Security Lake for normalized cross-source storage and Athena for SQL correlation.

11. Enable Route 53 Resolver query logging for the VPCs: Which configuration best satisfies the investigation requ

Medium
A company federates authentication with a partner through an inbound Route 53 Resolver endpoint. Security analysts suspect compromised partner workloads are resolving attacker-controlled domains. The VPCs and endpoint are already identified, and logs must show originating resource context, DNS responses, and blocked DNS Firewall actions. The design must centralize events without requiring packet capture or host agents. Which configuration best satisfies the investigation requirement?
  1. Install the GuardDuty security agent on partner instances and forward runtime findings through Amazon EventBridge.
    GuardDuty runtime findings can detect threats, but they do not provide the required complete DNS query and response records.
  2. Enable VPC Flow Logs for the endpoint subnets and deliver them to a centralized CloudWatch Logs account.
    VPC Flow Logs show network metadata, but they do not record queried domain names, DNS responses, or DNS Firewall actions.
  3. Enable CloudTrail data events for the partner's Amazon EC2 instances and deliver them to an organization trail.
    CloudTrail records API activity, not DNS queries generated by operating systems or Resolver DNS Firewall decisions.
  4. Enable Route 53 Resolver query logging for the VPCs and send records to a centralized Amazon S3 bucket. ✓
    Resolver query logging records queried names, responses, source context, and DNS Firewall actions without inspecting packet payloads.
The trap
Confuses connection metadata with application-layer DNS evidence required to investigate domain resolution. Treats threat findings as a replacement for authoritative DNS telemetry needed during forensic analysis. Assumes CloudTrail captures workload network behavior merely because instances perform the underlying activity.

Route 53 Resolver query logging supplies DNS names, responses, source context, and Firewall actions while avoiding packet capture.

12. Use EKS Pod Identity to associate narrowly scoped IAM: Which TWO actions best satisfy these requirements?

Medium
A container platform runs production workloads on Amazon EKS worker nodes backed by Amazon EC2. The security team must detect suspicious process execution, file access, command-line arguments, and network connections inside containers. Application teams also require workload roles that cannot read unrelated S3 buckets. GuardDuty is enabled, the cluster has outbound access for agent installation, and separate roles are available for pods. Which TWO actions best satisfy these requirements? Select TWO.

Select two. More than one option is correct — every correct one is ticked below.

  1. Use EKS Pod Identity to associate narrowly scoped IAM roles with workloads requiring AWS access. ✓
    EKS Pod Identity provides workload-specific credentials, allowing permissions to be limited without granting node-wide access.
  2. Enable VPC Flow Logs on worker-node subnets and rely on them for process and file activity.
    VPC Flow Logs provide network-flow metadata and cannot expose container processes, command lines, or file access.
  3. Attach the required S3 permissions to the worker-node instance role for all application containers.
    Node-role permissions are broadly available to workloads and do not enforce the required per-application access boundaries.
  4. Enable GuardDuty Runtime Monitoring for Amazon EKS and permit GuardDuty to manage the security agent. ✓
    GuardDuty Runtime Monitoring observes process, file, command-line, and network activity for supported EKS workloads.
  5. Enable GuardDuty Runtime Monitoring for Amazon EKS on AWS Fargate profiles hosting the cluster workloads.
    GuardDuty Runtime Monitoring does not support Amazon EKS clusters running on AWS Fargate.
The trap
Confuses supported ECS Fargate runtime coverage with unsupported EKS Fargate coverage. Assumes shared node credentials provide least privilege because applications use separate containers. Mistakes network telemetry for host and container runtime visibility.

GuardDuty Runtime Monitoring supplies runtime evidence, while EKS Pod Identity limits AWS permissions per workload.

130 more 1: Detection questions

The remaining 130 questions in this domain are part of the full AWS bank — 890 questions, every option explained. Start with the free five-minute check and see your score per domain.

Test your AWS readiness — free

Other AWS domains

Part of the Certsqill AWS question bank · 1: Detection · Every answer, right and wrong, comes with its own explanation.