Management And Technical Operations practice questions

Software-Defined Networking

Why it fails: SDN is an architecture, not a specific connectivity service for hybrid links.

Content Delivery Network

Why it fails: CDNs are for caching content closer to end-users, not data center connectivity.

Site-to-Site VPN

Why it fails: VPNs use the public internet and do not guarantee the same latency or privacy as dedicated lines.

Route Table

Why it fails: Route tables direct traffic, they do not filter it based on destination headers.

VPC Peering

Why it fails: Peering connects two networks, it does not filter traffic.

Internet Gateway

Why it fails: The gateway provides the connection to the internet, it does not act as a filter.

NAT Gateway

Why it fails: A NAT gateway allows outbound internet access, which is against the isolation requirement.

Public IP address assignment

Why it fails: Public IPs expose resources to the internet, which violates the requirement.

Internet Gateway

Why it fails: An Internet Gateway is explicitly for public internet traffic.

Change the password of the user

Why it fails: Rotating the compromised access key is the immediate step; changing the user's password does not invalidate the exposed key, leaving the attacker's access intact. Password changes address credential compromise for console or directory sign-ins, so they would be correct for a breached user account rather than a leaked service-account key.

Increase logging levels

Why it fails: Raising logging levels records more detail but does not revoke the compromised key, so the attacker retains access while lag persists. Verbose logging suits forensic investigation after containment, or diagnosing intermittent failures, not the immediate operational act of disabling or rotating the exposed credential.

Monitor CloudTrail logs

Why it fails: Monitoring CloudTrail logs is detective and retrospective, leaving the compromised key active and exploitable. It is tempting because logging supports investigation, and it would be correct for auditing API activity after the key has been deactivated or rotated.

Instance health checks

Why it fails: These check if the service is alive, not the network path.

IAM Policy simulator

Why it fails: This tests permissions, not network connectivity.

CloudWatch Metrics

Why it fails: Metrics show utilization, not network path connectivity.

Public access block

Why it fails: This prevents public access, not accidental deletion.

Storage encryption

Why it fails: Encryption protects data, but not against deletion.

Cross-region replication

Why it fails: This provides redundancy, but not deletion protection by default.

Printing all data as paper records

Why it fails: Paper records cannot carry data into cloud storage and breach the requirement to migrate data electronically. Physical shipping suits offline bulk transfer via appliances such as Azure Data Box, but printing produces an unusable analogue copy.

Hard-coding all database rows

Why it fails: Hard-coding database rows into application code neither migrates the data nor preserves referential integrity, and it exposes records in source control. Extract-and-load tooling such as Azure Database Migration Service is the correct mechanism for moving relational data.

Deleting all local hardware

Why it fails: Decommissioning on-premises hardware is an outcome of completing migration, not a migration strategy. Retire or decommission is a valid disposition step once workloads and data are verified in the cloud, but deleting hardware before data transfer destroys the source.

Content Delivery Network

Why it fails: CDNs are for caching, not security filtering.

Auto Scaling Groups

Why it fails: Scaling groups manage capacity, not network security.

Buying a new laptop

Why it fails: This is hardware procurement.

Deleting old logs

Why it fails: Deletion is the opposite of backup.

Physical disk copying

Why it fails: Cloud backups are logical, not physical copies.

Renaming a file

Why it fails: Renaming is not a backup process.

Migrate the application to a single larger virtual machine with more memory and CPU

Why it fails: Scaling up a single virtual machine increases capacity but concentrates risk. If that one instance or its host fails, the application becomes unavailable. This approach does not distribute the workload across failure domains, so it does not improve availability against an outage. It addresses performance, not the resilience concern described in the scenario.

Enable automatic backups of the application database every hour

Why it fails: Backups protect data integrity and enable recovery, but they do not keep the application running during an outage. If the provider or region becomes unavailable, the application still goes down until backups are restored elsewhere. The scenario asks for reducing the risk of an outage affecting the application, which requires architectural redundancy rather than data protection alone.

Purchase a higher-tier support plan from the cloud provider

Why it fails: A premium support plan improves response times and access to engineers during incidents, but it does not prevent outages or automatically fail over workloads. The application remains dependent on the same infrastructure. Support tiers are valuable for escalation, yet they do not provide the architectural redundancy needed to keep a customer-facing service available.

All-at-once deployment that replaces all instances simultaneously

Why it fails: Replacing every instance at once causes a service interruption because no healthy capacity remains during the swap. If the new version fails health checks, the entire application is unavailable until instances are restored. It cannot provide zero downtime or immediate rollback, so it does not satisfy the stated requirement of uninterrupted service with fast recovery.

Blue/green deployment that maintains two identical environments and shifts traffic after validation

