AWS Certified Security Specialty SCS-C02 (SCS-C02) — Questions 1051–1125

Replacing the instance's security group with one that has no inbound or outbound rules immediately severs network paths used for command-and-control, data exfiltration, and lateral movement while the operating system keeps running. Security groups act as a stateful virtual firewall, so removing all allow rules drops existing connections and blocks new ones without terminating the instance. This containment preserves volatile memory and disk state for subsequent forensic collection, making it the correct first response.

Seeing `SSEAlgorithm: AES256` in the bucket encryption response means default encryption is enabled with SSE-S3, where Amazon S3 manages the encryption keys. This configuration causes new objects written to the bucket to be automatically encrypted at rest with 256-bit AES using S3-managed keys, and the setting is stored as a bucket-level default rather than applied individually per object.

Use a rate-based rule in COUNT mode so WAF evaluates the request rate and increments the relevant counters without blocking traffic. This exposes the per-IP distribution in CloudWatch metrics and sampled requests, letting you determine a burst threshold that separates human usage from automated floods. The count data then informs a custom rule (e.g., with an aggregate key or scope-down statement) that blocks only when the observed rate genuinely exceeds your normal baseline, minimizing false positives.

A NAT gateway is a fully managed AWS service that performs source network address translation, replacing private IPv4 addresses with its own Elastic IP for outbound internet traffic. Because it is stateful, it automatically drops any unsolicited inbound connections initiated from the internet, so it satisfies the security requirement of blocking inbound while enabling outbound. It also scales automatically and requires no patching or maintenance, making it the recommended choice.

An SCP placed on the root organizational unit applies as a permission boundary to every account and principal in the organization, including each account's root user, so a deny of cloudtrail:StopLogging, cloudtrail:DeleteTrail, s3:DeleteBucket, and s3:DeleteObject makes tampering impossible even for administrators. The organizational trail, enabled from the management account, automatically collects events from all member accounts and cannot be stopped or disabled by any individual account. Together these controls enforce both protection of the audit trail and preservation of the log files, satisfying the requirement for a preventive solution.

An explicit deny in any applicable policy, such as a service control policy (SCP) attached to an organizational unit or a permissions boundary on the IAM principal, overrides any allow in the user's own IAM policy. During policy evaluation, AWS determines the final decision by first considering all applicable policies and applying the rule that an explicit deny takes precedence over any allow. Even if the user's policy grants s3:GetObject, the explicit deny in the SCP or boundary will cause the request to fail with an access denied error. To resolve this, the security engineer must identify and modify the deny statement or remove the restricting boundary.

Port 443 is HTTPS, the default port for encrypted web traffic using TLS. Because the instance is intended to serve a public website, allowing inbound TCP 443 from 0.0.0.0/0 lets internet clients reach the service securely while security groups remain stateful, automatically permitting return traffic. This rule aligns with the stated requirement and is the correct enablement for a web server receiving secure browser connections.

AWS Config records resource configuration changes as configuration items, generating a complete history that can be compared against baseline rules. For PCI DSS, it demonstrates compliance with configuration standards (e.g., Requirement 2) by detecting drift from approved settings, such as security group changes or unencrypted storage. This detective control is essential for proving that system configurations are maintained and reviewed.

AWS CloudTrail records every S3 management and data event, including the IAM user or role, sourceIPAddress, userAgent, event name, and request parameters, and it delivers these logs as gzipped JSON to an S3 bucket. Amazon Athena can run SQL queries directly against that CloudTrail log set, allowing you to quickly filter for a specific user's API calls over a time range and correlate source IPs, user agents, and event names to determine the scope of the breach. This is the standard, authoritative method for investigating API-level activity after an incident.

Amazon GuardDuty is a threat detection service that continuously analyzes AWS CloudTrail management and data events, VPC Flow Logs, and DNS logs using machine learning and integrated threat intelligence. It specifically detects suspicious S3 access patterns, such as unusual geographical locations, high-volume downloads, or bucket enumeration, and raises findings that can be sent to Amazon EventBridge. This enables automated remediation, for example a Lambda function that revokes IAM policies or applies a bucket policy, making it the correct choice for detecting and automating response to access threats.

