Cloud Infrastructure and Hybrid Architectures Questions

Understanding cloud provider infrastructure (AWS, Azure, GCP), virtualization concepts (hypervisors, container orchestration), Infrastructure-as-a-Service (IaaS) considerations, hybrid cloud and on-premise integration, cloud cost optimization, and vendor-specific architecture patterns.

MediumTechnical

52 practiced

Describe the process to synchronize on-prem Active Directory identities with Azure AD using Azure AD Connect. What are the key configuration options (password hash sync, pass-through auth, federation), and which would you recommend for a highly regulated environment with strict auditing requirements?

Sample Answer

**Brief process overview**- Install Azure AD Connect on a dedicated Windows server joined to the domain.- Run the wizard to connect to your on-prem Active Directory and your Azure AD tenant.- Configure sync scope (OUs, attribute filtering), account mapping, and optional write-backs (password, device, group).- Enable monitoring with Azure AD Connect Health and schedule or enable continuous sync.

**Key configuration options**- Password Hash Sync (PHS) - Syncs a hash of the on-prem AD password to Azure AD to allow cloud authentication. - Pros: simple, resilient, supports cloud-only authentication and Azure AD features. - Cons: password hashes exist in Azure (protected), may not meet strict compliance.

- Pass-Through Authentication (PTA) - Authentication agent validates user credentials against on-prem AD at sign-in time; no password hash stored in Azure. - Pros: no cloud password hashes, simpler than federation, supports SSO. - Cons: requires high availability of on-prem authentication agents and network connectivity; limited on-prem control vs federation.

- Federation (AD FS or third-party STS) - Redirects authentication to on-prem identity provider; Azure trusts the federation token. - Pros: full on-prem control over auth policies, rich auditing and claim rules, supports smartcard/kerberos/conditional access integration that relies on on-prem decisions. - Cons: more infrastructure (AD FS servers, proxy), higher operational overhead.

**Recommendation for a highly regulated environment with strict auditing**- Recommend Federation (AD FS or an enterprise STS) because it provides: - Centralized control of authentication flows on-premises. - Detailed, auditable logs under your control (auth, token issuance, conditional access decisions). - Ability to enforce on-prem MFA, smartcard, and custom claim rules.- If full federation is not possible, PTA is a reasonable compromise (no cloud-stored hashes) but plan for HA of PTA agents and integrate robust logging/SIEM for audit trails.

**Operational considerations**- Harden and monitor the Azure AD Connect server; restrict Admin permissions.- Enable Azure AD Connect Health and forward logs to SIEM for retention/audit.- Test in staging mode, configure backup/HA for AD FS or PTA agents, and document incident/recovery procedures.

MediumTechnical

61 practiced

Design a logging and aggregation strategy for a hybrid environment with on-prem servers, AWS EC2, and GKE clusters. Include log collection agents, transport, central storage, index/search considerations, retention policies, and how you would secure log access for compliance.

Sample Answer

**Approach summary**Design a unified, secure pipeline: lightweight agents collect logs on each host/container → reliable encrypted transport → central object store for cold/archive + search cluster for hot queries → retention tiering and strict access controls for compliance.

**Agents**- On-prem EC2/Linux servers: Filebeat (beats) or Vector as daemon/service.- GKE: Fluent Bit or Vector as a DaemonSet to capture stdout/stderr + node logs.- EC2: CloudWatch Agent for CloudWatch ingestion (optionally forward to central).- Containers: sidecar or use cluster-level Fluent Bit to enrich (k8s metadata).

**Transport**- Use TLS (mTLS where possible) and authenticated endpoints.- Buffering on agents + backpressure: use Kafka/Kinesis as durable stream between agents and processors for scale.- For simpler env, agents push directly to an ingestion endpoint (Logstash/Fluentd/Vector transform).

