15a-aws-security-자격증-오답노트-mini-test

오답노트

mini test

Q) A company’s developers use AWS Lambda function URLs to invoke functions directly. The company must ensure that developers cannot create or update unauthenticated function URLs in production accounts. The company wants to enforce this requirement centrally by using AWS Organizations. The solution must prevent insecure configurations without requiring developers to perform extra deployment steps.

Which solution should the security engineer recommend?

1. Use AWS Config organization rules to detect Lambda function URLs that use the NONE authentication type, aggregate the findings in a security account, and trigger automated remediation to replace the function URL configuration in production accounts

2. Use an AWS WAF delegated administrator account to identify and block unauthenticated Lambda function URL access in production accounts based on the organizational unit that owns the function

3. Create a service control policy that allows lambda:CreateFunctionUrlConfig and lambda:UpdateFunctionUrlConfig only when the lambda:FunctionUrlAuthType condition key is set to AWS_IAM

4. Create a service control policy that denies lambda:CreateFunctionUrlConfig and lambda:UpdateFunctionUrlConfig when the lambda:FunctionUrlAuthType condition key is set to NONE

답: 4

SCP(Service Control Policy)는 guardrail이다. SCP가 권한을 부여하지 않으므로 allow할 수는 없음. Unauthenticated function URLs를 막고싶으므로 condition key가 NONE인 function url을 생성하지 못하게 SCP에서 deny하는게 정답이다.

틀린 이유: SCP가 명시적으로 허용하지 않으면 다 거부하는걸로 착각함. IAM Policy쪽이었나.. 혼동했음

Q) A company runs a web application that captures highly sensitive information and stores it in an Amazon DynamoDB table. The company needs a solution that protects the data from the point of creation until it is stored and later read, and the company also needs a way to detect whether anyone has changed the stored data without authorization.

Which solution should the security engineer recommend?

1. Use DynamoDB server-side encryption with an AWS owned key, and enable point-in-time recovery so unauthorized modifications can be identified and rolled back

2. Use an AWS Key Management Service customer managed key for DynamoDB server-side encryption, and enable DynamoDB Streams so the application can review all item changes after they occur

3. Use the DynamoDB Encryption Client to apply client-side encryption and cryptographic signing to the table items

4. Use the AWS Encryption SDK to apply client-side encryption and signing to the table items before the application stores them in DynamoDB

틀린 이유: DynamoDB Encryption Client라는게 있는지 몰랐음.

Correct option:

Use the DynamoDB Encryption Client to apply client-side encryption and cryptographic signing to the table items

The DynamoDB Encryption Client is designed specifically for protecting DynamoDB items with client-side encryption. Because the encryption happens in the application before the data is sent to DynamoDB, the data remains protected end to end rather than relying only on storage-layer protection after it reaches the service.

The DynamoDB Encryption Client also supports signing table items. That signing capability helps detect unauthorized changes to the stored data because the application can verify the signature when it reads the item back. If the item has been tampered with, the signature validation fails.

This makes the option the best fit for both requirements. It provides end-to-end protection through client-side encryption and supports integrity checking through item signing, which directly addresses unauthorized data modification.

Incorrect options:

Use DynamoDB server-side encryption with an AWS owned key, and enable point-in-time recovery so unauthorized modifications can be identified and rolled back - DynamoDB server-side encryption and point-in-time recovery can help protect data at rest and recover from unwanted changes after the fact. But this option does not provide end-to-end protection, and point-in-time recovery is not the same as cryptographically detecting tampering of individual items. It helps restore data, not verify integrity at read time.

Use an AWS Key Management Service customer managed key for DynamoDB server-side encryption, and enable DynamoDB Streams so the application can review all item changes after they occur - A customer managed KMS key for server-side encryption improves control over encryption at rest, and DynamoDB Streams can record changes to items for downstream processing. However, this still does not give end-to-end protection from the application layer, and Streams do not provide cryptographic proof that an item was not altered. They provide change records, not signed integrity validation.

Use the AWS Encryption SDK to apply client-side encryption and signing to the table items before the application stores them in DynamoDB - The AWS Encryption SDK can perform client-side encryption and signing, which makes this option look very close to the . However, it is a general-purpose encryption library rather than the DynamoDB-specific client designed to protect and sign DynamoDB items with awareness of table item structure. Because the question is specifically about data stored in a DynamoDB table and detecting unauthorized item changes, the DynamoDB Encryption Client is the more precise and intended service-specific answer.

Q) A company is accelerating the migration of several applications to AWS in a single AWS Region. The target environment will use a combination of Amazon EC2 instances, Elastic Load Balancing load balancers, and Amazon S3 buckets. The company wants to complete the migration quickly and with minimal implementation effort.

All applications must meet these security requirements:

Data must be encrypted at rest.

Data must be encrypted in transit.

Endpoints must be monitored for anomalous network traffic.

Which combination of actions should the security engineer recommend to meet these requirements with the least operational effort? (Select three)

1. Install Amazon Inspector agents on the Amazon EC2 instances by using AWS Systems Manager Automation so the company can monitor the instances for suspicious network activity

2. Enable Amazon GuardDuty in all relevant AWS accounts so the company can detect anomalous network and threat activity

3. Enable AWS Network Firewall for every VPC that hosts the applications, configure stateful rules to inspect all outbound flows, and rely on the firewall logs as the primary mechanism for endpoint anomaly detection

4. Configure AWS Certificate Manager and associate ACM certificates with the load balancers so application traffic is encrypted in transit

5. Use AWS Key Management Service for key management, and create an S3 bucket policy that denies PutObject requests unless the request includes the x-amz-meta-side-encryption condition

6. Use AWS Key Management Service for key management, and create an S3 bucket policy that denies PutObject requests unless the request includes the x-amz-server-side-encryption condition

답: 2, 4, 6 GuardDuty가 network와 thread activity도 감시할 수 있다.

Correct option:

Enable Amazon GuardDuty in all relevant AWS accounts so the company can detect anomalous network and threat activity

Amazon GuardDuty is the AWS-native threat detection service for monitoring workloads and accounts for suspicious activity. It analyzes data sources such as VPC Flow Logs, DNS logs, and AWS CloudTrail management events to identify anomalous network behavior and other threats. This directly addresses the requirement to monitor endpoints for unusual network activity.

This is also the lowest-effort option among the choices for network anomaly detection. It does not require the company to build a custom analytics pipeline or manage host-based inspection logic on every instance. Enabling GuardDuty is a managed control that aligns well with a fast migration timeline.

Configure AWS Certificate Manager and associate ACM certificates with the load balancers so application traffic is encrypted in transit

AWS Certificate Manager is the simplest managed way to provision and use TLS certificates on Elastic Load Balancing load balancers. Associating ACM certificates with the load balancers ensures that client connections to the application are encrypted in transit.

This meets the in-transit encryption requirement with minimal effort because ACM handles certificate issuance and renewal for supported public certificates. The company avoids the operational burden of manually issuing, rotating, and deploying certificates.

Use AWS Key Management Service for key management, and create an S3 bucket policy that denies PutObject requests unless the request includes the x-amz-server-side-encryption condition

