Task 3.2: Determine a strategy to improve security.

• AStore the password as a SecureString parameter in Parameter Store and have each server read it at startup

  Incorrect

  SecureString parameters are encrypted, but Parameter Store has no built-in rotation, so the 30-day rotation would need custom code.

• BKeep the credentials in AWS Secrets Manager with 30-day automatic rotation and fetch the secret at runtime

  Correct

  Secrets Manager can rotate Amazon RDS credentials automatically on a schedule, updating both the secret and the database, and applications that fetch the secret when they connect pick up the new value.

• CEncrypt the configuration files with an AWS KMS key and replace the files on every server each month

  Incorrect

  The password stays in files on 200 servers, and changing it every month depends on a manual or custom process.

• DPut the password in an environment variable of each server through the instance user data

  Incorrect

  AWS advises against keeping passwords in user data, because anyone with access to the instance can read it, and nothing would rotate the password.

"Out of the code, rotated on a schedule" is Secrets Manager rotation with applications that read the secret at runtime.

• ACreate an IAM Access Analyzer unused access analyzer for the organization

  Correct

  An unused access analyzer reports unused roles, unused access keys and passwords, and unused permissions across the accounts of an organization, and keeps the findings up to date.

• BDownload the IAM credential report from every account each month and compare the results

  Incorrect

  The credential report lists IAM users and the status of their credentials. It does not cover roles or unused permissions.

• CDeploy an AWS Config rule that checks for IAM users with unused credentials in every account

  Incorrect

  A rule about IAM user credentials says nothing about unused roles or the permissions that roles never use.

• DTurn on Amazon GuardDuty in every account and review its IAM findings for unused roles

  Incorrect

  GuardDuty detects suspicious activity and threats. It does not report unused roles or unused permissions.

Unused roles, keys and permissions across an organization are exactly the findings of an IAM Access Analyzer unused access analyzer.

• AReview the AWS Trusted Advisor security group check every week and delete the rules it lists

  Incorrect

  The check can list such rules, but a weekly manual review is neither automatic nor fast enough.

• BTurn on Amazon Inspector and review its network reachability findings for port 22 every day

  Incorrect

  Inspector reports exposure findings, but a daily manual review does not remove the rule within minutes.

• CTurn on CloudTrail Insights so that unusual security group changes raise an event for the security team

  Incorrect

  CloudTrail Insights detects unusual API call rates. It does not evaluate a rule's content or remove it.

• DUse the restricted SSH AWS Config managed rule with automatic remediation by an Automation runbook

  Correct

  AWS Config evaluates security groups when they change, and its automatic remediation can run a Systems Manager Automation document against noncompliant resources, with the evaluation and remediation history kept by Config.

Detect-and-fix of a configuration within minutes is a Config rule with automatic remediation.

• ATurn on VPC Flow Logs for every VPC from which employees reach Amazon S3 and query the records with Athena

  Incorrect

  Flow logs capture information about the IP traffic going to and from network interfaces. They do not show which object was read or which person sent the request.

• BAdd S3 data events for the sensitive bucket to the trail with an advanced event selector on its ARN

  Correct

  Trails do not log data events by default. Object-level operations such as GetObject are S3 data events, and an advanced event selector can limit them to the objects of one bucket.

• CHave the identity provider send the user ID as SAML SourceIdentity and allow sts:SetSourceIdentity in the role trust policy

  Correct

  The SourceIdentity attribute in the SAML assertion sets a value that stays with every request of the role session and cannot be changed during it, and CloudTrail shows it in the userIdentity of the events from that session. The role trust policy must allow sts:SetSourceIdentity, or the role assumption fails.

• DTurn on Amazon GuardDuty S3 Protection in the account so that GuardDuty analyzes every object read in the bucket

  Incorrect

  S3 Protection analyzes S3 data events without needing data event logging on a trail, and it produces findings for potential threats. It does not give the company a record of every read.

• ERecord the bucket in AWS Config and review its configuration timeline to find each read of an object

  Incorrect

  AWS Config records how resources are configured and how those configurations change over time, not reads of the objects in a bucket.

Two gaps need closing. Object reads are data events, which a trail logs only after they are added to it. And because the session names on the shared role do not identify anyone and must stay as they are, the identity provider passes the person's ID as the source identity in the SAML assertion; CloudTrail then shows that value on each action taken in the session, including each GetObject data event.

• ARewrite the key policy to give KeyAdmin only key administration actions and the application role only cryptographic actions

  Correct

  Key policies separate key administrators, who manage the key, from key users, who use it in cryptographic operations, in different statements. Because the policy does not enable IAM policies, the key policy alone decides access, and the key and its ciphertext stay as they are.

• BRemove the application role from the key policy and give it a grant for Encrypt and Decrypt on the key instead

  Incorrect

  Grants let principals use a KMS key in cryptographic operations, often for temporary access, without editing the key policy. They do not take anything away from KeyAdmin, which keeps kms:* and can still decrypt.

• CRe-encrypt the payroll data with the AWS managed keys for Amazon S3 and Amazon RDS and retire the customer managed key

  Incorrect

  Nobody can manage the lifecycle or permissions of an AWS managed key, so KeyAdmin could not manage rotation or deletion, and re-encrypting changes the key and the ciphertext.

