Design Secure Architectures practice questions

Answer: A) Enable S3 Versioning on the bucket and configure MFA delete

S3 Versioning keeps prior versions when objects are overwritten or deleted, so they can be restored. MFA delete adds a second factor before versions can be permanently deleted or versioning can be changed. Encryption, Block Public Access, and Inventory don't keep previous object content.

• AWith versioning, an overwrite creates a new version and the previous version can still be restored. A delete adds a delete marker instead of removing the data. MFA delete requires a second authentication factor to permanently delete a version or change the bucket's versioning state.
• BEncryption protects data confidentiality at rest. An authorized writer can still overwrite an encrypted object, and the previous content is not kept.
• CBlock Public Access stops public exposure through ACLs and policies. It does nothing about overwrites by an application or by credentialed principals, and it keeps no prior copies.
• DS3 Inventory lists objects and their metadata. It does not keep object contents, so overwritten data can't be restored from it.

Answer: A) Take a snapshot, copy the snapshot with encryption enabled (choosing a KMS key), and restore a new instance from the encrypted snapshot, then cut over

You cannot enable encryption on an existing unencrypted RDS instance in place — you take an encrypted copy and restore.

• AEncryption is set at creation; the supported path is snapshot → encrypted copy → restore, followed by repointing the application to the new endpoint.
• BThere is no in-place toggle to encrypt an existing unencrypted RDS instance.
• CRDS storage isn't managed as customer-attached EBS volumes you can swap.
• DShield is DDoS protection and has nothing to do with encryption at rest.