Using AWS Key Management Service together with an S3 bucket policy that enforces the x-amz-server-side-encryption header is the correct way to require encrypted object uploads to Amazon S3. This ensures that objects written to the bucket are encrypted at rest by using SSE-KMS rather than relying only on application behavior.

This option is also operationally efficient because it uses a managed encryption service and an S3-native enforcement mechanism. The policy blocks noncompliant uploads automatically, which helps the company meet the encryption-at-rest requirement quickly during the migration.

Incorrect options:

Install Amazon Inspector agents on the Amazon EC2 instances by using AWS Systems Manager Automation so the company can monitor the instances for suspicious network activity - Amazon Inspector is a vulnerability management service, not the primary service for detecting anomalous network traffic. It helps identify software vulnerabilities and unintended network exposure, but it does not serve as the main managed detector for suspicious endpoint network behavior in the way GuardDuty does. This option also refers to installing an Inspector agent, which is not the best fit for the stated requirement and adds unnecessary implementation overhead compared to enabling GuardDuty. The company needs anomaly detection, not primarily vulnerability scanning.

Enable AWS Network Firewall for every VPC that hosts the applications, configure stateful rules to inspect all outbound flows, and rely on the firewall logs as the primary mechanism for endpoint anomaly detection - AWS Network Firewall can inspect network traffic and enforce network security policies, which makes this option sound attractive for traffic monitoring. However, it is more complex and more operationally heavy than enabling GuardDuty, especially for a company that wants to migrate quickly with the least effort. The requirement is to monitor endpoints for anomalous network traffic, and GuardDuty provides a managed detection capability that is simpler to enable. Network Firewall is a stronger traffic control mechanism, but it is not the least-effort solution here.

Use AWS Key Management Service for key management, and create an S3 bucket policy that denies PutObject requests unless the request includes the x-amz-meta-side-encryption condition - This option is close to the because it uses AWS KMS and a bucket policy to enforce encrypted uploads. However, the header condition is wrong. The correct S3 request header for server-side encryption enforcement is x-amz-server-side-encryption, not x-amz-meta-side-encryption. Because the condition key is incorrect, the policy would not reliably enforce SSE-KMS uploads in the intended way. That makes this option technically incorrect even though the overall direction appears plausible.

Q) A company manages hundreds of AWS accounts through AWS Organizations. The company is preparing to create many IAM roles and IAM policies for several internal teams, including a product team, a security team, and a platform engineering team. Some IAM policies will be reused across multiple teams.

A security engineer must design a structure that logically groups the IAM roles that belong to each team. The solution also must ensure that only the platform engineering team can delegate IAM roles to AWS services.

Which solution should the security engineer recommend?

1. Organize the IAM roles for each team by using IAM paths, and apply a service control policy that denies iam:PassRole for all principals except roles that are in the platform team path

2. Apply team-specific tags to the IAM roles, and use a service control policy that denies sts:AssumeRole for all principals except the platform team roles

3. Apply team-specific tags to the IAM policies, and use a service control policy that denies iam:PassRole for all principals except the policies that belong to the platform team

4. Organize the IAM roles for each team by using IAM paths, and apply permissions boundaries to the roles in the product team and security team paths so those roles cannot grant iam:PassRole to other principals or services

답: 1 4번 선택해서 틀렸었다. 권한이라 permissions boundaries라고 착각함. AWS Organizations 관련이니까 service control policy 골랐으면 됐는데. permnissions boundaries는 IAM User와 IAM Role에 대한 것이다.

IAM 관련해서 logically group 이라는 단어가 나오면 ‘IAM paths’와 관련이 있다.

iam:PassRole: 서비스에게 자신의 Role을 전달해서 사용하게 함 sts:AssumeRole: 자신이 어떤 Role의 권한을 가져와서 사용함

Correct option:

Organize the IAM roles for each team by using IAM paths, and apply a service control policy that denies iam:PassRole for all principals except roles that are in the platform team path

IAM paths provide a clean way to logically group IAM roles by team. This satisfies the organizational requirement because roles can be structured under paths such as /product/, /security/, and /platform/, making administration and policy targeting easier.

The second requirement is specifically about controlling delegation of IAM roles to AWS services. The relevant permission for that action is iam:PassRole, not sts:AssumeRole. If only the platform team should be able to delegate roles to AWS services, the company should restrict iam:PassRole accordingly.

Using an SCP is the strongest answer because the company uses AWS Organizations and wants a broad guardrail across many AWS accounts. An SCP deny on iam:PassRole, with an exception for the platform team role path, creates a centralized preventive control that works consistently across the organization.

Incorrect options:

Apply team-specific tags to the IAM roles, and use a service control policy that denies sts:AssumeRole for all principals except the platform team roles - Tagging roles by team can help with classification and access management, but this option denies the wrong permission. The requirement is about delegating IAM roles to AWS services, which is controlled by iam:PassRole, not by sts:AssumeRole. sts:AssumeRole controls whether one principal can assume another role. That is different from passing a role to an AWS service such as Lambda, EC2, or ECS. Because it targets the wrong action, this option does not meet the requirement.

Apply team-specific tags to the IAM policies, and use a service control policy that denies iam:PassRole for all principals except the policies that belong to the platform team - Tagging IAM policies instead of IAM roles does not satisfy the requirement to logically group the roles of each team. The grouping requirement is specifically about roles, so applying tags only to policies misses an important part of the problem. This option also incorrectly assumes that controlling policies can substitute for controlling iam:PassRole on roles. AWS services receive roles, not policies, so exempting platform team policies does not correctly solve the delegation requirement.

Organize the IAM roles for each team by using IAM paths, and apply permissions boundaries to the roles in the product team and security team paths so those roles cannot grant iam:PassRole to other principals or services - Permissions boundaries limit the maximum permissions that an IAM principal can have, so this sounds plausible. However, the requirement is to enforce the control consistently across hundreds of accounts in an AWS Organizations environment. An SCP is the stronger and more centralized preventive control for that requirement. Also, permissions boundaries on selected roles do not by themselves create an organization-wide guardrail against all non-platform principals delegating roles to AWS services.

Q) A company is migrating containerized workloads from its data center to Amazon Elastic Container Service clusters. The company needs a solution that can identify potential threats affecting the running workloads and also strengthen the security posture of the container environment.

Which solution should the security engineer recommend?

1. Audit Amazon ECS API activity by using Amazon CloudWatch Logs and review the logs for unauthorized access patterns against the clusters

2. Enable Amazon GuardDuty Runtime Monitoring for the Amazon ECS clusters to detect runtime threats in the workloads

3. Configure AWS Security Hub to aggregate container image scan results and enable continuous compliance monitoring of ECS task definitions

4. Enable Amazon Inspector scanning for container images and use the findings to detect active threats within running Amazon ECS tasks and containers

답: 2 4번 골랐다가 틀렸다. running workloads니까 runtime 감시 가능한 GuardDuty 골랐어야 했는데.

Correct option:

Enable Amazon GuardDuty Runtime Monitoring for the Amazon ECS clusters to detect runtime threats in the workloads

