Select Two (Multi-Select) Questions

A security information and event management (SIEM) system.

Why it fails: A SIEM correlates security events and generates threat alerts, but it does not aggregate application logs or service metrics for operational monitoring across microservices. It is tempting because SIEM genuinely centralises and correlates data, and would be correct if the requirement were security incident detection rather than operational observability.

An application performance monitoring (APM) tool.

Why it fails: APM tools trace application transactions and latency within instrumented services, but they do not provide the centralised log aggregation or cross-service log correlation the solution demands. They are tempting because APM genuinely covers metrics and alerting for service performance, and would be correct if distributed tracing alone were required.

Enabling automatic patching

Why it fails: Automatic patching closes known software flaws, eliminating the unpatched-system vulnerability instead of introducing it. It is tempting because unpatched cloud workloads are commonly exploited, so patching surfaces in vulnerability discussions, but enabling it is the control that prevents exposure, not a vulnerability.

Using multi-factor authentication

Why it fails: Multi-factor authentication strengthens identity verification, removing the credential-theft path that enables unauthorised access. It is tempting because weak authentication is a genuine cloud vulnerability, so authentication features appear in such lists, yet enabling MFA is the remediation rather than the weakness itself.

Properly scoped IAM roles

Why it fails: Properly scoped IAM roles enforce least privilege, closing the over-permissive-role vulnerability rather than creating one. It is tempting because misconfigured IAM roles genuinely cause breaches, so IAM appears in vulnerability discussions, but scoping them correctly is the mitigation, not the exposure.

Configure network security groups to allow only HTTPS traffic

Why it fails: While recommended, HIPAA does not mandate specific firewall rules.

Enable multi-factor authentication for all administrative accounts

Why it fails: MFA is a security best practice but not explicitly required by HIPAA.

Configure automatic patching for all virtual machines

Why it fails: Patching is important but not a specific HIPAA requirement.

Developers' preferred programming languages.

Why it fails: Programming-language preference is an application development concern, not a factor in choosing public, private or hybrid deployment. It is tempting because language choice does influence runtime and platform services, so it would be the correct consideration when selecting compute services or a PaaS runtime, not the deployment model itself.

Cloud provider's marketing claims.

Why it fails: Marketing claims are promotional and unverifiable, so they cannot inform a deployment-model decision. They are tempting because vendor material often frames compliance, resilience and cost in appealing terms, and such claims would only be relevant as a starting point for due diligence, never as a selection criterion.

Expired software licenses on the target host

Why it fails: Expired licences on the target host do not halt a VM migration; the hypervisor moves the workload regardless of guest or application licensing state. This distractor tempts because licence compliance genuinely blocks deployment and provisioning tasks, making it correct when auditing host eligibility before placing new workloads rather than migrating existing ones.

Stale DNS records for the VM's hostname

Why it fails: Migration re-registers the VM under a new IP, so stale DNS records are refreshed by the migration process itself and do not block it. Stale records are tempting because they genuinely cause connectivity failures after cutover, making them the right answer when troubleshooting post-migration name resolution rather than the migration event.

Azure Blob

Why it fails: Azure Blob is object storage accessed via HTTP REST APIs, not a mounted SMB or NFS file system, so on-premises and cloud VMs cannot mount it as a shared drive. It is tempting because Blob underpins Azure Files, and would be correct for storing unstructured objects, backups or static web content.

Amazon S3

Why it fails: Amazon S3 is object storage accessed via HTTP APIs, not a POSIX shared file system mountable by on-premises and cloud VMs. It is tempting because S3 is durable, highly available and reachable from both environments, but shared file access requires Amazon EFS or FSx.

Amazon EBS

Why it fails: Amazon EBS volumes attach to a single EC2 instance in one Availability Zone, so they cannot present a shared file system to on-premises hosts. It is tempting because EBS is block storage for EC2 boot and data volumes, and would be correct for a single-instance database needing low-latency disk.

Change sets