CloudTrail captures every API call across all accounts and delivers a tamper-evident log to the centralized S3 bucket, with default encryption protecting it at rest. Amazon GuardDuty, enabled in all accounts, continuously analyzes CloudTrail events along with VPC Flow Logs and DNS logs using machine learning and threat intelligence to detect anomalies such as compromised credentials or unusual API sequences. S3 server access logs provide object-level request logging for the centralized bucket itself. Together these components deliver both comprehensive API activity logging and proactive ML-based anomaly detection across the organization.

When the destination bucket for S3 server access logs uses SSE-KMS, the S3 log delivery service (logging.s3.amazonaws.com) must be explicitly allowed to use that KMS key to encrypt the log objects it writes. This is done by adding a bucket policy on the destination bucket that grants kms:GenerateDataKey and kms:Encrypt (as well as s3:PutObject) to the log delivery service. Additionally, the KMS key policy must also allow this service principal to use the key; otherwise, log delivery will fail with an access denied error. This is a required step, so this is the correct answer.

Macie automatically discovers sensitive data using managed data identifiers and also evaluates S3 bucket policies and ACLs for public access. It runs automated discovery jobs on a schedule, and you can use CloudWatch Events to trigger alerts for both sensitive data findings and policy findings. This combines content discovery with access control verification, addressing both dimensions of the requirement.

An instance profile is the container that delivers an IAM role's temporary credentials to EC2 via the instance metadata service. Auto Scaling groups reference the profile in their launch template, so each launched instance automatically assumes the role.

IAM decisions are made by evaluating all statements: if any applicable Deny statement matches the request, the result is Deny regardless of any matching Allow. Here, the Deny statement's condition is satisfied by the request, and because explicit Deny statements cannot be overridden by Allows, the effective decision is denied. This is not due to a default deny or missing allow, but an active, matching Deny.

AWS DMS has native support for SSL/TLS encryption between the replication instance and both the source and target endpoints. For each endpoint, you can specify an SSL mode (e.g., require for Oracle, SQL Server, and PostgreSQL, or verify-ca for Aurora MySQL) so that all data transferred between the database and DMS is encrypted in transit. With SSL enabled, DMS negotiates an encrypted connection directly with the database engines, ensuring data is protected without relying on additional VPN or network manipulation. This is the most direct and appropriate way to encrypt migration traffic in AWS DMS.

An AWS Site-to-Site VPN uses IPsec to encrypt traffic between the on-premises data centre and AWS, satisfying the in-transit encryption requirement for data moving to Amazon S3. IPsec provides cryptographic protection at the network layer, covering all traffic over the connection without application changes.

The AuthorizeSecurityGroupIngress call is adding a rule allowing TCP port 22 (SSH) from CIDR 0.0.0.0/0. A CIDR of 0.0.0.0/0 represents all possible IPv4 addresses, meaning any host on the internet can attempt to connect to port 22 on the associated instances. This effectively exposes SSH to the world, which is a critical security risk because it invites brute-force attacks and unauthorized access attempts.

AWS Organizations is the correct service for centrally managing multiple accounts and applying service control policies (SCPs) that place guardrails on the maximum permissions available to IAM principals within member accounts. SCPs act as a policy filter, allowing you to forbid or allow specific AWS services and actions at the organizational, organizational unit, or account level without modifying the IAM policies themselves. This makes Organizations a central control plane for permission boundaries across an entire AWS environment.

The most common cause of consistently rejected MFA codes is clock drift between the authenticator device and AWS’s TOTP server, so the 30-second time window computed by the device does not match AWS’s window. AWS compares the presented code with codes for the current time step and an allowed clock skew; if the device’s time is off by more than the skew, even a freshly generated code will fail. To fix this, synchronize the device clock (or re-register the MFA device), which is why 'MFA device is not properly synchronized with AWS' correctly describes the failure.

