AWS Security

One question per exam domain, 6 in all, each with the answer, the reasoning behind it, and the public source it was written from. Read them here with no account. These are original questions written against the published exam outline, not real exam items.

1. Question 1 · Detection

   Ironvane Systems must prove to an external auditor that the CloudTrail records for a contract period have not been altered or selectively removed since they were delivered to a dedicated S3 bucket in a separate logging account. What should the security engineer configure?

   1. AServer-side encryption of the log bucket with a customer managed AWS KMS key and a key policy restricting decryption
   2. BA bucket policy denying s3:DeleteObject to every principal except the logging account's break-glass role
   3. CS3 Versioning on the log bucket so prior versions of any modified or deleted log object can be recovered intact
   4. DLog file validation on the trail, verifying the delivered digest files, combined with S3 Object Lock in compliance mode
   Show answer and explanation

   Correct answer

   Log file validation on the trail, verifying the delivered digest files, combined with S3 Object Lock in compliance mode

   Log file validation makes CloudTrail write digest files containing hashes of the delivered log files, signed so that any modification or deletion of a log file since delivery can be proven, and Object Lock in compliance mode prevents deletion of the objects during the retention period, so together they provide the cryptographic evidence plus the retention guarantee an auditor asks for. Encryption with a customer managed key protects confidentiality and controls who can read the logs but proves nothing about integrity. Versioning preserves prior copies and helps recovery, yet a principal with sufficient permission can still remove versions and it produces no proof of untampered content. A restrictive bucket policy reduces who can delete but is mutable by an account administrator and again yields no verifiable integrity artifact.

   Source: Validating CloudTrail log file integrity

2. Question 2 · Incident Response

   A university has eradicated a cryptomining compromise caused by an over-permissive EC2 instance profile. The same root cause has appeared twice in 18 months. Which action will do the MOST to reduce recurrence?

   1. APublish an executive summary of the incident timeline and the mining compute cost
   2. BTurn the root cause into a preventive guardrail, such as an SCP and a Config rule
   3. CCreate a GuardDuty suppression rule so this finding type stops paging the on-call team
   4. DExtend CloudTrail log retention so the next investigation has more history to use
   Show answer and explanation

   Correct answer

   Turn the root cause into a preventive guardrail, such as an SCP and a Config rule

   Post-incident activity only pays off when the lesson becomes an enforced control rather than a document. Turning the root cause into a service control policy and a configuration rule prevents the pattern from being recreated, which is what a repeat root cause demands. Longer log retention helps future investigations but leaves the same weakness in place. An executive summary communicates impact and is appropriate, yet communication alone has already failed to stop the second occurrence. Suppressing the finding removes the alarm rather than the condition, and it makes the third occurrence invisible instead of impossible.

   Source: NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations

3. Question 3 · Infrastructure Security

   A developer added DynamoDB permissions to the task execution role of an ECS Fargate service, but the running application still gets access denied when it reads the table. What is the correct fix?

   1. AAdd the DynamoDB permissions to both roles so that whichever identity the SDK happens to select at runtime will succeed.
   2. BStore long-lived access keys for a DynamoDB user in the task definition's environment variables and read them in application code.
   3. CAttach the DynamoDB permissions to the EC2 instance profile of the container host so the running task inherits them at runtime.
   4. DGrant the DynamoDB permissions in the task role, which is the identity the application code assumes, not in the task execution role.
   Show answer and explanation

   Correct answer

   Grant the DynamoDB permissions in the task role, which is the identity the application code assumes, not in the task execution role.

   ECS separates two identities on purpose. The task execution role is used by the ECS agent and the Fargate infrastructure before and around the container, for pulling images and writing logs, while the task role is the identity the credentials provider hands to the application inside the container. Application data access therefore belongs in the task role, and putting it in the execution role grants it to the wrong principal. There is no EC2 instance profile to use under Fargate, and even on EC2 the host role is shared by every task on the instance, which breaks isolation. Duplicating permissions across both roles works by accident while widening the platform role's reach. Static access keys in the task definition are long-lived, visible in the definition and cannot be rotated automatically.

   Source: Amazon ECS task IAM role - Amazon Elastic Container Service Developer Guide