**Central storage & indexing**- Hot tier: OpenSearch/Elasticsearch cluster for indexing recent logs (7–30 days) enabling fast search/alerts.- Cold tier: S3 (or S3-compatible) for month/years retention; use index lifecycle management to roll indices to S3 snapshots.- Option: AWS OpenSearch Service with S3 snapshots for durability.

**Index/search considerations**- Index by time-based indices (daily/weekly) and use ILM to shrink/rollover.- Use parsers to structure logs (JSON fields) and predefined mappings to avoid mapping explosion.- Retain only necessary fields in hot index (remove large payloads), store full raw in S3.

**Retention & lifecycle**- Hot: 7–30 days (search/alerts)- Warm: 30–90 days (reduced replicas, less compute)- Cold/Archive: 90 days–7 years on S3/Glacier depending on compliance- Automate via ILM and lifecycle policies; test restore procedures.

**Security & compliance**- Encryption in transit (TLS) and at rest (KMS for S3/OpenSearch).- Central auth: SAML/SSO + RBAC for OpenSearch; AWS IAM for S3/OpenSearch access.- Network controls: VPC endpoints, security groups, private connectivity (Direct Connect/VPN) for on-prem.- Audit logging: enable access/audit logs for search cluster and S3 access; store separate immutable audit stream.- Data access policies: field/row-level redaction for PII; tokenization or scrubbing at ingestion.- Key retention and legal hold: mark indices/objects immutable; implement retention overrides with approvals.

**Operational notes**- Monitor agent health with metrics; alert on drop rates.- Regular runbooks: restore tests, index growth forecasts, cost monitoring (S3 vs. Hot storage).- Start small: pilot with critical apps, validate retention/restore, then roll out.

This design balances reliability, searchability, cost, and compliance for a hybrid on‑prem + AWS + GKE environment.

HardTechnical

53 practiced

Design an encrypted backup pipeline that transfers on-prem backups to cloud object storage. Describe key management choices (cloud KMS vs external HSM), transport encryption, access controls, and how you would rotate and revoke keys while ensuring historical backups remain decryptable if required by auditors.

Sample Answer

**Situation / Overview**Design an encrypted pipeline where on‑prem backups (VM images, DB dumps, file archives) are moved to cloud object storage while meeting security and audit needs.

**Architecture & Encryption Approach**- Use envelope encryption: each backup file is encrypted on‑prem with a randomly generated data key (DEK) using AES‑GCM (local encryption) and the DEK is wrapped (encrypted) with a Key Encryption Key (KEK).- Store the wrapped DEK and key metadata alongside the object (object metadata or a separate secure manifest).

**Key Management Choices**- Cloud KMS (managed): easier integration, automatic auditing, IAM controls, key rotation APIs. Good for operational simplicity.- External HSM (on‑prem or BYOK with cloud HSM): stronger control, useful when policy demands customer custody or FIPS 140‑2/3 compliance. Use for KEK root of trust; KMS can import HSM‑generated KEKs or use HSM-backed KMS.- Recommended for a systems admin: use HSM-backed cloud KMS (BYOK or HSM import) so you get managed reliability + hardware root of trust.

**Transport Encryption**- Use TLS 1.2+ with mutual TLS for transfer agents or VPN/WAN link. Validate server certs and enforce cipher suites.- Use multipart upload over HTTPS and verify checksums (SHA‑256) after upload.

**Access Controls**- Principle of least privilege via IAM roles: backup agent role can PutObject and GetObject for backup buckets, and use encrypt/decrypt only via KMS APIs for wrap/unwrap if using KMS.- Bucket policies: restrict by VPC or source IP, require server‑side encryption and deny public ACLs.- Enable object versioning and MFA Delete (if supported) to prevent undetected deletions.