Answer: A) Allow s3:ListBucket on arn:aws:s3:::orders-prod, and allow s3:GetObject and s3:PutObject on arn:aws:s3:::orders-prod/*

In S3 policies, bucket-level actions such as s3:ListBucket take the bucket ARN, and object-level actions such as s3:GetObject and s3:PutObject take the bucket/* ARN. Least privilege means granting only the needed actions, each on its matching resource, and not extra actions such as s3:DeleteObject.

• ACorrect. s3:ListBucket is a bucket-level action, so its resource is the bucket ARN. s3:GetObject and s3:PutObject are object-level actions, so their resource is the object ARN (bucket/*). The policy grants exactly the three actions the application needs.
• BIncorrect. s3:ListBucket applies to the bucket resource, and the object ARN pattern (bucket/*) does not match it. The application could read and write objects but could not list the bucket.
• CIncorrect. The resource scoping is correct, but the policy also grants s3:DeleteObject. The application is not allowed to delete objects, so this breaks least privilege.
• DIncorrect. This allows listing, reading, and writing. It also allows deleting objects and changing bucket settings such as the bucket policy, which is far more than the application needs.

Answer: A) Create an IAM role in the data-lake account that the analytics account can assume, scoped to the specific bucket and prefixes

• AA cross-account role with a trust policy and least-privilege permissions grants temporary, auditable access without sharing long-term keys.
• BPublic buckets expose data to everyone, and header filtering is trivially spoofed.
• CSharing static credentials by email is insecure and hard to rotate or audit.
• DObject ACLs are legacy, error-prone, and AWS recommends against relying on them for cross-account access.

Answer: A) Add the allowed principals (partner account IDs or IAM ARNs) to the endpoint service's allow list, and optionally require manual acceptance of each connection request

• AAn endpoint service has an allow list of principals permitted to create interface endpoints to it, plus an option to require the service owner to accept connection requests.
• BThat would expose the service publicly rather than privately to named partners.
• CVPC peering connects whole networks and doesn't scope access to a single service the way PrivateLink does.
• DSecurity groups reference CIDRs or other security groups, not account IDs, and can't gate PrivateLink connections.

Answer: A) Create an IAM role with a trust policy naming the partner account and a permissions policy scoped to the bucket; the partner's principals call sts:AssumeRole

A cross-account IAM role lets the partner's principals get temporary STS credentials scoped to the bucket, with no long-term credentials created or shared. Shared IAM user keys, IP-based bucket policies, and presigned URLs each fail the identity or temporary-credential requirement.

• ACorrect. The role's trust policy names the partner account as a principal, and its permissions policy limits access to the bucket. The partner's principals call AssumeRole and receive temporary STS credentials, so no long-term credentials are created or shared. A bucket policy that grants the partner account directly is also a common pattern. However, the partner would then use its own credentials, which could be long-term, so that pattern does not guarantee the STS-only requirement.
• BIncorrect. Storing the keys in Secrets Manager protects them in transit, but they are still long-term IAM user access keys created for the partner. This breaks both the STS-only requirement and the ban on creating long-term credentials.
• CIncorrect. This grants access by network location, not identity. Any request from those IP ranges is allowed with no AWS authentication at all. It doesn't use STS credentials and isn't limited to the partner's principals.
• DIncorrect. A presigned URL works only for the one object it was generated for, and it carries the permissions of whoever signed it. It doesn't give ongoing bucket-level access, it must be regenerated as objects change, and with the seven-day maximum the signer typically uses long-term IAM user credentials.

Answer: A) An IAM policy allowing the EC2 actions with a condition of aws:RequestedRegion equal to eu-west-1

• AThe aws:RequestedRegion global condition key evaluates the region targeted by the API call, so requests to any other region are denied even though the actions are otherwise allowed.
• BIAM is global; users aren't scoped to a region.
• CSecurity groups govern network traffic to resources, not which regions a principal may call.
• DA tag by itself enforces nothing without a policy condition, and there's no principal tag that limits the call's target region like aws:RequestedRegion does.

Answer: A) Create a tag policy that defines the CostCenter key and its allowed values, and attach it to the organization root

Tag policies in AWS Organizations standardize tag key case and allowed values across accounts. Compliance can be viewed centrally from the management account. Note that untagged resources are not evaluated.

• ATag policies define tag key case treatment and allowed values, and can optionally block noncompliant tagging operations on specified resource types. From the management account, compliance information for all accounts in the organization can be viewed through Resource Groups.
• BAn SCP can deny API calls based on tag conditions, but it does not standardize key capitalization or produce a compliance report of noncompliant resources.
• CResource groups organize resources for viewing and management. On their own they do not define allowed values or enforce tagging rules across an organization.
• DActivating a cost allocation tag only makes it appear in cost reports. It does not validate tag key case or values and does not report noncompliant resources.

Answer: A) Store the password as a secret in AWS Secrets Manager and enable automatic rotation on a schedule

Secrets Manager is built to store credentials encrypted and rotate them automatically, updating both the secret and the database. Parameter Store has no built-in rotation, KMS key rotation changes key material rather than passwords, and ACM handles only certificates.

• ACorrect. Secrets Manager encrypts secrets with AWS KMS and supports scheduled automatic rotation. Managed rotation covers service-managed secrets, and rotation functions cover RDS databases. Rotation updates both the secret and the database credentials, and the application keeps reading the current value.
• BIncorrect. A SecureString parameter is encrypted with AWS KMS, but Parameter Store has no built-in credential rotation in either the Standard or the Advanced tier. The team would have to build and schedule its own rotation logic. AWS recommends Secrets Manager for database credentials.
• CIncorrect. KMS automatic key rotation replaces the key's cryptographic material. It doesn't change the database password or update the credentials in RDS.
• DIncorrect. ACM manages and renews TLS certificates. It doesn't store or rotate arbitrary secrets such as database passwords.

Answer: A) Amazon Macie

• AMacie scans S3 objects using managed and custom data identifiers to locate PII and other sensitive data, and reports on bucket exposure and access posture — exactly this pre-access review.
• BInspector assesses compute workloads for CVEs and network exposure, not the contents of S3 objects.
• CConfig evaluates configuration rules; it doesn't classify data inside objects.
• DAthena can query data if you already know its structure, but it isn't an automated sensitive-data discovery and classification service.