AWS Config conformance packs aggregate a pack of rules plus associated remediation actions, deployable across an entire AWS Organization from a single managed template. For a public S3 bucket, the included rule (e.g., s3-bucket-public-read-prohibited) detects noncompliance and automatically invokes an SSM Automation document, such as AWS-DisablePublicReadAccessForS3Bucket, to remove public access. This provides centralized, scalable, and fully automated governance rather than per-account, manual, or report-only controls.

CloudTrail delivers log files via the S3 `PutObject` API, but it does not set the `x-amz-acl` request header or the `bucket-owner-full-control` canned ACL unless the trail is explicitly configured for that behavior. If the bucket policy uses a `StringEquals` condition on `s3:x-amz-acl`, every PutObject request from CloudTrail will not match the condition and is denied before the write can occur. Removing that condition allows the PutObject action to succeed; use a condition on `aws:SourceArn` or `aws:SourceAccount` instead to scope the trust.

A gateway VPC endpoint for S3 is the correct solution because it provides private connectivity from the VPC to S3 without requiring an Internet Gateway, NAT Gateway, or public IP address. It is implemented as a route-table entry using a prefix list for S3, directing traffic to the S3 service over the AWS private network. This endpoint does not incur per-hour or data-processing charges, and it keeps traffic entirely within AWS, satisfying both security and cost-efficiency requirements.

If the policy permits PutObject without requiring the s3:x-amz-server-side-encryption header or a condition that forces encryption, clients can upload objects in plaintext to S3. Although the company uses KMS for encryption, that KMS key is only used when the upload explicitly requests SSE-KMS or the bucket has default encryption and the client doesn't override it. Without an explicit Deny for unencrypted uploads, some objects may remain unencrypted at rest, defeating the company's stated security intent.

A KMS key policy that explicitly lists the IAM role as Principal, optionally with a condition like aws:PrincipalArn, correctly restricts kms:Decrypt to that role. Key policies are the authoritative control for a KMS key, and when they grant access to a specific principal, IAM policies are not required for that identity to decrypt. This is the recommended approach when the desired access is limited to a particular role and you want the key policy to be self-contained and auditable. Since the key policy is evaluated first and any IAM allow is subordinate to it, this configuration unambiguously enforces the intended restriction.

AWS WAF's AWSManagedRulesSQLiRuleSet is a managed rule group specifically designed to detect and block SQL injection attempts by inspecting request components such as query strings, body, and headers. It uses curated signatures and pattern-matching to catch syntactic SQLi payloads, and you can associate it with your web ACL on the Application Load Balancer, CloudFront, or API Gateway. Enabling this rule directly addresses the reported vulnerability.

An S3 bucket policy with an aws:SourceVpc condition is the correct way to restrict access to requests originating from a specific VPC. This condition evaluates the VPC ID of the requester, which is available when the request comes through a VPC gateway endpoint (service: s3). It is a resource-based policy, meaning it applies directly to the S3 bucket regardless of which IAM principal makes the request, and is a standard pattern for keeping buckets private to a particular VPC.

Amazon GuardDuty is a threat detection service that uses machine learning, anomaly detection, and integrated threat intelligence to continuously monitor for malicious activity. It ingests and analyzes AWS CloudTrail event logs, VPC flow logs, and DNS logs to identify suspicious patterns, including unusual S3 access, credential compromise, or unauthorized API usage. GuardDuty generates findings that indicate potential security threats, making it a direct and effective tool for detecting unauthorized access.

CloudTrail's management event selector controls whether read-only API calls are captured; if the trail is configured as 'Write-only', then actions like `ec2:DescribeInstances` are omitted. Even though the console default for a new trail is to log both read and write events, an existing trail may have been changed to write-only, and that setting is a common cause of missing read activity. To record these calls, the trail must be explicitly set to log 'Read' or 'All' management events.

A CloudWatch Events rule (now Amazon EventBridge) can define an event pattern that matches the exact API call, because CloudTrail delivers all AWS API events as CloudWatch Events in near real-time. When the event matches, the rule triggers an SNS topic to send a notification. This provides immediate, event-driven alerting without the delay of log aggregation, querying, or metric filters.