Amazon GuardDuty Runtime Monitoring is designed to detect runtime threats in Amazon ECS workloads. AWS documents that Runtime Monitoring can analyze runtime events from containers and workloads in Amazon ECS and generate findings for suspicious behavior such as privilege escalation, malicious process execution, and other runtime compromise indicators. This directly addresses the requirement to detect potential threats in the workloads.

This is also the best answer for improving the security posture of the container clusters because it provides managed threat detection that is purpose-built for container runtime activity. It covers both Amazon ECS on Amazon EC2 and supported Amazon ECS on AWS Fargate scenarios, and AWS provides dedicated documentation for configuring Runtime Monitoring on ECS clusters.

Among the available choices, this is the most direct and accurate fit. It is specifically designed for threat detection in running ECS workloads rather than vulnerability scanning, API auditing, or network-log review alone.

Incorrect options:

Audit Amazon ECS API activity by using Amazon CloudWatch Logs and review the logs for unauthorized access patterns against the clusters - Reviewing Amazon ECS API activity can help identify suspicious administrative actions, but it does not provide runtime threat detection inside the running containers and workloads. This option also relies on manual or custom analysis of logs rather than using a managed threat detection capability. It therefore falls short of the requirement to detect threats in workloads and improve cluster security posture.

Configure AWS Security Hub to aggregate container image scan results and enable continuous compliance monitoring of ECS task definitions - Security Hub provides excellent aggregation and reporting of findings from multiple security services but is not a threat detection service itself. Security Hub can display container image scan results and compliance status from other services but does not detect active threats in running containers. Continuous compliance monitoring of ECS task definitions identifies configuration drift and policy violations but does not address the requirement for detecting threats within executing containers. Security Hub enhances the visibility and reporting of findings from services like Inspector and GuardDuty but should be used in conjunction with rather than as a replacement for GuardDuty Runtime Monitoring. Task definition compliance monitoring is a configuration management function; threat detection requires real-time analysis of container runtime behavior, which Security Hub does not provide natively.

Enable Amazon Inspector scanning for container images and use the findings to detect active threats within running Amazon ECS tasks and containers - This option is close because Amazon Inspector can scan container images for vulnerabilities, which does improve part of the security posture of container environments. However, image scanning is not the same as detecting active runtime threats in running ECS workloads. The question explicitly asks for detection of potential threats in workloads, which points to runtime monitoring rather than image vulnerability scanning. Therefore, this option is incomplete.

Q) Two Amazon EC2 instances in different subnets must be able to communicate with each other, but the connection is failing. Other instances in the same two subnets can communicate successfully. The security engineer has already confirmed that the relevant security groups contain rules that allow the required traffic. The security engineer must identify the next troubleshooting step that is most likely to reveal the cause of the problem.

Which action should the security engineer take?

1. Detach and reattach the security groups on both EC2 instances so the allowed rules are reevaluated for the failed connection

2. Review the inbound and outbound network ACL rules for explicit deny entries that might block traffic between the two subnets

3. Examine the rejected packet reason codes in VPC Flow Logs to determine which service denied the traffic between the two instances

4. Review the route tables for both subnets to confirm that each route table contains a local route for the VPC CIDR block

답: 2 NACL은 ip나 port 막을 수 있음. 두 서브넷에서 이미 통신 잘 되는 인스턴스가 있더라도 두 인스턴스가 사용하는 ip나 port가 NACL에서 deny되지 않았다면 통신 가능하다.

Correct option:

Review the inbound and outbound network ACL rules for explicit deny entries that might block traffic between the two subnets

Network ACLs are stateless and operate at the subnet boundary. Unlike security groups, network ACLs support both allow and deny rules, and they are evaluated in numbered order for both inbound and outbound traffic. If two specific EC2 instances in different subnets cannot communicate while other hosts in the same subnets can, the next logical troubleshooting step is to inspect the network ACL rules to determine whether a deny entry or an overly specific rule is affecting this traffic pattern.

This fits the scenario because the security groups have already been verified to allow the traffic. Security groups do not have deny rules, so the remaining subnet-level packet filter that can explicitly deny traffic is the network ACL. A deny or missing ephemeral port allowance on one side can block the communication even when security groups are correct.

This is the best answer because it targets the AWS control plane component most likely to explain the behavior described. It focuses on the actual packet-filtering layer that can still block traffic after security groups have been ruled out.

Incorrect options:

Detach and reattach the security groups on both EC2 instances so the allowed rules are reevaluated for the failed connection - Detaching and reattaching security groups is not a standard troubleshooting method for this kind of issue. Security group rules are applied dynamically, and there is no need to reattach them to force reevaluation. This option also ignores the key clue in the question that security groups are already confirmed to allow the traffic. Reattaching them would not address a likely subnet-level deny condition.

Examine the rejected packet reason codes in VPC Flow Logs to determine which service denied the traffic between the two instances - VPC Flow Logs can be very useful for troubleshooting rejected traffic, and this option is plausible. However, VPC Flow Logs are a diagnostic aid rather than the primary control that is likely causing the issue in this scenario. The question asks which troubleshooting step should be performed. Since security groups are already known to be correct and other hosts in the subnets work, the most direct next step is to inspect network ACL rules themselves. Flow Logs can help confirm the findings afterward, but they are not the most direct answer here.

Review the route tables for both subnets to confirm that each route table contains a local route for the VPC CIDR block - Route tables are worth reviewing in some connectivity scenarios, but the question states that other hosts in the same subnets can communicate successfully. That strongly suggests the subnet routing is already functioning. Because the problem is isolated to two specific instances and security groups have already been validated, route tables are less likely than network ACLs to explain the behavior. A subnet route problem would usually affect other hosts in the same subnets as well.

Q) A company runs a regulated application on Amazon EC2 instances inside a VPC. A compliance mandate requires the company to inspect all traffic to and from the workload for network-layer attacks, including examination of the full packet contents instead of only connection metadata. A security engineer deploys intrusion detection software on a dedicated m5n.2xlarge Amazon EC2 instance. The engineer must now configure AWS networking so the monitoring instance can inspect traffic for the application instances.

Which action should the security engineer take next?

1. Place the elastic network interface of the monitoring Amazon EC2 instance into promiscuous mode so it can capture traffic that is flowing to and from the application instances

2. Enable VPC Flow Logs for the application subnets, send the logs through a Network Load Balancer, and deliver the traffic data to the monitoring Amazon EC2 instance for inspection

3. Configure VPC Traffic Mirroring for the application instance elastic network interfaces, and use a Network Load Balancer as the traffic mirror target for the monitoring Amazon EC2 instance

4. Create a Gateway Load Balancer endpoint in the application subnets, register the monitoring Amazon EC2 instance as the inspection appliance, and leverage the endpoint to passively duplicate all packets for analysis without using traffic mirroring

답: 3

4번 선택지에서 Gateway Load Balancer endpoint는 일반적으로 inline inspection용으로 라우팅 경로에 넣어 실제 트래픽을 검사 장비로 보내는 방식입니다. “passively duplicate all packets” 용도가 아닙니다. 패킷 복제 자체는 Traffic Mirroring의 역할입니다.