Why it fails: Blue/green does provide zero downtime and fast rollback, but it requires provisioning and paying for a complete duplicate environment, which is not stated as available or desired here. The question asks for the strategy the team should implement given only the described infrastructure; the rolling approach achieves the same availability goal without the extra environment cost.

Canary deployment that sends a small percentage of traffic to the new version and waits for manual approval

Why it fails: Canary releases reduce risk by exposing only a small traffic slice, but they typically require additional routing configuration and often manual promotion steps. The scenario demands an immediate, automated rollback on health-check failure across the fleet, which the batch-based rolling deployment handles directly. Canary delays full rollout and adds operational complexity not requested.

Move all objects to an archive storage class immediately after upload.

Why it fails: Archive storage classes are the cheapest per gigabyte but impose retrieval delays ranging from minutes to hours and often add per-retrieval fees. Because the files are accessed frequently during the first week, immediate archival would make those early reads slow or expensive. This option sacrifices the active-access period to save cost, which the scenario does not permit.

Keep all objects in the standard hot storage class for the full seven years.

Why it fails: Standard hot storage provides the lowest latency but the highest per-gigabyte cost, and the vast majority of these objects are rarely accessed after the first week. Paying premium rates for seven years on cold data wastes budget without improving retrievability. This strategy meets the retrieval requirement but directly contradicts the stated goal of minimizing cost.

Enable versioning and cross-region replication on the bucket to reduce storage costs.

Why it fails: Versioning preserves multiple copies of each object, and cross-region replication duplicates data into another region. Both features increase storage volume and cost rather than reduce it, and neither changes the storage class or access latency. This option addresses durability and disaster recovery, not the cost optimization the team is pursuing.

Backup and restore from nightly snapshots

Why it fails: Nightly snapshots provide an RPO of up to 24 hours, far exceeding the 5-minute requirement. Restoring from snapshots also typically takes longer than 15 minutes, especially for large databases. This approach is the cheapest but fails both the RTO and RPO objectives, so it is not suitable for this critical application.

Multi-site active-active deployment

Why it fails: An active-active deployment runs full capacity in two regions, providing near-zero RTO and RPO. While it meets the objectives, it is the most expensive option because it duplicates all infrastructure and requires complex data synchronization. The scenario asks for the lowest cost that still meets the objectives, so this over-engineers the solution.

Warm standby with synchronous replication

Why it fails: A warm standby with synchronous replication can meet the RTO and RPO, but synchronous replication adds latency to every write and requires higher network bandwidth and cost. It is more expensive than asynchronous replication and unnecessary for a 5-minute RPO. Therefore, it is not the lowest-cost option that satisfies the requirements.

Cloud Monitoring with a Prometheus sidecar per node.

Why it fails: Cloud Monitoring ingests and alerts on metrics, but a per-node Prometheus sidecar is a self-managed scraping pattern rather than a cluster-level managed observability service. It does not provide traces or preconfigured Kubernetes dashboards out of the box, and operating sidecars adds maintenance overhead the team is trying to avoid.

Cloud Logging with log-based metrics and custom sinks.

Why it fails: Cloud Logging collects and routes log entries and can derive log-based metrics, but it does not natively capture distributed traces or provide prebuilt Kubernetes dashboards. Building a full observability view would require assembling multiple products manually. The requirement calls for an integrated metrics, logs, and traces service, which logging alone does not satisfy.

Cloud Trace with OpenTelemetry collectors deployed as a DaemonSet.

Why it fails: Cloud Trace focuses on distributed tracing latency analysis, not metrics and logs collection. Deploying OpenTelemetry collectors as a DaemonSet shifts operational responsibility to the platform team and still leaves metrics and dashboards to be assembled separately. This does not meet the integrated observability requirement with minimal configuration.

Configure an HTTPS listener on the ALB using the public certificate, and configure the target group to use HTTP for backend traffic.

Why it fails: While this encrypts client-to-ALB traffic, the backend traffic from the ALB to the EC2 instances remains unencrypted HTTP, violating the requirement for encryption in transit between the load balancer and the instances. This approach fails the compliance mandate and exposes internal traffic to potential interception within the VPC, which is unacceptable for payment processing data.

Configure an HTTPS listener on the ALB using the public certificate, and configure the target group to use HTTPS with a self-signed certificate on the instances, disabling certificate validation on the ALB.

Why it fails: Disabling certificate validation on the ALB undermines the security of the backend connection, as it would accept any certificate, including expired or malicious ones. While encryption is technically enabled, the lack of validation means the ALB cannot verify the identity of the backend instances, creating a man-in-the-middle vulnerability. This does not meet the compliance team's requirement for secure, validated encryption.

Configure a TCP listener on the ALB using the public certificate, and rely on the instances to handle TLS termination for both client and backend connections.