Referencing the previous tier's security group as the source in an inbound rule is the correct approach because security groups are stateful and allow logical references to other security groups, not just IP addresses. When you assign an instance to the source security group, it automatically becomes allowed to reach the target tier, even if its IP address changes or new instances are added. This eliminates the need to manage CIDR blocks or public IPs and keeps security policies tightly aligned with architectural tiers. It is the AWS-recommended pattern for multi-tier security group design.

Configure the key policy with a Deny statement that uses the aws:PrincipalAccount condition to block any principal whose account ID does not match the expected account. Since the key policy is the authoritative resource-based policy for the KMS key, an explicit deny overrides any IAM permissions in another account and prevents cross-account EBS volume or snapshot sharing. This directly enforces the desired account boundary.

Setting `require_secure_transport=1` on MySQL or `rds.force_ssl=1` on PostgreSQL in the RDS parameter group makes the server reject any non-TLS connection, explicitly enforcing encryption at the database layer. This server-side configuration is authoritative: only TLS-enabled clients with the appropriate CA certificate can connect, so plaintext traffic is refused regardless of client-side settings.

AWS CloudFormation Guard is a policy-as-code engine that parses and evaluates a template's structure before deployment, allowing you to assert that every resource includes a specific tag key with an allowed value. This validation is proactive, occurring in the CI/CD pipeline prior to stack creation, so non-compliant templates are rejected before any infrastructure exists. Guard rules are written in a simple DSL and can be enforced alongside other template checks, making it the only option that directly inspects the template content rather than relying on API request conditions.

SSE-S3 encrypts each object with a unique key, itself encrypted by a regularly rotated root key managed entirely by AWS, using AES-256. It satisfies data-at-rest protection with no key management overhead, applied by default to every uploaded object.

This is the recommended multi-account design. By designating a delegated administrator through AWS Organizations, the admin account can enable GuardDuty across every member account with a single action and receives a consolidated view of all findings in the GuardDuty console and via the API. The delegated administrator also gains centralized control to manage member accounts, apply trusted IP lists, configure threat list filters, and create suppression rules for the entire organization. This integration is natively built into GuardDuty, so no custom IAM roles or log-forwarding pipelines are required to aggregate findings.

The rule permits TCP port 80 from 0.0.0.0/0, so any host on the internet can reach the group's instances over unencrypted HTTP. That source range is the axis distinguishing public exposure from a restricted CIDR.

AWS CloudTrail records every API call made to AWS services, capturing details such as the identity, time, source IP, and request parameters. By sending these event logs to Amazon CloudWatch Events (or Amazon EventBridge), you can create custom rules to match specific API activity, such as unusual calls or attempts from unexpected regions, and trigger alerts via SNS or AWS Lambda. This combination gives you direct, real-time, and customizable detection and alerting on the API calls themselves, making it the correct choice.

Configuring an HTTPS listener and an HTTPS target group encrypts traffic at both hops, including the ALB-to-target leg. This satisfies the requirement for in-transit encryption between load balancer and targets, since the default HTTP target protocol leaves that segment unencrypted.

SSE-C allows you to provide your own encryption keys in S3 API request headers, and S3 uses them for AES-256 encryption/decryption but never stores the key material, giving you full control over the key lifecycle. Storing those keys in AWS Secrets Manager adds secure storage, centralizes access control, and enables programmatic retrieval for uploads/downloads while keeping the key material customer-owned. This directly satisfies a bring-your-own-key requirement without the overhead of client-side encryption, though you must use HTTPS and supply the key on every request.

CloudTrail trails can be updated at any time to include data events for specific S3 buckets or all buckets, capturing object-level operations such as GetObject, PutObject, and DeleteObject in addition to the existing management events. This consolidates all API activity into a single audit stream, avoids the operational overhead of managing multiple trails, and is the direct, recommended way to meet the requirement for S3 access logging within CloudTrail.