Gateway Load Balancer는 ‘inline inspection’ 이라는 단어나 관련 내용이 있을 때 선택해야 한다.

Gateway Load Balancer는 트래픽을 복제하는게 아니라 트래픽을 경유해서 inline inspection을 수행함. 트래픽이 복제되지 않고 흐름 중간에 Gateway Load Balancer를 거치는 것이다.

Correct option:

Configure VPC Traffic Mirroring for the application instance elastic network interfaces, and use a Network Load Balancer as the traffic mirror target for the monitoring Amazon EC2 instance

Amazon VPC Traffic Mirroring is the AWS feature designed to copy network traffic from elastic network interfaces so that security appliances can inspect it out of band. AWS documents that Traffic Mirroring supports packet-level inspection use cases, which directly matches the requirement to inspect the whole packet for network-level attacks.

A Network Load Balancer can act as a traffic mirror target. This allows the mirrored traffic from the application instances to be forwarded to the intrusion detection software running on the dedicated monitoring EC2 instance. The application traffic path remains unchanged while the monitoring instance receives a copy for analysis.

This is the most direct and compliant solution because it provides passive full-packet visibility by using native AWS networking capabilities. It satisfies the regulatory need for network-level inspection without requiring changes to the application itself.

Incorrect options:

Place the elastic network interface of the monitoring Amazon EC2 instance into promiscuous mode so it can capture traffic that is flowing to and from the application instances - Promiscuous mode is a traditional networking concept, but enabling it on an EC2 instance does not cause the VPC to send that instance all traffic from other instances. The problem is not that the monitoring instance cannot read packets addressed to itself. The problem is that the monitoring instance needs a copy of packets from other interfaces, and that requires an AWS traffic-copying feature such as VPC Traffic Mirroring.

Enable VPC Flow Logs for the application subnets, send the logs through a Network Load Balancer, and deliver the traffic data to the monitoring Amazon EC2 instance for inspection - VPC Flow Logs provide metadata about network traffic such as source IP, destination IP, port, protocol, and accept or reject status. They do not include packet payloads or full packet contents. Because the requirement explicitly states that the company must inspect the whole packet, VPC Flow Logs are insufficient. They are useful for traffic analysis but not for full-packet intrusion detection.

Create a Gateway Load Balancer endpoint in the application subnets, register the monitoring Amazon EC2 instance as the inspection appliance, and leverage the endpoint to passively duplicate all packets for analysis without using traffic mirroring - Gateway Load Balancer is useful for steering traffic through inspection appliances in inline architectures, which makes this option sound plausible. However, the scenario asks for the next step after deploying an IDS instance to monitor traffic to and from existing application instances. For passive packet-copy inspection, the native AWS feature is VPC Traffic Mirroring. A Gateway Load Balancer endpoint by itself is not the intended answer for this out-of-band monitoring requirement.

Q) A company has enabled Amazon GuardDuty in every AWS Region as part of its threat detection strategy. In one VPC, the company runs an Amazon EC2 instance that serves as an FTP server. Because many clients from different locations connect to the server every hour, GuardDuty repeatedly flags the activity as a brute-force style finding. The security team has investigated the finding and confirmed that it is a false positive for this workload. A security engineer must reduce this recurring noise while preserving GuardDuty visibility for other potentially anomalous behavior.

Which solution should the security engineer recommend?

1. Disable the GuardDuty detection that is generating the FTP-related brute force finding in the Region where the FTP server is deployed

2. Add the FTP server to a GuardDuty trusted IP list so GuardDuty no longer generates findings for connections that involve that server

3. Create a GuardDuty suppression rule that automatically archives new findings when they match the specified criteria for the known false positive

4. Send the GuardDuty findings to AWS Security Hub, create a custom insight for the FTP server finding pattern, and exclude the matching findings from GuardDuty processing in all Regions

답:3 2번은 false positive가 아닌 실제 위협도 GuardDuty가 무시하게 된다. GuardDuty 관련 false positive 내용이 나오면 GuardDuty suppression이 답이다.

Correct option:

Create a GuardDuty suppression rule that automatically archives new findings when they match the specified criteria for the known false positive

GuardDuty suppression rules are the native AWS mechanism for reducing recurring false positive noise while preserving the underlying GuardDuty detection capability. AWS documents that suppression rules can automatically archive newly generated findings that match specified criteria, such as a finding type, resource, or other attributes. This directly addresses the requirement to improve the signal-to-noise ratio.

This is the best answer because it does not disable broader threat detection. Instead, it narrowly targets the known benign pattern for the specific FTP workload. That means GuardDuty can continue to detect other unexpected or malicious behavior in the account and Region without repeatedly surfacing the same confirmed false positive.

It is also the least operationally complex solution. The security engineer can configure the suppression rule once with the right matching criteria, and GuardDuty handles the rest automatically without requiring custom code or post-processing logic.

Incorrect options:

Disable the GuardDuty detection that is generating the FTP-related brute force finding in the Region where the FTP server is deployed - Disabling a GuardDuty detection or rule in the Region is too broad. The company wants to reduce false positive noise without compromising visibility into other anomalous behavior, and turning off the detection would weaken overall monitoring. This option therefore sacrifices useful security coverage just to eliminate one noisy use case. A targeted suppression rule is much more appropriate than disabling a detection class for the entire Region.

Add the FTP server to a GuardDuty trusted IP list so GuardDuty no longer generates findings for connections that involve that server - GuardDuty trusted IP lists are used to suppress findings for activity that originates from trusted source IP addresses. They are not designed to suppress findings simply because a specific EC2 instance acts as a legitimate public-facing service. This option also misunderstands the relationship between the FTP server and the source traffic. The issue is that many clients connect to the server from multiple locations, not that the server itself should be treated as a trusted source in GuardDuty.

Send the GuardDuty findings to AWS Security Hub, create a custom insight for the FTP server finding pattern, and exclude the matching findings from GuardDuty processing in all Regions - AWS Security Hub can aggregate GuardDuty findings and custom insights can help organize or filter them for analysis. However, Security Hub does not replace GuardDuty suppression rules for controlling how recurring false positive findings are handled at the source. This option also incorrectly suggests excluding findings from GuardDuty processing through Security Hub. The correct place to control this behavior is in GuardDuty itself, not in a downstream aggregation service.

Q) A company manages separate AWS accounts for its human resources, finance and software development departments by using AWS Organizations. All developers work only in the software development account. The company recently discovered that developers launched Amazon EC2 instances that included software packages the company has not approved. A security engineer must implement a solution that allows developers to launch EC2 instances only with company-approved software images and only inside the software development account.

Which solution should the security engineer recommend?

1. Create an AWS Service Catalog portfolio that contains approved Amazon EC2 products, share the portfolio with all AWS accounts in the organization, and allow developers to launch those products from any account where they have console access

2. Create an Amazon EC2 Image Builder pipeline that produces approved AMIs, share those AMIs with the software development account, and allow developers to launch any EC2 instance as long as the AMI owner is the company account

