More in DevOps & Cloud — page 15
Offload long-running tasks from web requests
WHAT IT TESTS: async background-job architecture. OUTLINE: enqueue the job to a queue, return immediately, process with separate workers, report status out of band. RED FLAG: doing the work in the request thread or fire-and-forget threads.
CI/CD pipeline for a container PaaS
WHAT IT TESTS: the build-push-deploy pipeline. OUTLINE: run tests, build the image, push the tag to a registry, then deploy it to Cloud Run. The registry is the build-to-deploy handoff. RED FLAG: skipping the registry or rebuilding on the deploy host.
Securely supplying secrets to an app
WHAT IT TESTS: secrets management hygiene. OUTLINE: never hardcode credentials, inject them as environment variables or pull from a secrets manager, and rotate them. RED FLAG: committing the database URI to source control or baking it into the image.
Deploying to Heroku via Git
WHAT IT TESTS: the git-push PaaS deploy flow and build manifests. OUTLINE: push to the remote, a buildpack detects the language, builds a slug, and runs the Procfile process. RED FLAG: confusing what declares dependencies versus the start command.
Why not store uploads on local PaaS disk?
WHAT IT TESTS: statelessness and ephemeral storage. OUTLINE: PaaS instances are ephemeral and unshared, so local files vanish on restart and are invisible to peers; store uploads in object storage. RED FLAG: treating instance disk as durable or shared.
The cloud shared responsibility model
WHAT IT TESTS: the security boundary in PaaS. OUTLINE: the provider secures the cloud (hardware, OS, runtime), you secure what runs in it (code, data, config, access). RED FLAG: assuming the provider secures your code, data, or IAM.
CAP theorem and real database tradeoffs
WHAT IT TESTS: CAP as a partition-time choice. OUTLINE: during a partition you pick consistency or availability, CP systems reject requests, AP systems stay available but stale. RED FLAG: thinking you pick two of three at all times.
Design a global low-latency database
WHAT IT TESTS: multi-region database tradeoffs. OUTLINE: a distributed store with replicas near users, a tuned consistency level, accepting lag, conflicts, and cross-region cost. RED FLAG: promising low latency, strong consistency, and low cost together.
Add a second access pattern to a key-value store
WHAT IT TESTS: secondary indexing in NoSQL. OUTLINE: add a global secondary index on EmailAddress, weighing extra storage, write amplification, and eventual consistency. RED FLAG: a full scan with a filter, or assuming indexes are free.
Data warehouse versus OLTP database
WHAT IT TESTS: OLAP versus OLTP design. OUTLINE: warehouses use columnar storage for analytical scans, OLTP uses row storage for fast transactions, each fits a different workload. RED FLAG: a warehouse for high-volume single-row writes, or vice versa.
Strong versus eventual consistency in NoSQL
WHAT IT TESTS: consistency tradeoffs. OUTLINE: strong reads see the latest write at higher latency and cost, eventual reads may be stale but are cheaper and faster, match the choice to stakes. RED FLAG: calling eventual consistency simply broken.
RDS Multi-AZ versus Read Replicas
WHAT IT TESTS: availability versus scalability. OUTLINE: Multi-AZ is a synchronous standby for failover, replicas are async for read scaling, combine both when needed. RED FLAG: claiming the standby serves reads or that replicas auto-failover.
How does caching reduce database load?
WHAT IT TESTS: caching as a read-offload layer. OUTLINE: cache-aside reads, RAM-speed lookups, TTL plus invalidation. RED FLAG: treating the cache as durable source of truth or ignoring stale-data and invalidation.
Read replicas in managed relational databases
WHAT IT TESTS: scaling reads and replication basics. OUTLINE: a read replica is an async copy of the primary that serves read-only queries, offloading the primary and scaling read-heavy workloads; expect replication lag.
Choosing relational vs NoSQL managed databases
WHAT IT TESTS: data model and access pattern fit. OUTLINE: choose relational for complex relationships, joins, flexible queries, and strong transactions; choose NoSQL for known access patterns needing massive horizontal scale.
Architecting for HIPAA or PCI DSS compliance
WHAT IT TESTS: building auditable, compliant data handling. OUTLINE: isolate sensitive data in restricted networks and accounts, encrypt at rest and in transit with managed keys, enforce least-privilege access, and keep immutable audit logs.
Centralized logging and threat detection across accounts
WHAT IT TESTS: multi-account security architecture. OUTLINE: organization-wide trails ship logs to a locked-down central security account, store in immutable append-only storage, and aggregate threat detection findings centrally with least-privilege…
Dynamic database credential rotation for microservices
WHAT IT TESTS: dynamic secrets and zero-downtime rotation. OUTLINE: a secrets manager issues short-lived per-service credentials, services authenticate by workload identity and fetch or refresh secrets without restart, leases expire and rotate automatically.
Shared responsibility model across service tiers
WHAT IT TESTS: who secures what at each service tier. OUTLINE: provider secures the cloud infrastructure; you secure what you put in it; the line shifts with abstraction. For OS patching, you patch IaaS VMs but the provider patches a managed database OS.
Automating a no-public-IP governance rule
WHAT IT TESTS: preventive policy-as-code governance. OUTLINE: use organization-level policy guardrails (SCP, Azure Policy, Org Policy) to deny public IP attachment before creation, applied across all accounts.