AWS Config's managed rule s3-bucket-server-side-encryption-enabled continuously evaluates each bucket and flags any bucket whose default encryption setting is disabled. When non-compliance is detected, the rule can trigger an SSM Automation remediation—typically the AWS-EnableS3BucketEncryption document—which automatically applies the appropriate SSE-S3 or SSE-KMS default encryption to the bucket. This pairing of continuous detection and automated remediation provides an enforceable, organization-wide corrective control that directly satisfies the encryption requirement.

Modifying the security group to deny inbound SSH from the attacking IPs directly blocks the SSH brute force attempts at the instance level. Since the instance uses a security group that can be applied to all instances in the Auto Scaling group, this approach is effective and persistent.

Setting the source of the app-sg inbound rule to the alb-sg security group creates an identity-based dependency: only traffic originating from network interfaces associated with alb-sg is permitted. This automatically accommodates ALB node IP changes and scale events because AWS resolves the security group relationship in the VPC. It is a best practice for internal load-balanced architectures and is preferred over CIDR/ENI references since it remains valid across AZs and lifecycle changes.

The IAM password policy is the account-level setting designed to enforce password requirements for all IAM users. It lets you require minimum length, uppercase/lowercase letters, numbers, non-alphanumeric characters, password expiration, and prevent password reuse, and users see the requirements during sign-in. Because this policy is applied natively by the IAM service during authentication and password changes, it exactly matches the security policy described.

S3 Glacier Deep Archive is the correct choice for 7-year security log retention because it provides the lowest storage cost of any S3 storage class, designed specifically for long-term, rarely accessed archival data. It offers 99.999999999% durability across multiple Availability Zones and a standard retrieval time of 12 hours, which is acceptable for compliance-oriented logs that are seldom retrieved. The one-time retrieval fee and minimum 180-day storage period are outweighed by the dramatic per-GB savings over the full 7-year cycle.

GuardDuty publishes every finding as an event to Amazon EventBridge, where a rule with an event pattern matching specific finding types and severities can route to a Lambda function. That function can call ec2:RevokeSecurityGroupIngress or ec2:ModifyNetworkInterfaceAttribute to swap the instance onto a dedicated quarantine security group, removing internet-facing ingress rules. This approach is targeted to the exact resource in the finding, reversible, and scales across many findings without affecting the rest of the subnet.

AWS CloudTrail is an audit service that continuously records all API activity in an AWS account, capturing the calling identity, source IP address, timestamp, request parameters, and response elements. CloudTrail itself is not a threat-detection engine—it simply produces the raw audit logs—but it is a required and correct component because it provides the management-event data that GuardDuty consumes to detect suspicious API calls. Enabling CloudTrail is the necessary first step, and when paired with GuardDuty's analysis engine, it becomes part of a complete detection solution.

Amazon Athena is serverless and lets you run standard SQL directly against VPC Flow Logs stored in S3, requiring no ETL or infrastructure to manage. By partitioning the logs in S3—for example by year/month/day or by hour—you drastically reduce the amount of data scanned per query, and Athena charges per byte scanned, so partitioning cuts costs substantially. Athena is built on Presto, supports filtering, grouping, and joins, and is well suited for ad-hoc security investigations over large volumes of network traffic.

The aws:SecureTransport condition key is a boolean that is true only when the request is made over SSL/TLS. By attaching a bucket policy with a Deny effect when aws:SecureTransport is false, the bucket rejects every HTTP request and only allows HTTPS requests. This enforces encryption in transit for all S3 operations, including direct API calls from any client or SDK, making it the correct solution.

An S3 lifecycle policy can transition delivered log objects from frequently accessed storage classes to S3 Glacier after one year, preserving the logs for long-term audit needs while reducing cost. This is a correct component for the retention half of the requirement, provided that a delivery mechanism such as an organization CloudTrail trail first places the logs into the S3 bucket. It does not record any API activity by itself, so it is complementary to CloudTrail rather than a replacement.

The inline policy allows SSM StartSession only on tagged instances, but since the group policy allows all actions, the effective permission is still 'Allow' on all instances. To restrict, a 'Deny' statement is needed for instances without the tag.