Why it fails: Change sets preview how a stack update will alter running resources before execution, but they neither enforce consistent deployment across accounts nor detect drift. It is tempting because they accompany updates, yet drift detection requires Drift Detection and cross-account consistency requires StackSets, which this option does not provide.

Outputs

Why it fails: Outputs merely export values from a stack for other stacks or processes to consume; they neither replicate templates into other accounts nor detect drift. Outputs are tempting because they enable cross-stack references, which is the correct choice when sharing resource identifiers between stacks in one account.

Nested stacks

Why it fails: Nested stacks compose a parent template from child templates within one account, so they cannot deploy the same template across separate accounts; that cross-account consistency requires StackSets. Nested stacks are tempting for reusing modular template components inside a single account's deployment.

Set up a site-to-site VPN between the on-premises network and each cloud.

Why it fails: VPNs provide network connectivity, not identity management.

Use a single shared API key for all clouds to simplify automation.

Why it fails: Shared keys are insecure and not a suitable identity method.

Use complex passwords and rotate them every 30 days

Why it fails: While good, not specific to console access and MFA is better.

Use the root account for daily administration

Why it fails: Root account should be used sparingly.

Enable guest access for external auditors

Why it fails: Guest access introduces risk.

Using single-factor authentication for all administrative access

Why it fails: PCI DSS requires multi-factor authentication for all administrative access into the cardholder data environment; single-factor leaves privileged accounts exposed to credential theft. It is tempting because single-factor is the default for many basic IAM users, and would suffice only for non-privileged, low-risk read-only accounts outside CDE scope.

Using default VPC settings without changes

Why it fails: A default VPC ships with permissive routing, auto-assigned public IPs and open default security groups, none of which satisfy PCI DSS segmentation or least-privilege network controls. It is tempting because default VPCs genuinely suit quick non-regulated development sandboxes where isolation and audit obligations do not apply.

Enable verbose logging for all services

Why it fails: Verbose logging increases volume across every service, burying security-relevant events and inflating ingestion cost without adding structure or queryable fields. It is tempting because more data feels like better coverage; it would be correct during active troubleshooting of a specific service, where detailed diagnostic output is needed temporarily.

Use random log formats for different applications

Why it fails: Random formats prevent consistent parsing and field extraction, defeating structured logging and breaking alert queries. Uniform schemas such as JSON with stable keys are required; randomness suits deliberately obfuscated or unstructured diagnostic dumps, not alerting pipelines.

Send all logs to syslog servers

Why it fails: Syslog servers centralise transport and retention but impose no schema, so fields remain unstructured text that cannot be queried reliably for alerting. It is tempting because syslog is the standard mechanism for aggregating device and host logs; it would be the right choice when the requirement is collection and archival rather than structured, queryable events.

Network performance monitoring

Why it fails: Network performance monitoring observes latency and throughput for operational tuning, not the restoration of services or data following a disaster. It is tempting because monitoring underpins incident detection, and would be correct if the question concerned day-to-day performance visibility rather than recovery planning components.

Billing alerts

Why it fails: Billing alerts notify on cost thresholds; they neither replicate data nor restore workloads after an outage. It is tempting because cost governance matters in cloud DR planning, and would be the right answer if the question asked about controlling spend, not the components that enable recovery.

Load balancing

Why it fails: Load balancing distributes live traffic across healthy instances for availability and scaling, not recovery of data or workloads after an outage. It is tempting because it supports resilience during partial failures, and would be the right answer if the question asked about maintaining service continuity, not disaster recovery components.

Cloud NAT

Why it fails: NAT provides outbound internet access, not security.

Cloud VPN

Why it fails: VPN encrypts traffic but does not provide WAF or DDoS protection.

Scale vertically to increase capacity

Why it fails: Vertical scaling enlarges one node, leaving a single point of failure and requiring downtime to resize; high availability demands horizontal redundancy across zones. It is tempting because it raises capacity quickly, and would be correct for a monolithic workload that cannot be distributed.

Use a single, powerful database instance