**Rotation & Revocation Strategy**- Key rotation: rotate KEKs on a schedule (e.g., annually) by creating new KEK version in KMS/HSM and using it for new wrapped DEKs.- Preserve old KEKs/versions: do NOT delete previous KEK versions; keep them archived in HSM or KMS key versions so wrapped DEKs remain decryptable.- Rewrap policy (optional): implement lazy rewrap—existing backups remain wrapped with old KEK versions; rewrap to new KEK only if required (e.g., after key compromise or proactive rekeying for compliance) by decrypting DEK with old KEK and re-wrapping with new KEK, updating manifest.- Revocation: if a KEK is compromised, mark its version as disabled for future operations. To preserve audit decryptability, either: - Rewrap all affected backups immediately to new KEK, or - Keep the compromised KEK isolated in offline HSM for auditor-only decrypt with strict access controls and recorded approvals.

**Ensuring Historical Decryptability**- Store key version identifier with each backup’s metadata so the correct KEK version is used.- Never permanently delete KEK versions if audits may require historic decryption; instead export an encrypted key‑escrow snapshot into a secure offline HSM vault with tamper controls and dual‑control access.- Maintain detailed access logs (KMS, storage access, and network) and periodic test restores to validate ability to decrypt old backups.

**Operational Controls & Compliance**- Separation of duties: different principals for backup config, key management, and audit access.- Automated key rotation via KMS APIs, with rotation runbooks and playbooks for compromise.- Regular restore drills, attestation records for key custody, and retention policies for key material consistent with legal retention.- Monitor with SIEM: KMS API calls, key disable/enable events, and anomalous storage access.

This design balances operational manageability with strong cryptographic control: use HSM‑backed KMS for KEKs, envelope encryption on‑prem for data, TLS for transport, strict IAM and bucket controls, versioned keys and manifests for rotation, and secure escrow/retention for audit decryptability.

MediumTechnical

46 practiced

Design an automated backup and retention strategy for a fleet of SQL databases hosted across on-prem and cloud-managed instances. Requirements: daily full backups for production with 30-day retention, weekly offsite snapshot to cloud object storage for compliance, and weekly restore verification. Describe tools, scheduling, encryption, and verification steps.

Sample Answer

**Overview (goal)** I would implement an automated, auditable backup pipeline that produces daily full backups for production (30-day retention), weekly offsite snapshots to cloud object storage for compliance, and weekly restore verification.

**Tools**- SQL engines: native tools (SQL Server BACKUP, pg_dump/pg_basebackup) or managed DB snapshots (RDS/Azure SQL).- Orchestration: cron / systemd timers (Linux) or Task Scheduler + PowerShell (Windows). Use Ansible for rollout.- Offsite transfer: AWS S3 / Azure Blob with lifecycle rules; rclone or aws-cli/azcopy for transfers.- Encryption: server-side KMS + client-side AES-256 for at-rest; TLS for in-transit.- Monitoring/alerting: Prometheus + Alertmanager or CloudWatch + SNS; record logs to ELK.

**Scheduling & retention**- Production DBs: full backup daily at low-usage hours (e.g., 02:00). Retain local backups 30 days.- Weekly offsite snapshot: every Sunday 03:00 copy encrypted backup to cloud object storage, set immutable (WORM) if compliance requires.- Retention enforced by lifecycle rules and a retention cleanup job that deletes local files older than 30 days.

Example cron entries:- Daily full: 0 2 * * * /opt/backups/backup_prod.sh- Weekly offsite copy: 0 3 * * 0 /opt/backups/push_offsite.sh- Cleanup: 30 4 * * * /opt/backups/cleanup.sh

**Encryption**- Create a per-environment KMS key. On backup: - Encrypt backup with AES-256 using local key wrapping. - Upload to cloud using TLS; server-side encryption with KMS on cloud side as secondary protection.- Store KMS key policy & rotation in Vault (HashiCorp) and restrict access via IAM roles.

**Verification (weekly)**- Weekly automated restore to an isolated test instance: 1. Spin up ephemeral DB server (container/VM). 2. Pull last weekly offsite snapshot, decrypt, restore. 3. Run smoke tests: schema validation, row counts, key query results, application-level health checks. 4. Compute checksum/hash of important tables and compare to baseline. 5. Post results to monitoring; on failure open incident via PagerDuty.