AWS Network Firewall inspects inbound, outbound and east-west traffic using Suricata-compatible stateful rules, enabling signature-based detection of malicious activity across VPC subnets. It satisfies the monitoring requirement by logging alerts and flow data to CloudWatch, S3 or Kinesis Firehose, giving the visibility needed to identify threats rather than merely filtering them.

AWS Config rules continuously evaluate bucket public access settings and flag noncompliant resources, triggering remediation. Lambda or SSM Automation then applies the block public access configuration automatically, satisfying both continuous monitoring and automatic remediation requirements.

Creating an organization trail in the management account (with isOrganizationTrail set to true) automatically provisions CloudTrail for every current and future member account in AWS Organizations, delivering logs to a single central S3 bucket. Member account users—even those with administrative rights—cannot disable or alter the trail because ownership rests with the management account, eliminating the need for per-account configuration or remediation. This native, centralized governance model is exactly why recommended architectures consistently select this option over per-account scripts, roles, or Config checks.

By creating an IAM role in the target account with read-only permissions to the S3 bucket, the application can use the EC2 instance's existing instance profile role to assume that role via STS AssumeRole. The target account role's trust policy must explicitly allow the EC2 instance role as a principal, and the instance role needs sts:AssumeRole permission. This yields temporary security credentials, avoids storing long-term keys, and adheres to least-privilege cross-account access.

RDS natively supports SSL/TLS for encrypting the connection between a client and your database. You must set the database parameter group to require a secure connection (for example, 'require_secure_transport=ON' for MySQL, or use the rds-force-ssl-parameter for PostgreSQL) and then modify your application's connection string to use SSL mode, pointing to the RDS CA certificate. This ensures that all SQL queries, result sets, and authentication data are encrypted in transit, directly satisfying the requirement.

The IAM users in Account A must have an identity-based policy that explicitly grants the sts:AssumeRole action against the role ARN in Account B. Without this allow, the AssumeRole API call is denied even if the trust policy in Account B permits the user, because IAM policies are evaluated by default-deny. The policy should specify the exact role ARN in the Resource element, for example arn:aws:iam::AccountB:role/CrossAccountRole.

CloudTrail log file validation creates a SHA-256 hash of each log file and stores it in a digest file in the same S3 bucket. When enabled, you can use the AWS CLI or API to validate that log files were not modified or deleted after delivery. It uses a private key to sign the digest files, providing cryptographic assurance that the logs themselves are authentic and intact. This directly detects any tampering with log integrity, unlike the other options.

IAM policies define which actions an identity may perform on which resources; listing only the required actions means any unlisted API call is implicitly denied. This directly enforces least privilege at the identity-policy layer, satisfying the stem's requirement to grant no more than the task needs.

AWS IAM Identity Center (successor to AWS SSO) is designed precisely for centralized management of workforce user access to multiple AWS accounts. It connects to external identity providers like Okta, Azure AD, or its own built-in identity store, and assigns users and groups to accounts using permission sets that define granular IAM permissions. With IAM Identity Center, an organization can manage one user directory and control sign-in across all accounts, complete with MFA and auditing, eliminating the need to create IAM users in each account.

Security groups provide stateful, instance-level filtering of inbound and outbound traffic, allowing least-privilege rules per workload. This satisfies the EC2 hardening requirement by restricting which ports and sources can reach each instance, unlike subnet-level NACLs alone.

The s3:x-amz-server-side-encryption condition key only verifies that server-side encryption was requested or applied, typically checking the value such as AES256 or aws:kms, but it does not identify which AWS KMS key was used. This condition can ensure that objects are encrypted, but it cannot distinguish between different KMS keys, so it is insufficient for restricting access to objects encrypted with a specific KMS key. The requirement specifically calls for enforcing a particular KMS key, which requires a more granular condition key like s3:x-amz-server-side-encryption-aws-kms-key-id.

A key policy is the resource-based policy that governs access to a KMS key. Adding an explicit Deny statement for the kms:ScheduleKeyDeletion action prevents any principal—including IAM users, roles, or the account root—from scheduling the key for deletion, because an explicit Deny overrides any Allow. This makes the key effectively non-deletable through the normal API, assuming the key policy itself cannot be altered by unauthorized principals.