4. Question 4 · Identity and Access Management

   A catalog bucket policy lists about 20 internal account IDs. New accounts keep being left out, and a decommissioned account is still listed. What is the BEST way to simplify this while still limiting access to company accounts?

   1. AReplace the account list with an aws:PrincipalOrgID condition matching the company's organization ID.
   2. BReplace the bucket policy with an SCP at the organization root that allows S3 access to the catalog bucket.
   3. CShare the bucket with the organization through AWS RAM so membership is inherited automatically.
   4. DGrant access to a wildcard principal and rely on an aws:SourceVpce condition for each account's endpoint.
   Show answer and explanation

   Correct answer

   Replace the account list with an aws:PrincipalOrgID condition matching the company's organization ID.

   The principal organization condition key evaluates the organization the caller belongs to, so membership is checked dynamically and a new account is covered the moment it joins while a removed account loses access automatically. Service control policies never grant permissions, so replacing the bucket policy with one would deny everybody. Resource Access Manager does not support S3 buckets. Pinning to VPC endpoint IDs would work only for in-VPC traffic and reintroduces exactly the same per-account list maintenance problem in a less obvious place.

   Source: AWS IAM User Guide: AWS global condition context keys

5. Question 5 · Data Protection

   An RDS master password is stored as a Parameter Store SecureString and rotated manually. An auditor now requires automatic 30-day rotation with no downtime and a record of each rotation. What should the engineer do?

   1. AMove it to AWS Secrets Manager, enable managed rotation, and point the application at the secret
   2. BStore it as a KMS-encrypted S3 object rotated every 30 days by a scheduled Lambda that logs each change
   3. CRun a Systems Manager Automation runbook every 30 days to overwrite the parameter and restart the fleet
   4. DMove the parameter to the advanced tier, whose parameter policies add scheduled rotation
   Show answer and explanation

   Correct answer

   Move it to AWS Secrets Manager, enable managed rotation, and point the application at the secret

   Secrets Manager provides native scheduled rotation for supported databases and uses staging labels so the previous credential stays valid while the new one is created and tested, which is how rotation happens without downtime, and every rotation is recorded. Parameter Store has no rotation capability at any tier: the advanced tier adds larger values, higher throughput and parameter policies for expiration notification, which is the detail that makes that option tempting and wrong. The custom runbook and the Lambda plus S3 design both rebuild a managed capability by hand and typically force the restart the auditor wants eliminated.

   Source: AWS Secrets Manager User Guide: Managed rotation for AWS Secrets Manager secrets

6. Question 6 · Security Foundations and Governance

   Windward Charter Schools keeps logs in CloudWatch Logs set to never expire because retention rules require five years. The bill is now the largest security line item, and operators only query the last two weeks. What is the BEST change?

   1. AMove the log groups to a region with lower per-gigabyte rates and keep the never expire setting
   2. BKeep a short retention in CloudWatch Logs and export the logs to S3, where lifecycle rules archive them
   3. CSample the logs so that only ten percent of events are ingested and stored, cutting volume tenfold
   4. DReduce the log group retention from never expire to exactly five years and accept the remaining cost
   Show answer and explanation

   Correct answer

   Keep a short retention in CloudWatch Logs and export the logs to S3, where lifecycle rules archive them

   Retention and queryability are separate requirements with very different price points, so the right shape is a short hot window where investigators and operators actually work, backed by cheap durable object storage for the long legal tail. Trimming retention to exactly five years is an improvement but keeps five years of data in the most expensive tier, which is the actual cost driver. Sampling destroys the completeness that a retention obligation implies and undermines any investigation. Moving regions shifts the rate marginally, leaves the volume and the storage tier unchanged, and introduces a residency question for no real saving.

   Source: Understanding and managing Amazon S3 storage classes