**Operational details & docs**- Secure backup scripts in Git, use CI to test.- Audit logs for backup/restore actions, key usage.- Run quarterly disaster-recovery drills and review RTO/RPO targets.This design balances automation, encryption, auditability, and verification appropriate for a Systems Administrator role.

EasyTechnical

53 practiced

Describe the steps to provision a Linux VM in Azure, join it to an on-prem Active Directory domain using AD Connect or hybrid join, and verify that domain group policies are being applied. Include network and DNS prerequisites that a systems administrator must configure.

Sample Answer

**Approach overview**I’d provision an Azure Linux VM, ensure network/DNS and time sync let it reach on‑prem DCs, join the VM to the on‑prem AD using realmd/SSSD, then confirm hybrid identity sync (Azure AD Connect) and verify AD group policies (SSSD GPO support / config) are applied.

**Prerequisites — network & DNS**- Connectivity: VPN or ExpressRoute between Azure VNet and on‑prem network; correct route tables.- DNS: VM must use on‑prem AD DNS servers (point VM DNS settings or custom DNS in VNet).- Firewall/NSG rules: allow DNS (UDP/TCP 53), Kerberos (TCP/UDP 88), LDAP (TCP 389 / TCP 636 for LDAPS), RPC/SMB (TCP 445) and NTP (UDP 123) to DCs.- Time sync: NTP to domain time source (Kerberos requires clock within tolerance).- Azure AD Connect: correctly syncs on‑prem AD to Azure AD; verify sync and configured OU filtering.

**Provision & join steps**1. Create Linux VM (Ubuntu/CentOS) in Azure; assign subnet with route to on‑prem and set DNS to on‑prem DCs.2. SSH in, install packages: realmd, sssd, sssd-tools, oddjob, samba-common-bin, krb5-user, adcli.

bash

sudo apt update
   sudo apt install realmd sssd sssd-tools adcli samba-common krb5-user oddjob oddjob-mkhomedir

3. Discover and join domain: - Test discovery: realm discover corp.example.com - Join: sudo realm join --user=ADadmin corp.example.com4. Configure SSSD and home dir creation (oddjob) and adjust /etc/sssd/sssd.conf as needed; restart sssd.

**Hybrid identity verification**- In Azure AD Connect server: confirm successful sync and no errors.- In Azure Portal > Azure AD > Devices: check device shows as Hybrid Azure AD joined (if using device join) or users present in Azure AD.

**Verify AD membership & GPO application**- Confirm account resolution and groups: - id username - getent passwd username - getent group "AD-Group-Name"- Check Kerberos ticket: klist- If using SSSD GPO plugin (sssd-ad-gpo): - Inspect cached GPOs: /var/lib/sss/gpo_cache/ - Use sssctl or sss_cache to view/apply: sudo sssctl gpo-show username - Check /var/log/sssd/sssd_ad.log and /var/log/sssd/sssd_nss.log for GPO fetch/apply errors- For configuration policies (e.g., sudoers, pam, configs) validate the specific policy effects (file contents, permission changes).- On Windows side, ensure GPOs targeted to the computer/user are enabled and use gpresult /r for Windows test machines.

**Common checks / troubleshooting**- DNS resolution of DCs from VM (nslookup dc1.corp.example.com)- Time skew (timedatectl)- Kerberos auth (kinit ADadmin)- Azure AD Connect sync status and event logs

This sequence ensures the VM can authenticate against on‑prem AD, appear in Azure AD if hybrid sync is configured, and lets you verify GPO content retrieval via SSSD logs and cache.

Unlock Full Question Bank

Get access to hundreds of Cloud Infrastructure and Hybrid Architectures interview questions and detailed answers.

Join thousands of developers preparing for their dream job.