• DKeep the policy, and alarm on CloudTrail records of Decrypt calls made by KeyAdmin so that the security team investigates each one

  Incorrect

  CloudTrail records KMS API calls, so an alarm would reveal decryption by KeyAdmin after the fact. It detects rather than prevents, so KeyAdmin would still be able to decrypt payroll data.

The constraints are management without use, use without management, and an unchanged key. Grants add use without removing KeyAdmin's kms:*, an alarm only detects decryption, and AWS managed keys cannot be managed at all and force re-encryption. Splitting the key policy into a key administrators statement and a key users statement meets every constraint.

• AStore the access keys in Secrets Manager with automatic rotation, and have the applications fetch the current keys at startup

  Incorrect

  Secrets Manager can rotate secrets with a Lambda function, but the secrets would still be IAM user access keys, which are long-term credentials, and fetching them means changing the applications.

• BRotate the access keys every 90 days with a scheduled script that writes the new keys into each instance's credentials file

  Incorrect

  Regular rotation shortens the exposure of a leaked key, but access keys remain long-term credentials, and AWS recommends temporary credentials such as IAM roles instead.

• CPass the access keys to each instance as environment variables in the launch template's user data instead of the credentials file

  Incorrect

  The SDK would still find the keys through its credential provider chain, but they would be the same long-term access keys, only stored in a different place on each instance.

• DAttach an IAM role through an instance profile, then delete the credentials files and deactivate the IAM user keys

  Correct

  A role supplies temporary credentials through instance metadata that update automatically before they expire, so no long-term keys are distributed. Once the files are gone, the SDK's provider chain reaches the IMDS provider without code changes.

The constraints are no long-term credentials, automatic renewal and no application change. Secrets Manager rotation and scripted rotation still use IAM user keys, and user data only moves the keys. An instance profile role gives temporary, automatically refreshed credentials, and removing the files lets the default provider chain find them.

• AMore detailed VPC Flow Logs fields

  Incorrect

  Flow logs describe network traffic, not processes or files.

• BGuardDuty Runtime Monitoring for the clusters

  Correct

  Runtime Monitoring analyzes operating system-level, networking and file events to detect potential threats in workloads.

• CAWS Config rules for the clusters

  Incorrect

  Config evaluates resource configuration, not runtime events.

• DAmazon Inspector container image scanning in the registry

  Incorrect

  Image scanning finds vulnerabilities before run time, not suspicious behavior while containers run.

Threat detection from inside running workloads is GuardDuty Runtime Monitoring.

• ATurn on Amazon Inspector Lambda code scanning for the production functions and act on its findings

  Incorrect

  Inspector scans function code and dependencies for vulnerabilities. It reports on code that is already deployed, and it does not stop an unsigned or altered package from being deployed.

• BAdd a manual approval action to the pipeline before the production deployment stage of each function

  Incorrect

  A manual approval stops the pipeline until someone approves, which adds the manual step the team must avoid, and it does nothing about uploads that bypass the pipeline.

• CSign packages in the pipeline with an AWS Signer profile and attach an enforcing Lambda code signing configuration

  Correct

  With a code signing configuration that allows only the pipeline's signing profile and is set to Enforce, Lambda blocks packages that fail the signature checks, and its integrity check rejects any package modified since it was signed.

• DStore build artifacts in an S3 bucket with Object Lock in governance mode so that they cannot be overwritten

  Incorrect

  Object Lock protects stored object versions from being overwritten or deleted. Lambda would still accept a package that someone uploads directly instead of the locked artifact.

The control has to sit at the point where code enters the function, not in the pipeline or the artifact store. Lambda code signing checks every new deployment against the allowed signing profiles and verifies that the package has not changed since it was signed, so direct uploads of unsigned or tampered packages fail while signed releases from the pipeline deploy as before.

• AHave each function call GetSecretValue through the AWS SDK at the start of every invocation to read the current key

  Incorrect

  Reading through the SDK always returns the current value, but it calls the service on every invocation. AWS notes that the caching approaches perform better and cost less than retrieving secrets directly with the SDK.

• BStore the key as a SecureString parameter in Parameter Store, encrypted with a customer managed KMS key

  Incorrect

  A SecureString parameter is stored once and encrypted, but AWS recommends Secrets Manager for API keys because it provides automatic rotation, which Parameter Store does not.

• CRead the key through the AWS Parameters and Secrets Lambda Extension layer added to each function

  Correct

  The extension retrieves and caches secrets without an SDK, and its local cache means a function does not call Secrets Manager on every invocation, which gives better performance and lower cost.

• DKeep the environment variable but encrypt it with a customer managed KMS key that developers cannot use

  Incorrect

  With a customer managed key, only users with access to the key can view the variable, but the key still lives in every function's configuration, in 40 copies, with no rotation.

• EStore the key as a secret in Secrets Manager with a rotation Lambda function that calls the vendor's API every 30 days

  Correct

  Secrets Manager stores secrets centrally and encrypted, and for secrets that are not managed by an AWS service, rotation uses a Lambda function that updates the secret and the external service on a schedule.

The constraints are one encrypted copy, automatic 30-day rotation, nothing in function configuration, and cached low-latency reads without new code. Secrets Manager with a rotation function covers storage and rotation, and the Lambda extension supplies cached reads. SDK calls on every invocation add latency and cost, SecureString parameters do not rotate, and an encrypted environment variable stays in each function.