3. Create an AWS Service Catalog portfolio in the software development account that contains Amazon EC2 products based on approved AMIs, and grant developers permission to launch only products from that portfolio

4. In the management account, create approved AMIs, use AWS CloudFormation StackSets to deploy those AMIs across the organization, and allow developers to launch the stack sets from the management account when they need EC2 instances

답: 3 문제 제대로 안 읽어서 틀렸다.. software를 따로 설치하는 그런게 아니라 EC2 launch할 때 이미지에 포함된 software를 말하는 것이었음.

Correct option:

Create an AWS Service Catalog portfolio in the software development account that contains Amazon EC2 products based on approved AMIs, and grant developers permission to launch only products from that portfolio

AWS Service Catalog is designed to let organizations curate and govern approved infrastructure products for end users. By creating a portfolio that contains EC2-based products built from approved AMIs, the company can provide developers with a controlled self-service path to launch instances that already contain only authorized software.

This approach directly addresses both requirements. It limits developers to approved images, and it can be scoped to the software development account so developers do not receive equivalent launch capabilities elsewhere. The developers use a governed catalog product instead of selecting arbitrary AMIs and launch parameters on their own.

This is also the most operationally effective answer because it gives the company a repeatable governance model rather than depending on developer behavior. The company can update the approved products centrally, version them over time, and keep developer experience straightforward while preventing launches from unapproved images.

Incorrect options:

Create an AWS Service Catalog portfolio that contains approved Amazon EC2 products, share the portfolio with all AWS accounts in the organization, and allow developers to launch those products from any account where they have console access - AWS Service Catalog is the right type of service for governing approved EC2 launch options, which makes this choice look believable. However, the requirement is not only to use approved software, but also to ensure that developers can launch EC2 instances only in the software development account. Sharing the portfolio across all accounts would violate that boundary and could let developers launch approved products outside the software development account.

Create an Amazon EC2 Image Builder pipeline that produces approved AMIs, share those AMIs with the software development account, and allow developers to launch any EC2 instance as long as the AMI owner is the company account - Amazon EC2 Image Builder is an excellent way to create approved AMIs, which makes this option look plausible. However, allowing developers to launch any EC2 instance as long as the AMI owner is the company account does not create the same controlled self-service boundary as Service Catalog. This option is also weaker from a governance perspective because it still relies on direct EC2 launch permissions and does not package the approved launch path into a constrained product experience. Developers could still vary instance settings in ways the company may not want.

In the management account, create approved AMIs, use AWS CloudFormation StackSets to deploy those AMIs across the organization, and allow developers to launch the stack sets from the management account when they need EC2 instances - StackSets are used to deploy CloudFormation stacks across accounts and Regions, but they are not the right self-service governance mechanism for giving developers approved EC2 launch options. This option also introduces unnecessary risk by involving the management account in routine developer workflows. The requirement is to keep launches limited to the software development account, and allowing developers to operate through the management account is not appropriate.

Q) A company is expanding its retail footprint and wants to launch a customized web application for each new store on the day the store opens. Every store will have a non-production environment and a production environment, and each environment will run in a separate AWS account. The company uses AWS Organizations and places these accounts in a dedicated organizational unit. Most of the development work is performed by third-party development teams. A security engineer must ensure that every team deploys AWS resources by following the company’s predefined deployment plan. The engineer also must restrict access to that deployment plan so that only the developers who need it can use it. The engineer has already created an AWS CloudFormation template that implements the deployment plan.

Which solution should the security engineer recommend in the most secure way?

1. Create an AWS Service Catalog portfolio in the organization’s management account, add a product based on the AWS CloudFormation template, and share the portfolio with the dedicated organizational unit

2. Use the AWS CloudFormation CLI to convert the AWS CloudFormation template into a module, register the module as a private extension in the CloudFormation registry, publish it, and use a service control policy to allow access to the extension from the organizational unit

3. Create an AWS Service Catalog portfolio in the organization’s management account, add a product based on the AWS CloudFormation template, create a cross-account IAM role for users in the organizational unit accounts, and attach the AWSServiceCatalogEndUserFullAccess managed policy to that role

4. Create an AWS Service Catalog portfolio in the management account, add the AWS CloudFormation template as a product, and share the portfolio with the entire AWS organization so product access can be managed later by account-level IAM policies

답: 1 왜틀렸지?;

Correct option:

Create an AWS Service Catalog portfolio in the organization’s management account, add a product based on the AWS CloudFormation template, and share the portfolio with the dedicated organizational unit

AWS Service Catalog is built to distribute approved infrastructure products to end users in a controlled manner. AWS documents that a portfolio is a collection of products, that products can be based on AWS CloudFormation templates, and that portfolios can be shared directly with an AWS Organizations organizational unit. This directly matches the requirement to enforce a standard deployment plan across multiple accounts while keeping access limited to the developers who need it.

This is also the most secure answer because the portfolio can be shared only with the dedicated organizational unit that contains the store environment accounts. That keeps the deployment plan scoped to the intended accounts instead of exposing it more broadly. Service Catalog is specifically intended to let administrators distribute approved products while controlling who can use them.

Operationally, this is the cleanest governed self-service model. The CloudFormation template becomes a managed product, teams launch only what has been approved, and portfolio sharing through AWS Organizations stays aligned with the OU structure as accounts are added over time.

Incorrect options:

Use the AWS CloudFormation CLI to convert the AWS CloudFormation template into a module, register the module as a private extension in the CloudFormation registry, publish it, and use a service control policy to allow access to the extension from the organizational unit - CloudFormation modules and private extensions can help standardize infrastructure components, which makes this option sound plausible. However, a private extension is not the same as a governed deployment plan delivery mechanism for end users. It standardizes resource modeling, but it does not by itself provide the curated access-control experience that Service Catalog portfolios and products are designed to provide. It also incorrectly relies on an SCP to “allow access” to the extension. SCPs define permission guardrails and maximum available permissions, but they are not the primary mechanism for distributing and granting end-user access to a deployment product. This makes the approach less aligned to the stated requirement.

Create an AWS Service Catalog portfolio in the organization’s management account, add a product based on the AWS CloudFormation template, create a cross-account IAM role for users in the organizational unit accounts, and attach the AWSServiceCatalogEndUserFullAccess managed policy to that role - This option correctly uses AWS Service Catalog, which makes it close to the right answer. However, introducing a cross-account IAM role with the broad AWSServiceCatalogEndUserFullAccess managed policy adds more privilege and complexity than necessary. The requirement is to restrict access to only the developers who need it while securely distributing the deployment plan. Service Catalog already supports granting access to portfolios through normal account-level identity controls once the portfolio is shared to the OU. The extra cross-account role and broad managed policy make this less secure than necessary.

Create an AWS Service Catalog portfolio in the management account, add the AWS CloudFormation template as a product, and share the portfolio with the entire AWS organization so product access can be managed later by account-level IAM policies - This option uses the right service but shares the portfolio too broadly by exposing it to the entire AWS organization. The question states that access to the deployment plan must be limited to only the developers who need access. Sharing the portfolio with the whole organization violates the least-privilege principle at the organization level. Sharing specifically with the dedicated OU is the more secure and precise design.

