Design Secure Architectures: free practice questions

Option B is a common real-world issue: if the bucket policy is updated to remove CloudTrail's write permission, CloudTrail silently fails to deliver logs (it will display delivery errors in the console). Option C (trail stopped or deleted) is the most direct cause — no trail means no log delivery. Option A is incorrect — Block Public Access prevents public ACLs and policies but does not block CloudTrail's service-principal writes, which use a bucket policy grant. Option D is incorrect — CloudTrail logs all API calls regardless of credential type, including temporary credentials. Option E is incorrect — CloudTrail does not automatically change log destinations; the trail configuration is static until manually changed. Option F is incorrect — KMS key rotation replaces the key material for future encryption but does not invalidate existing encrypted objects or prevent new writes; CloudTrail would continue writing logs.

Option B is correct because RDS does not support enabling encryption on an existing unencrypted instance in place. The supported process is: (1) take an unencrypted snapshot, (2) copy that snapshot and enable encryption with a KMS key during the copy operation, and (3) restore a new encrypted RDS instance from the encrypted snapshot. This is the AWS-documented migration path. Option A is incorrect because RDS does not allow you to enable encryption on an existing instance after creation — this setting is immutable and cannot be changed via a modify operation. Option C is incorrect because while DMS is a valid migration tool and could work, the question asks for minimal downtime and the snapshot copy/restore method is simpler, lower-cost, and more straightforward than setting up a DMS task for this specific use case. Additionally, enabling SSL on the source doesn't encrypt data at rest. Option D is incorrect because Amazon Macie is a data discovery and classification service for S3 — it does not support RDS, does not inspect RDS data, and has no capability to encrypt RDS instances.

IAM authorization with SigV4 signed requests provides strong, credential-based authentication for partner systems. API keys tied to separate usage plans allow per-partner throttling and quota tracking — exactly what the requirements specify. Option B (ALB with IP filtering) does not provide per-partner identity tracking and IP ranges can change or be spoofed; ALBs also do not natively integrate with API Gateway for throttle tracking. Option C uses a shared secret (weak: single compromise affects all partners) and a single usage plan means throttle limits cannot be differentiated per partner. Option D (resource-based policy by account ID) is appropriate for intra-AWS integrations but many external partners do not have AWS accounts; WAF rate limiting is aggregate and not per-partner without custom rule sets.

Option B is correct because AWS Secrets Manager is purpose-built for secrets management with native automatic rotation support. It provides built-in Lambda rotation functions for popular database engines (RDS MySQL, PostgreSQL, etc.), runs rotation automatically on a configurable schedule without application code changes, and the GetSecretValue SDK call retrieves the latest version seamlessly — the application always gets current credentials without modification. Option A is incorrect because Parameter Store (Standard tier) does not have native automatic rotation; the EventBridge + Lambda approach described requires custom rotation code and ongoing maintenance, does not update the parameter atomically with the database credential change, and is more operationally complex than Secrets Manager. Option C is incorrect because KMS is an encryption key management service — it does not store application secrets or credentials, and GenerateDataKey generates data encryption keys for envelope encryption, not a mechanism to retrieve database passwords. Option D is incorrect because storing credentials in S3 objects and rotating them via Lambda is a fragile custom solution that involves race conditions (what if the app reads mid-rotation?), requires application code to fetch and parse objects, and has higher latency than Secrets Manager's regional API endpoint.

Option B is correct because cross-account IAM role assumption is the standard AWS mechanism for granting third-party access. The trust policy restricts which external accounts can assume the role, no long-term credentials are issued to the auditors, all role assumptions are logged by CloudTrail (with sts:AssumeRole events), and the policy can be narrowly scoped to read-only actions on Config and CloudTrail only — satisfying least privilege and operational efficiency. Option A is incorrect because creating IAM users with access keys generates long-term credentials that are harder to revoke, must be rotated, and are not tied to the auditors' own identity management practices. Option C is incorrect because exporting logs to S3 and using presigned URLs provides only delayed/batch access to historical data, not real-time configuration review capability, and requires significant ongoing automation effort. Option D is incorrect because AWS Resource Access Manager (RAM) is used to share specific resource types (like Transit Gateways, subnets, etc.) across accounts — it cannot share account-level credentials and has nothing to do with root account credential sharing, which is an extreme security anti-pattern.