Why it fails: One database instance creates a single point of failure; availability requires replication, clustering or multi-AZ failover. It is tempting because a large instance performs well under load, and would be correct for development environments where uptime guarantees are not required.

Warm standby

Why it fails: Warm standby runs a scaled-down but fully functional copy of the application, so it still requires scaling up and validating before traffic can be served, which can exceed five minutes. It is tempting because it balances cost against recovery speed, and it is correct when the RTO is around ten to thirty minutes.

Backup and restore

Why it fails: Backup and restore recovers data from stored copies, so recovery time is governed by restore duration — hours for a critical application, not under five minutes. It is tempting because it is the cheapest, simplest pattern, and it is the correct choice when the RTO is measured in hours and cost minimisation matters most.

Pilot light

Why it fails: Pilot light keeps only core components such as data replication running, with application servers stopped, so recovery requires provisioning and starting those servers before traffic is served. It is tempting because it is cheaper than warm standby, and it is correct when the RTO is tens of minutes rather than under five.

Swap file usage

Why it fails: Swap file usage reflects memory pressure inside a guest operating system, not contention between virtual machines on the hypervisor. It is tempting because swapping indicates a resource shortage, but it suits diagnosing an individual VM's memory exhaustion, whereas host-level metrics such as CPU ready time reveal contention.

Network latency

Why it fails: Network latency measures round-trip delay across the network path, not contention for CPU, memory or storage on the virtualisation host. It is tempting because latency spikes accompany many performance problems, but it suits diagnosing network congestion or WAN issues rather than host resource contention.

Store secrets in ConfigMaps

Why it fails: Secrets should be stored in dedicated secrets management, not ConfigMaps.

Disable audit logging to reduce overhead

Why it fails: Disabling audit logging reduces visibility, not improve security.

Use default service accounts for all pods

Why it fails: Default service accounts may have excessive permissions.

Use separate encryption keys for each account.

Why it fails: Separate keys per account is a sound isolation practise, but the question asks for storage management best practices; per-account keys alone do not address lifecycle, access, or cost governance across accounts. It would be correct where regulatory isolation mandates distinct key custody per tenant.

Use a single storage bucket/container for all accounts to simplify management.

Why it fails: A single shared bucket across accounts collapses the isolation boundary, letting one account's misconfiguration or credential compromise expose every account's objects. Consolidated buckets suit single-account or tightly coupled workloads where centralised management outweighs blast-radius concerns.

Allow full public access to ensure availability.

Why it fails: Full public access removes the access-control layer entirely, exposing stored objects to anyone and breaching least-privilege expectations for multi-account storage. Public access is only appropriate for deliberately published static content, such as a website's public assets, not general account data.

Infrastructure as Code

Why it fails: Infrastructure as Code provisions and versions environments reproducibly, but it neither executes automated tests nor gates promotion on test results. It is the right choice when the requirement is consistent, repeatable infrastructure provisioning rather than validating code health before production release.

Immutable infrastructure

Why it fails: Immutable infrastructure replaces rather than mutates servers, aiding consistency and rollback, but it performs no testing and applies no health gate before production. It is correct when eliminating configuration drift is the objective, not when validating code quality in a pipeline.

Manual approval gates

Why it fails: Manual approval gates insert human sign-off, which contradicts the stated goal of automating testing and deployment. They suit regulated releases needing documented authorisation. The stem requires automated quality checks that block unhealthy code, which approval gates do not perform.

Send all logs to a single S3 bucket without partitioning

Why it fails: A single unpartitioned S3 bucket prevents efficient pruning, so queries scan everything and cost and latency rise. Partitioning by date or service is tempting to skip for simplicity, but structured logging relies on partitioned prefixes so tools such as Athena can prune scanned data.

Encrypt log files at rest using AWS KMS

Why it fails: KMS encryption at rest protects confidentiality but adds no structure or queryability, so it does not satisfy the stated goal. It is tempting because security is a logging best practice, yet the question asks specifically for practices that improve queryability, such as JSON formatting and partitioning.