Q) A company runs a public-facing application on a fleet of Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer. The company requires encryption for client connections to the load balancer and also for connections from the load balancer to the EC2 instances. A security engineer must implement a solution that provides end-to-end encryption between external users and the application instances.

Which solution should the security engineer recommend?

1. Request an Amazon-issued certificate from Certificate Manager, install it on the ALB, request a separate certificate for the EC2 instances, and configure mutual TLS between both layers

2. Request an Amazon-issued certificate in AWS Certificate Manager for the Application Load Balancer, and configure the load balancer to use HTTP to the Amazon EC2 instances because the front-end TLS session already provides complete encryption

3. Create a self-signed certificate for the Application Load Balancer and each Amazon EC2 instance, install the certificates on both tiers, and configure HTTPS for client-to-load-balancer traffic and load-balancer-to-instance traffic

4. Import a third-party certificate into AWS Certificate Manager, associate the certificate with the Application Load Balancer, and install the certificate on the Amazon EC2 instances

답: 4

end-to-end encryption을 위해서는 ec2 instance에도 인증서를 설치해야하므로 ACM에서 발급한 인증서로는 안 되고 third-party certificate이 필요하다.

(ChatGPT: 현재 AWS 기준으로는 ACM public certificate를 export해서 EC2에 설치하는 것도 가능합니다. 그래서 오늘 기준으로는 “ALB에 ACM 발급 cert, EC2에도 ACM export cert” 같은 구성도 가능합니다.)

꼭 end-to-end encryption이라고 해서 로드밸런서와 ec2가 같은 인증서를 써야하는건 아니다. public facing certificate와 로드밸런서←>EC2 에서 사용하는 인증서가 달라도 https 라면 end-to-end encryption이다.

fyi) self-signed certificate은 내부 통신용으로 사용할 수는 있어도 public facing에서는 사용할 수 없다.

현재 AWS 기준으로는 ACM의 exportable public certificate를 요청하면, 그 공개 인증서를 export해서 EC2에 설치해 사용할 수 있다. 다만 기존의 모든 ACM 공개 인증서가 가능한 것은 아니고, export 가능 옵션으로 생성된 인증서여야 하며, 갱신 후 EC2 재배포는 사용자가 관리해야 한다.

ACM의 “Export an AWS Certificate Manager public certificate” 문서에 따르면, 콘솔/CLI/API로 공개 인증서를 export할 수 있고, export 결과에는 certificate, certificate chain, encrypted private key가 포함됩니다. 다만 2025년 6월 17일 이전에 생성된 ACM public certificate는 export할 수 없고, export 시에는 passphrase를 지정해야 합니다.

Correct option:

Import a third-party certificate into AWS Certificate Manager, associate the certificate with the Application Load Balancer, and install the certificate on the Amazon EC2 instances

To achieve end-to-end encryption in this architecture, the company needs a certificate on the Application Load Balancer for the client-to-load-balancer TLS session and also a certificate on each Amazon EC2 instance for the load-balancer-to-instance TLS session. Importing a third-party certificate into AWS Certificate Manager allows the certificate to be attached to the Application Load Balancer, and the same certificate can also be installed directly on the EC2 instances.

This works because the private key material for an imported third-party certificate is available to the company outside ACM, which makes it possible to deploy the certificate and key on the backend instances. That satisfies the requirement for encryption on both legs of the connection path.

This is the most reliable answer in the option set because it provides one certificate approach that can be used on the load balancer and the instances. It avoids depending on non-exportable certificate models and directly supports complete encryption between external users and the application.

Incorrect options:

Request an Amazon-issued certificate from Certificate Manager, install it on the ALB, request a separate certificate for the EC2 instances, and configure mutual TLS between both layers - Requesting separate Amazon-issued certificates for the ALB and EC2 instances creates duplicate certificates and increases management complexity. Amazon-issued certificates are designed primarily for use with AWS managed services and cannot typically be installed on EC2 instances, and configuring mutual TLS adds operational overhead without addressing the stated requirement.

Request an Amazon-issued certificate in AWS Certificate Manager for the Application Load Balancer, and configure the load balancer to use HTTP to the Amazon EC2 instances because the front-end TLS session already provides complete encryption - Using an ACM certificate on the Application Load Balancer does provide encryption for traffic from the external users to the load balancer. However, using HTTP from the load balancer to the EC2 instances breaks the end-to-end encryption requirement. The question explicitly requires complete encryption between the users and the application. That means the backend connection from the ALB to the instances must also use TLS, so this option is insufficient.

Create a self-signed certificate for the Application Load Balancer and each Amazon EC2 instance, install the certificates on both tiers, and configure HTTPS for client-to-load-balancer traffic and load-balancer-to-instance traffic - Although this option does provide encryption on both hops, a self-signed certificate is not appropriate for the public-facing side of the architecture because external users will not inherently trust it. That leads to browser trust warnings and does not meet normal production requirements for secure public access. For the ALB listener that faces internet users, the company should use a publicly trusted certificate, not a self-signed certificate.

Q) A company uses multiple AWS CloudFormation stacks to deploy a suite of applications. The application development team notices that stack deployments fail with permission errors for some team members, while other team members can deploy the same stacks successfully. All team members access the AWS account by assuming roles that are tailored to their job responsibilities. Each team member already has permission to perform operations on the CloudFormation stacks. A security engineer must implement a solution that ensures stack deployments succeed consistently while following the principle of least privilege.

Which combination of actions should the security engineer take? (Select three)

1. Create a CloudFormation service role that uses a composite principal containing every AWS service that might need deployment permissions, and allow the sts:AssumeRole action for those services

2. Create a CloudFormation service role that trusts cloudformation.amazonaws.com as the service principal, and allow the sts:AssumeRole action

3. For each required permission set, attach a separate policy to the service role and specify the ARN of each CloudFormation stack in the Resource element of those policies

4. For each required permission set, attach a separate policy to the service role and specify the ARN of each AWS service resource that CloudFormation must create, update, or delete in the Resource element of the corresponding policy

5. Update each CloudFormation stack to use the CloudFormation service role

6. Create an AWS Service Catalog portfolio for the applications, import the CloudFormation stacks as products, and require all team members to deploy only through the portfolio instead of using CloudFormation directly

답: 2,4,5

CloudFormation은 service role 기반으로 작동함. sts:AssumeRole 권한도 필요.

Correct option:

Create a CloudFormation service role that trusts cloudformation.amazonaws.com as the service principal, and allow the sts:AssumeRole action

AWS CloudFormation service roles are the standard way to make stack operations run with a consistent permission set regardless of which user initiates the deployment. The trust policy for that role must specify cloudformation.amazonaws.com as the service principal so that CloudFormation can assume the role during stack operations. This directly addresses the inconsistency in the scenario. Some team members fail today because CloudFormation is effectively constrained by the permissions of the caller when no service role is consistently used. A dedicated CloudFormation service role fixes that by shifting resource creation and update permissions to a controlled execution role.