This is the documented pattern for aggregating CloudTrail logs: the bucket policy grants s3:PutObject (and s3:GetBucketAcl if not using bucket owner enforcement) to the CloudTrail service principal, and the aws:SourceAccount condition restricts the service request to CloudTrail accounts explicitly allowed. The service principal cloudtrail.amazonaws.com prevents individuals or other AWS services from writing, while the condition blocks confused-deputy attacks from accounts not in the allow list. The central account then receives trail logs from all member accounts.

CloudTrail log file integrity validation delivers a tamper-evident chain by hashing each log file with SHA-256, digitally signing the digest with a private key, and storing those digest files in the same delivery bucket. During validation, CloudTrail compares file hashes and signatures, so any modification, deletion, or replacement of delivered logs is detected, even if someone has access to the bucket. This directly addresses the requirement to prove that CloudTrail logs have not been altered.

Gateway endpoints for S3 and interface endpoints for CloudWatch Logs keep that traffic on the AWS network, so no NAT gateway is needed. Interface endpoints use elastic network interfaces with security groups, so permitting HTTPS from the Lambda function's security group is required for the logs path to succeed.

The trust policy in the role should list the vendor's AWS account as a principal, allowing that account's users or roles to call sts:AssumeRole. The role's permissions policy then grants only s3:* on 'vendor-bucket' (e.g., arn:aws:s3:::vendor-bucket and arn:aws:s3:::vendor-bucket/*), adhering to least privilege. A bucket policy that explicitly allows the role can be added to make the resource-based authorization unambiguous and to satisfy any governance requirement that the bucket owner also approve access.

GuardDuty publishes every finding as an event to the default EventBridge event bus with a source of 'aws.guardduty' and a detail-type of 'GuardDuty Finding'. A rule with an event pattern that filters on either the source or the detail-type gives you a flexible, event-driven trigger point for incident response. This approach is direct, near-real-time, and requires no extra services or log processing to detect a new security finding.

Security groups act as a stateful virtual firewall attached to Elastic Network Interfaces, allowing you to define allow rules for inbound and outbound traffic. Stateful means return traffic is automatically permitted for an allowed request, and you can only specify allow rules—there is no explicit deny—so managing per-instance traffic at the protocol, port, and source/destination CIDR is the core instance-level measure. This is a foundational VPC security control that directly filters traffic before it reaches an instance.

The request does not satisfy the condition placed on the Allow, so the policy engine cannot produce an effective Allow for this operation. AWS evaluates IAM condition blocks as part of determining whether a statement applies, and a false condition causes the statement to be skipped entirely. Consequently, the s3:GetObject action is denied by default even though the statement text appears to authorize the action.

AWS Config conformance packs bundle multiple managed or custom Config rules and remediation actions into a single CloudFormation template, and when deployed from the management account using CloudFormation StackSets, they are automatically applied to every target member account and Region. This leverages native AWS Organizations integration, so rules are provisioned consistently without manual per-account steps, and any updates to the conformance pack template can be rolled out centrally. With organization conformance packs, AWS Config manages the deployment across all accounts, making this a fully managed, scalable solution for enforcing security group compliance.

Launching an isolated test instance from the AMI prevents any risk to production resources while allowing deep inspection. Amazon Inspector automatically assesses the instance for software vulnerabilities and unintended network exposure, producing a prioritized list of findings. This approach gives a clean, controlled environment for forensics without altering the original evidence.

AWS Security Token Service (STS) is the correct service because it explicitly issues temporary, limited-privilege credentials—typically an access key ID, a secret access key, and a session token—with configurable durations (15 minutes to 12 hours). For a mobile app that needs scoped permissions without embedding permanent keys, STS operations like AssumeRole or GetFederationToken are the direct mechanism, and the returned credentials are automatically expired, reducing risk of long-term exposure.

S3 Object Lock in compliance mode prevents objects from being deleted or overwritten for a specified retention period, even by the root user. This protects CloudTrail logs from tampering or deletion, satisfying the immutability requirement. It is a strong control that ensures logs cannot be altered, which is critical for security and compliance.