Why it fails: A TCP listener on an Application Load Balancer does not support TLS termination; ALBs operate at the application layer and require HTTP/HTTPS listeners for TLS offloading. Using a TCP listener would pass encrypted traffic directly to the instances, but the ALB cannot use the public certificate to decrypt and inspect traffic, defeating the purpose of the load balancer's TLS capabilities and complicating certificate management.

Azure Disk Encryption with BitLocker and Key Vault

Why it fails: Azure Disk Encryption encrypts OS and data disks using BitLocker and stores keys in Key Vault, but it does not support customer-managed keys stored in a hardware security module (HSM) by default. While it provides encryption at rest, the keys are software-protected unless you use Key Vault Premium with HSM-backed keys, but that requires additional configuration and may not meet the strict HSM requirement without Managed HSM.

Always Encrypted with secure enclaves

Why it fails: Always Encrypted with secure enclaves protects sensitive data in use and at rest, but it requires application changes to specify which columns to encrypt and to use the appropriate drivers. The scenario explicitly states that the application should not be modified, so Always Encrypted is not suitable. It also does not use customer-managed keys in an HSM by default, though it can integrate with Key Vault.

Azure Storage Service Encryption with customer-managed keys in Key Vault

Why it fails: Azure Storage Service Encryption is designed for Azure Storage services like Blob, File, and Queue, not for SQL Server databases running on VMs. While it supports customer-managed keys, it cannot encrypt the database files directly. The scenario requires encryption of the SQL Server database, so this service is not applicable and would not meet the requirement without additional layers.

S3 Versioning

Why it fails: S3 versioning preserves prior object versions to aid recovery from overwrites or deletions; it does not acquire or release a lock during apply, so concurrent CI/CD runs still collide. Versioning suits durability and rollback requirements, not preventing simultaneous state modifications.

Terraform Cloud Workspaces

Why it fails: Terraform Cloud workspaces provide remote state storage and run coordination, but locking is enforced by the workspace's own execution model rather than a configurable backend lock mechanism for arbitrary multi-cloud backends. It suits teams wanting managed remote runs, not explicit backend-level locking.

IAM Policy

Why it fails: An IAM policy grants or denies API actions on resources; it cannot acquire a state lock or block a concurrent Terraform apply mid-run. IAM policies suit access control and least-privilege enforcement, not serialising state writes across pipeline executions.

CloudWatch Alarms

Why it fails: CloudWatch Alarms detect metric thresholds but cannot themselves terminate and replace instances; that action belongs to the Auto Scaling group's health-check replacement process. Alarms are tempting because they trigger scaling policies and notifications, and would be the right choice when the requirement is to react to a metric breach rather than to instance health status.

Elastic Load Balancer

Why it fails: An Elastic Load Balancer distributes traffic and performs health checks, but it does not itself terminate or replace instances. Auto Scaling group health check replacement is configured through the group's health check type and grace period; the load balancer only supports this when its health checks are selected as the group's source.

IAM Role

Why it fails: An IAM role grants AWS service permissions, not health evaluation or instance replacement; it cannot detect or terminate unhealthy EC2 instances. It is tempting because Auto Scaling groups do assume a service-linked role to launch and terminate instances, so an IAM role is genuinely required for that group to function — but the component that performs health checks and replacement is the Auto Scaling group's health check configuration.

AWS Cost Explorer

Why it fails: Cost Explorer reports spending and usage trends, but its rightsizing recommendations cover only a limited subset and lack the detailed per-instance historical utilisation analysis requested. It is tempting because it visualises cost data, and would be correct for forecasting spend or identifying overall cost trends rather than instance-level sizing advice.

AWS Trusted Advisor

Why it fails: Trusted Advisor flags idle or underutilised resources through its cost optimisation checks, but it does not generate specific rightsizing recommendations from historical utilisation data. It is tempting because it audits accounts for waste, and would be correct for broad best-practise checks across security, limits and fault tolerance.

AWS Budgets

Why it fails: AWS Budgets tracks spend against thresholds and sends alerts when usage or cost exceeds them; it performs no utilisation analysis and issues no sizing recommendations. It is tempting because it targets cost control, and would be correct for notifying teams when monthly expenditure approaches a defined limit.

Azure Advisor

Why it fails: Azure Advisor analyses configuration and usage to produce best-practise recommendations; it does not stream or visualise live CPU counters. It is tempting because it reviews the whole estate, which suits periodic optimisation guidance rather than real-time metric capture.

Azure Policy

Why it fails: Azure Policy evaluates and enforces resource compliance against rules; it never collects performance counters, so CPU utilisation stays invisible. It is tempting because it operates across a whole VM fleet, which suits auditing configuration drift rather than capturing live metrics.

Azure Resource Graph

Why it fails: Azure Resource Graph queries resource metadata and configuration through Kusto, not live performance telemetry, so it cannot capture CPU counters. It is tempting because it inventories and filters resources at scale, which suits governance reporting rather than real-time metric visualisation.