Using a service role is also the more secure pattern because it lets the security engineer scope deployment permissions to exactly what the stacks need, instead of granting broad direct permissions to every team member role.

For each required permission set, attach a separate policy to the service role and specify the ARN of each AWS service resource that CloudFormation must create, update, or delete in the Resource element of the corresponding policy

The CloudFormation service role needs the permissions required to create, update, and delete the actual AWS service resources used by the stacks. That means the policies on the service role should target the relevant service resources, not the stack ARNs themselves. This is important for least privilege. By defining separate policies for the required services and scoping access to the corresponding resource ARNs where possible, the engineer can give CloudFormation only the permissions it needs to deploy the applications successfully and consistently.

This option is therefore the correct way to authorize the service role. It aligns permissions with the resources CloudFormation manages rather than with the CloudFormation stack objects.

Update each CloudFormation stack to use the CloudFormation service role

Creating the service role alone is not enough. Each CloudFormation stack must be configured to use that service role so CloudFormation actually executes stack operations with the consistent permission set provided by the role. Once the stacks are updated to use the service role, future stack operations use that role instead of relying on differences in the permissions of individual team member roles. This is what eliminates the inconsistent deployment behavior described in the scenario.

This is also secure because the privilege needed to deploy infrastructure is centralized in the service role rather than being distributed unevenly across developer roles.

Incorrect options:

Create a CloudFormation service role that uses a composite principal containing every AWS service that might need deployment permissions, and allow the sts:AssumeRole action for those services - A CloudFormation service role should trust the CloudFormation service principal, not a composite principal containing multiple AWS services. CloudFormation is the service that assumes the role during deployment. Adding multiple services unnecessarily broadens the trust policy and weakens the security model. The question asks for the most secure approach, and a narrowly scoped trust relationship is the correct design.

For each required permission set, attach a separate policy to the service role and specify the ARN of each CloudFormation stack in the Resource element of those policies - CloudFormation stack ARNs are not the right resources to place in the execution policies that grant deployment permissions. The service role must be able to operate on the actual AWS resources inside the stacks, such as IAM roles, Lambda functions, or other service resources. This option therefore attaches permissions at the wrong layer. Even if the role trusts CloudFormation correctly, the deployments would still fail if the role is not authorized to act on the underlying service resources.

Create an AWS Service Catalog portfolio for the applications, import the CloudFormation stacks as products, and require all team members to deploy only through the portfolio instead of using CloudFormation directly - AWS Service Catalog can govern approved products and deployment workflows, so this option sounds reasonable from a governance perspective. However, it changes the deployment model rather than solving the underlying CloudFormation permission inconsistency. The question is specifically about existing CloudFormation stack deployments failing for some team members. The direct and secure fix is to use a CloudFormation service role with the right permissions and update the stacks to use that role.

Q) A security engineer is updating an IAM policy to protect AWS API operations in a production account. The policy must require multi-factor authentication for IAM users who access specific Amazon EC2 actions. In addition, each authenticated session must remain valid for no longer than 3 hours.

The current IAM policy is:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "ec2:DescribeInstances",
      "ec2:StopInstances",
      "ec2:TerminateInstances"
    ],
    "Resource": ["*"]
  }]
}

Which combination of conditions should the security engineer add to the IAM policy to meet these requirements? (Select two)

1. "Bool": {"aws:MultiFactorAuthPresent": "true"}

2. "Bool": {"aws:MultiFactorAuthPresent": "false"}

3. NumericLessThan": {"aws:MultiFactorAuthAge": "10800"}

4. DateLessThan": {"aws:TokenIssueTime": "10800"}

5. NumericLessThan": {"MaxSessionDuration": "10800"}

답. 1,3

• 2번은 MFA가 없을 때(true가 아니라 false일 때) 허용하는 조건이라 요구사항과 반대입니다.
• 4번의 aws:TokenIssueTime 는 토큰이 발급된 시각 자체(날짜/시간) 를 비교하는 키라서 10800 같은 초 단위 숫자와 비교하는 방식이 맞지 않습니다.
• 5번의 MaxSessionDuration 은 IAM Role 설정값 으로 쓰는 개념이지, 이런 IAM 정책의 Condition 에 넣는 조건 키가 아닙니다.

Correct options:

"Bool": {"aws:MultiFactorAuthPresent": "true"}

The policy must explicitly require MFA, and the correct global condition key for that control is aws:MultiFactorAuthPresent. AWS documents that this key is used to enforce MFA for API access and that it works with a Boolean operator. Setting the value to true ensures that the request must be made with MFA-authenticated credentials. Without this condition, the policy would still allow the listed EC2 API actions even when the IAM user had not authenticated with MFA. Since the requirement explicitly states that MFA must be enforced, this condition is mandatory.

NumericLessThan": {"aws:MultiFactorAuthAge": "10800"}

The session lifetime requirement is met by checking the age of the MFA-authenticated session with the aws:MultiFactorAuthAge condition key. AWS documents that this value is measured in seconds and can be used to limit access to requests made within a specified amount of time after MFA authentication. Using NumericLessThan with a value of 10800 enforces that the MFA-authenticated session must be younger than 3 hours. That directly matches the requirement that each session remain valid for only 3 hours.

Incorrect options:

"Bool": {"aws:MultiFactorAuthPresent": "false"} - This option reverses the intended logic. Setting aws:MultiFactorAuthPresent to false would match requests that are not MFA authenticated, which is the opposite of the requirement. Because the policy must enforce MFA, this condition would weaken access control rather than strengthen it.

DateLessThan": {"aws:TokenIssueTime": "10800"} - aws:TokenIssueTime can be used in some time-based access controls, but this option is invalid as written because it compares a date-based key to a numeric value of 10800. The requirement is specifically about MFA session age, and AWS provides aws:MultiFactorAuthAge for that purpose. This option therefore uses the wrong key and the wrong data type pattern.

NumericLessThan": {"MaxSessionDuration": "10800"} - MaxSessionDuration is not a valid IAM global condition key for use in a policy condition block like this. The relevant condition key for limiting the age of an MFA-authenticated request is aws:MultiFactorAuthAge. As a result, this option is not a valid condition for enforcing a 3-hour MFA session window in the policy.

Q) A company runs a production application in an AWS account. The company receives an email alert that Amazon GuardDuty has generated an Impact:IAMUser/AnomalousBehavior finding. A security engineer must begin the incident investigation playbook and collect evidence quickly. The engineer must analyze the activity in context without making changes that could affect the production application.

Which solution should the security engineer recommend?

1. Sign in to the AWS account by using read-only credentials, review the GuardDuty finding for details about the IAM principal, and attach a DenyAll policy to the IAM identity to stop further activity

2. Sign in to the AWS account by using read-only credentials, review the GuardDuty finding to identify the API activity involved, and use Amazon Detective to investigate the related API calls in context

3. Sign in to the AWS account by using read-only credentials, open AWS Security Hub to locate the finding, and use a custom action to quarantine the affected IAM identity before gathering additional context

4. Sign in to the AWS account by using read-only credentials, review the GuardDuty finding to identify the API activity involved, and use AWS CloudTrail Insights together with AWS CloudTrail Lake to investigate the related API calls in context

답: 2

당장 차단하라는게 아니라 조사하고 증거 모으라는 것이었으므로 2번

1번은 production application에 영향이 간다

Correct option:

Sign in to the AWS account by using read-only credentials, review the GuardDuty finding to identify the API activity involved, and use Amazon Detective to investigate the related API calls in context

Amazon Detective is designed to investigate GuardDuty findings in context. AWS documents that Detective integrates with GuardDuty and helps security teams analyze related API activity, entities, timelines, and behavior patterns around a finding. That makes it a strong fit for a fast investigation workflow when the goal is to understand what happened without changing the environment.

Using read-only credentials is also important because the requirement explicitly says the engineer must collect and analyze information without affecting the production application. Read-only access supports forensic review without introducing containment or remediation changes that might disrupt the workload.

This is the quickest correct approach because it combines the native GuardDuty investigation path with a read-only access model. It avoids unnecessary manual correlation and avoids operational changes during the analysis phase.

Incorrect options:

Sign in to the AWS account by using read-only credentials, review the GuardDuty finding for details about the IAM principal, and attach a DenyAll policy to the IAM identity to stop further activity - Using read-only credentials is appropriate for investigation, but attaching a DenyAll policy is a containment action that changes the environment. That could interrupt the production application if the IAM principal is tied to active workloads or dependent processes. The question specifically requires collecting and analyzing information without affecting the application. Because this option introduces an immediate policy change, it does not satisfy that requirement even though it starts with read-only access.

Sign in to the AWS account by using read-only credentials, open AWS Security Hub to locate the finding, and use a custom action to quarantine the affected IAM identity before gathering additional context - AWS Security Hub can aggregate findings, and custom actions can launch response workflows, which makes this option look operationally capable. However, quarantining the identity is still a containment step that could affect the production application. The requirement is to investigate first without causing impact. This option moves prematurely into response actions instead of focusing on evidence collection and contextual analysis.

Sign in to the AWS account by using read-only credentials, review the GuardDuty finding to identify the API activity involved, and use AWS CloudTrail Insights together with AWS CloudTrail Lake to investigate the related API calls in context - AWS CloudTrail Lake can help query API activity, and CloudTrail Insights can highlight unusual write activity trends, so this option sounds plausible. However, Amazon Detective is the more direct and faster service for investigating a GuardDuty finding in context. CloudTrail Insights is also not the primary tool for analyzing a specific GuardDuty finding end to end. It is better for surfacing anomalous API patterns, whereas Detective is built to investigate GuardDuty findings and related activity relationships more efficiently.

Q) A security engineer is developing an incident response process for EC2 instances that are EBS-backed and have the AWS Systems Manager Agent installed. The process must preserve both volatile and non-volatile memory, update instance metadata with the incident ticket identifier, keep the instance online while isolated from the network, and capture investigative activity during volatile data collection with the least operational overhead.

Which combination of actions should the security engineer recommend to meet these requirements with the least operational overhead? (Select three)

1. Collect instance metadata including tags and metadata service details, enable termination protection on the instance, isolate the instance using security group rules that deny all outbound and inbound traffic, detach the instance from any associated Auto Scaling Group, and deregister the instance from any load balancers

2. Collect instance metadata and tag the instance with incident details, enable termination protection, move the instance to an isolation subnet with Network ACLs configured to deny all traffic, detach from Auto Scaling Group, and deregister from load balancers

3. Use AWS Systems Manager Run Command to execute custom scripts that collect volatile memory data and process information from the running instance, or alternatively establish an interactive SSH or RDP session to run memory collection scripts directly

4. Create an Amazon EBS snapshot from the instance volume and tag the snapshot with incident ticket metadata to preserve non-volatile storage for forensic analysis

5. Create an AWS Systems Manager State Manager association that automatically triggers EBS snapshot creation and applies tags containing metadata and incident ticket information

6. Isolate the instance by modifying the primary network interface and attaching it to a dedicated isolation VPC with no internet gateway or NAT gateway

답: 1,3,5

Correct options:

Collect instance metadata including tags and metadata service details, enable termination protection on the instance, isolate the instance using security group rules that deny all outbound and inbound traffic, detach the instance from any associated Auto Scaling Group, and deregister the instance from any load balancers

This option addresses both isolation and operational continuity: security group rules provide immediate isolation while keeping the instance online for remote investigation access via Systems Manager; termination protection prevents accidental deletion; Auto Scaling Group detachment prevents automatic replacement; and load balancer deregistration removes production traffic. This is more efficient than moving instances between subnets (option B) because security groups are layer-4 controls that can be modified instantly without network reconfiguration.

Use AWS Systems Manager Run Command to execute custom scripts that collect volatile memory data and process information from the running instance, or alternatively establish an interactive SSH or RDP session to run memory collection scripts directly

This option captures volatile memory and process state using Systems Manager Run Command, which executes scripts through the agent without SSH key management overhead. The ability to run scripts directly on the live instance preserves volatile memory that would be lost during snapshot creation. The alternative of SSH/RDP is mentioned to acknowledge that direct interactive sessions are also viable, though Systems Manager Run Command is preferred for operational efficiency and audit logging.

Create an AWS Systems Manager State Manager association that automatically triggers EBS snapshot creation and applies tags containing metadata and incident ticket information

This option automates the non-volatile data collection through State Manager associations, eliminating manual snapshot creation. State Manager automatically tags snapshots with metadata and incident information, reducing human error and ensuring consistent forensic data capture. Automation also reduces the time lag between incident detection and snapshot creation, improving forensic completeness.

Together, these three options preserve both memory types (volatile via live inspection, non-volatile via automated snapshots), maintain online status for investigation, isolate the instance from production traffic, and minimize operational overhead through automation and Systems Manager integration.

Incorrect options:

Collect instance metadata and tag the instance with incident details, enable termination protection, move the instance to an isolation subnet with Network ACLs configured to deny all traffic, detach from Auto Scaling Group, and deregister from load balancers - While this option achieves isolation and data preservation, moving an instance to a different subnet with restrictive NACLs is more operationally intensive than modifying security groups. NACLs require explicit rule creation and subnet migration, adding complexity and potential for misconfiguration. Security groups (option A) provide the same isolation with faster deployment and easier reversal.

Create an Amazon EBS snapshot from the instance volume and tag the snapshot with incident ticket metadata to preserve non-volatile storage for forensic analysis - Creating a single EBS snapshot captures only non-volatile storage at a point-in-time; it does not preserve volatile memory or process information. This option lacks automation, requiring manual invocation for each snapshot. Without Systems Manager State Manager association (option E), the snapshot process is not automated and incident metadata must be applied manually after snapshot creation.

Isolate the instance by modifying the primary network interface and attaching it to a dedicated isolation VPC with no internet gateway or NAT gateway - Moving the instance to an isolation VPC with network interface changes is operationally complex and time-consuming. This approach requires VPC and networking configuration changes, which increases incident response time. Security groups achieve equivalent isolation with minimal operational overhead and are the AWS best practice for rapid containment.