7 Meta Cloud Engineer Interview Questions & Answers

I would keep topology, policy, addressing, inventory, and constraints in one versioned Git source of truth. A design compiler generates device configurations. Automated checks validate syntax, policy, addressing, dependencies, device capabilities, reachability, and blast radius. A human reviews the diff, risk, and impact before approval. The deployment controller starts with a canary or small batch and uses health gates before continuing. If verification fails, it stops further rollout and uses the supported revert method when safe. Continuous drift detection compares the live network with intended state and sends corrections back through the same reviewed workflow.

The goal is to make network changes repeatable and safe. I would keep the intended network design in one controlled repository. Automation turns that intent into device configurations. Before anything changes, the framework checks the result for mistakes, conflicts, and unsupported behavior. A person reviews the proposed change and its impact. Deployment starts on a small part of the network. The system checks whether that part is healthy before continuing. If something goes wrong, it stops and recovers where recovery is supported. It also keeps checking that the live network still matches the intended design.

1. Which device vendors and operating systems must the framework support?
2. Do all target devices provide a safe commit or revert capability?
3. Which health signals should block promotion to the next rollout stage?
4. Should detected drift create only an alert, or also create a proposed correction?

I would use Git as the source of truth. It stores topology, policy, addressing data, device inventory, and design constraints. Protected branches, schema checks, policy checks, ownership rules, and code review help prevent conflicting intent from being accepted.

A design compiler converts approved intent into device specific configuration artifacts. Templates such as Jinja2 can render those artifacts, but the important rule is that generated output comes from versioned intent and inventory. The validation stage checks syntax, semantics, policy compliance, address overlap, dependencies, device capability, change risk, reachability, and expected blast radius. Tools such as Batfish, pyATS, or a network simulator can provide extra preflight evidence when they fit the environment.

A network engineer then reviews the configuration diff, risk assessment, impact analysis, test results, and rollout plan. Deployment begins only after approval. An orchestrator such as Ansible or Nornir can control order and parallelism, respect the change window, and start with a canary or small batch. It must use the commit or revert behavior actually supported by each device.

Health gates check reachability, interface state, neighbor relationships, routing convergence, policy enforcement, telemetry, and alarms. A failed gate stops further rollout. If the affected device supports a safe revert, the controller can roll it back automatically or an operator can perform recovery. The framework must not assume that every device provides transactional rollback.

After deployment, verification compares intended and observed behavior. Continuous monitoring detects configuration, policy, and topology drift. Drift should normally create an alert or proposed correction that returns through the reviewed Git workflow instead of silently changing production. Least privilege access, secrets management, audit logs, change history, and stored test results provide traceability.

Common mistakes are treating generated configuration as the source of truth instead of the original intent, allowing direct production edits outside the workflow, checking syntax but not policy or device capability, deploying to every device at once, assuming every device supports transactional rollback, and continuing rollout after a health gate fails. Another mistake is checking only configuration text after deployment. The framework should also verify operational behavior such as interfaces, neighbors, routing convergence, policy enforcement, telemetry, and alarms. Automatically repairing every detected drift without review can also overwrite a legitimate emergency change.

Explain the framework as one safety chain. Start with trusted intent, then generation, validation, review, staged rollout, verification, recovery, and drift detection. For each stage, say what unsafe condition it blocks. Emphasize that rollout stops when a health gate fails and that rollback depends on the real capability of the target device.

I would build an event driven, multi tenant CI/CD platform with separate stages for intake, build graph analysis, test selection, fair scheduling, isolated execution, artifact and cache management, promotion, and deployment tracking. Each repository event is deduplicated and mapped to a tenant. The build graph finds affected projects, and test selection runs the tests needed for the change. Work enters fair queues with tenant limits, then runs on autoscaled ephemeral workers. Successful outputs become immutable artifacts with provenance. The same artifact is promoted through controlled environments. Queue depth, wait time, build time, test time, cache hit rate, retries, failures, lead time, deployment frequency, change failure rate, and MTTR reveal where feedback is slowing down.

The goal is to let thousands of engineers send changes every day without one busy team slowing everyone else down. A change should enter quickly, find only the work affected by that change, run the useful checks, and receive shared computing capacity fairly. Successful results should be saved once and reused safely as they move toward production. The system should also show engineers what is happening and give operators clear measurements when work starts waiting too long, tests become slow, or deployment results take too long to return.

1. How many repositories and changes per day should the platform support?
2. Are builds mostly independent services, or is there a large shared code base?
3. What feedback time should developers normally receive?
4. Which deployments require manual approval?
5. Should workers run on Kubernetes, Nomad, or another approved execution platform?

I would split the platform into eight stages. Git pushes, pull requests, webhooks, scheduled events, and approved automation events enter an event router. Intake deduplicates repeated events, identifies the team and repository, and applies rate limits and burst control.

A build graph service resolves dependencies, finds affected projects, and creates a build DAG. Smart test selection uses historical test behavior, coverage information, and risk to select useful unit, integration, end to end, and performance tests.

Selected work enters multi tenant queues. Weighted fair queuing or dominant resource fairness gives teams a fair share. Per tenant limits control concurrency, CPU, memory, cache use, and queue size. Burst credits can absorb short spikes without allowing a noisy tenant to consume the platform.

The scheduler sends jobs to autoscaled ephemeral workers. Each job runs in an isolated container or microVM with resource and network limits. Jobs use least privilege identity and short lived secrets. Network policy, dependency scanning, and security checks reduce risk.

Build outputs go to an immutable artifact store. Distributed build and dependency caches reuse content addressed results when inputs match. Retention and garbage collection limit storage growth. The platform records signed commits, artifact digests, SBOM data, checksums, and build provenance.

Transient infrastructure failures retry with backoff and a bounded retry budget. Deterministic failures fail fast. Idempotent jobs and stable work identifiers prevent duplicate side effects.

A release orchestrator applies quality gates, policy checks, approvals, version checks, and provenance checks. It promotes the same immutable artifact through environments instead of rebuilding it. Deployment can use staged rollout, canary, or blue green techniques. Health checks, rollback status, and deployment progress are surfaced to engineers.

I would watch queue depth, P50 and P95 wait time, build time, test time, cache hit rate, retry rate, failure rate, lead time, deployment frequency, change failure rate, and MTTR. High wait time points to scheduling or capacity pressure. High test time points to slow tests. Low cache hit rate points to poor reuse.

A common mistake is to place every build in one FIFO queue because a large team can then dominate worker capacity. Another mistake is to rebuild the application for each environment instead of promoting the same immutable artifact. Running every test for every commit can also create unnecessary feedback delay when dependency and coverage data can safely narrow the test set. Unlimited retries can create a retry storm, while retrying deterministic failures only wastes capacity. Other mistakes include weak tenant isolation, shared long lived credentials, mutable artifact references without digest tracking, caches without content based keys, missing provenance, and monitoring worker CPU while ignoring queue depth and wait time.

Explain the design as one flow from commit to deployment status. Spend extra time on the parts that become difficult at 5,000 engineers: fair queues, tenant quotas, selective testing, autoscaled isolated workers, correct cache reuse, immutable artifact promotion, bounded retries, provenance, and feedback time metrics. Connect each design choice to the bottleneck or failure it prevents.

I would use a highly available global control plane that creates one signed and immutable release, distributes it through global storage and regional caches, and rolls it out progressively. Each region starts with a small canary group, passes health gates, then moves through larger batches until the region is complete. Host agents pull the approved artifact, verify it, and report health and state. If a gate fails, I stop progression and roll back the affected batch. If one region fails, I isolate it and continue healthy regions. Disconnected hosts use cached approved content when possible and reconcile state after reconnecting.

The goal is to update a very large number of computers around the world without causing a large outage. I would not change every computer at once. I would prepare one trusted release, send it close to each location, test it on a small group first, and expand only when the results stay healthy. Each location can move independently, so one broken location does not stop every healthy location. Computers with poor connections can wait or use a trusted local copy, then report their state after they reconnect. This keeps failures small and recovery predictable.

1. How quickly must a worldwide release finish?
2. Can different regions progress independently?
3. What health signals should stop a rollout?
4. How long may disconnected hosts remain offline?
5. Are database changes required to remain compatible with the previous application version?

I would start with a global control plane running across multiple active regions. Users enter through an authenticated API, command line interface, or user interface. The control plane contains the deployment orchestrator, policy and approval checks, health evaluator, rollback engine, targeting inventory, and audit events. Replicated metadata, deployment state, configuration, and event stores keep rollout decisions available if one control plane region fails.

The build pipeline starts from a committed or merged change. Continuous integration runs build, test, and security checks. It creates one immutable version, records its software bill of materials, signs it, and publishes the package, binary, or container artifact to global object storage and content delivery caches. Deployment promotes this exact artifact rather than rebuilding it for each region.

Before rollout, the orchestrator checks dependencies, compatibility, policy, capacity, quotas, and change windows. The strategy progresses from global planning to a region, then to a canary, then to controlled batches, and finally to the full regional fleet. Each region starts with roughly 1 to 5 percent of its servers. A healthy canary advances to a first batch of roughly 10 to 20 percent, then a second batch of roughly 20 to 30 percent, and finally to 100 percent.

At every stage, automated health gates evaluate error rate, latency, crashes, availability, synthetic checks, service objectives, and business signals. Healthy stages progress automatically. An unhealthy stage pauses progression and triggers remediation or rollback.

Agents on hosts pull from a nearby content delivery endpoint or regional cache, verify the signature and software bill of materials, apply the approved version atomically when the target platform supports atomic replacement, run local health checks, and report status. Deployment actions use idempotent behavior so a safe retry does not create a second logical deployment.

If a health gate fails, progression stops and the affected batch rolls back to the previous known good version. A feature flag can disable risky behavior quickly. Database changes must remain backward compatible or have a safe reverse plan.

If one region fails during rollout, the control plane marks that region degraded and stops new deployment work there. Healthy regions continue. The failed region retries with backoff or waits for manual recovery. After repair, rollout can resume automatically under policy or after manual approval.

A disconnected host detects the loss of connectivity. It can apply an already approved artifact from a trusted local cache when policy allows, or wait. It queues health and event records while offline. After reconnecting to the nearest endpoint, it synchronizes state, events, and inventory, then reconciles with desired state before normal operation continues.

A common mistake is pushing a new release to the entire fleet at once. That creates a very large blast radius. Another mistake is rebuilding an artifact separately for each region instead of promoting the same immutable artifact. Candidates also forget dependency and compatibility checks before rollout, or they treat a single metric as proof that a release is healthy. Other mistakes include making every region depend on one control plane location, allowing one failed region to block healthy regions, assuming disconnected hosts can always contact the control plane, retrying deployment actions without idempotency, and claiming rollback is safe when database changes are not compatible with the previous application version.

Explain the rollout as a sequence. Start with one immutable signed artifact and a highly available global control plane. Then describe prechecks, canary exposure, health gates, controlled regional batches, full rollout, and completion. After the normal path, explain three failures clearly: a bad release, a failed region, and a disconnected host. Emphasize that healthy regions keep moving while a failed region is isolated, and that rollback depends on a previous known good version plus compatible data changes.

At a high level, the IPv6 equivalent of an IPv4 A record is an AAAA record. The main point is knowing what the record represents and what it does not do. I would explain the forward DNS lookup, then contrast it with reverse lookup and local address configuration. An AAAA record maps a domain name to a 128-bit IPv6 address. PTR records handle reverse lookup. SLAAC or DHCPv6 can configure an IPv6 address on a host.

The goal is to understand how a name, such as example.com, can point to an IPv6 address. The important part is separating three different jobs. One job finds an IPv6 address from a domain name. Another job starts with an IP address and finds a name. A third job gives an IPv6 address to a device on a network. The diagram separates these jobs so they are not confused. The main answer is the AAAA record, which stores the IPv6 address used for forward name resolution.

1. Should I also explain how an AAAA record differs from an IPv4 A record?
2. Would you like me to contrast forward DNS with IPv6 reverse lookup?
3. Should I also explain why SLAAC and DHCPv6 are separate from DNS?

I would say that the IPv6 equivalent of an IPv4 A record is an AAAA record. An A record maps a domain name to a 32-bit IPv4 address. An AAAA record performs the same basic job for IPv6. It maps a domain name to a 128-bit IPv6 address.

For example, the diagram shows example.com with an AAAA value of 2001:db8:1a2b:3c4d::10. That value is the IPv6 address returned for the name.

For the normal lookup, the Client needs the IPv6 address for example.com. It sends a DNS query for record type AAAA to the Recursive DNS Resolver.

The resolver resolves the query and, if needed, queries other DNS servers. The Authoritative DNS holds the zone for example.com and returns the AAAA record. The Recursive DNS Resolver then returns the IPv6 address to the Client. This is forward name resolution because the lookup goes from a name to an address.

The record contains an IPv6 address as its value. The example shown is 2001:db8:1a2b:3c4d::10. The diagram also shows normal DNS fields such as the name, type, TTL, and class.

The key field for this question is the value. Type AAAA tells DNS that this value is an IPv6 address. In comparison, type A stores an IPv4 address.

I would then make clear that an AAAA record is not a reverse lookup record. Reverse lookup starts with an IP address and tries to find a domain name.

For IPv6, reverse lookup uses a PTR record in the ip6.arpa domain. So the directions are different. AAAA means domain name to IPv6 address. PTR means IPv6 address back to a name.

Finally, I would separate DNS from assigning an IPv6 address to a device. SLAAC or DHCPv6 can configure an IPv6 address on a host or interface. That is host-local network configuration, not a DNS AAAA lookup.

A local hosts file can also provide a local name-to-address mapping. These mechanisms do not replace an AAAA record in DNS. The useful interview distinction is simple: AAAA handles forward DNS for IPv6, PTR handles reverse lookup, and SLAAC or DHCPv6 handles host address configuration.

The benefit of an AAAA record is that IPv6 uses the same familiar DNS idea as IPv4. Applications can ask for a domain name and receive an IPv6 address. The main thing to remember is that several related features have different jobs. AAAA is for name-to-IPv6 lookup. PTR is for the opposite direction, from an IPv6 address to a name. SLAAC and DHCPv6 configure addresses on hosts. A local hosts file can also map names locally. Mixing these jobs together is the main source of confusion, so keeping the direction and purpose of each mechanism clear makes the answer much easier.

At a high level, TLS 1.3 keeps the same goal as TLS 1.2 but makes connection setup faster and removes many older choices. The main challenge is balancing lower latency with strong security and real-world compatibility. I would compare the handshake, key exchange, cipher choices, and session resumption. TLS 1.3 normally needs one round trip instead of two, uses stronger defaults, and removes legacy features. The trade-off is that older clients, servers, or middleboxes may still require TLS 1.2.

The goal is to understand how two generations of secure connections differ when a client connects to a server. Both protect information while it travels across a network. The newer design tries to start secure communication with fewer back-and-forth messages. It also removes many older choices that were harder to use safely. The important point is not simply that a newer number is better. I would compare how each connection starts, how secrets are created, what older features disappear, how repeat connections work, and what compatibility problems can remain.

1. Should I focus on a normal first connection, resumed connections, or both?
2. Should I discuss compatibility with older clients and network devices?
3. Do you want me to explain the security risk of TLS 1.3 0-RTT early data?

I would begin with the biggest visible difference: TLS 1.3 needs fewer message exchanges.

A typical TLS 1.2 full handshake takes two round trips before secure application data can flow. The client sends Client Hello. The server replies with Server Hello, Certificate, Server Key Exchange, and Server Hello Done. The client then sends its key-exchange information and Finished messages. The server finishes the handshake afterward.

TLS 1.3 normally completes a full handshake in one round trip. The Client Hello already includes a key share. The server can therefore return its key share, encrypted extensions, certificate information, and Finished message immediately.

Next, I would explain that TLS 1.3 removes many old cryptographic choices.

TLS 1.2 supports several key-exchange methods. Ephemeral ECDHE can provide forward secrecy, but older static RSA key exchange is also possible. Forward secrecy means that stealing a long-term key later does not reveal older protected sessions.

For normal certificate-based TLS 1.3 handshakes, ephemeral ECDHE is used. Static RSA key exchange is removed. TLS 1.3 also supports PSK modes for resumed connections.

Cipher-suite negotiation is simpler in TLS 1.3. The client offers supported cipher suites, and the server selects one. TLS 1.3 keeps a smaller set of modern authenticated-encryption choices.

I would then show why TLS 1.3 has safer defaults.

TLS 1.2 can provide forward secrecy, but it depends on the selected key exchange. TLS 1.3 certificate-based handshakes use ephemeral key exchange, so forward secrecy is the normal case. A PSK-only resumed mode does not inherently provide the same property.

TLS 1.3 also removes older features such as RC4, 3DES, MD5, SHA-1 signatures, TLS compression, static RSA key exchange, and renegotiation. Removing these choices reduces complexity and the chance of unsafe configuration.

For repeat connections, both versions can avoid repeating the entire original handshake.

TLS 1.2 can resume using a Session ID or Session Ticket. The diagram shows this as a one-round-trip resumed connection.

TLS 1.3 uses PSK-based resumption. It can also allow optional 0-RTT early application data. This data can be sent immediately, but it can be replayed. Applications should therefore restrict 0-RTT to operations that are safe to repeat.

The benefit of TLS 1.3 is lower connection latency and fewer old security features. The downside is operational compatibility. Older clients, servers, and some middleboxes may not fully support it, so deployments may need TLS 1.2 during migration.

I would finish by saying that the protocol version alone never proves a system is safe. Valid certificates, strong configuration, timely updates, and monitoring still matter.

The benefit is that TLS 1.3 normally starts a secure connection faster. A full handshake needs one round trip instead of the two shown for TLS 1.2. It also removes many older cryptographic choices, which makes unsafe setup less likely. The downside is compatibility. Some older clients, servers, and middleboxes may still need TLS 1.2. TLS 1.3 can also send 0-RTT early data on resumed connections, but that data can be replayed. We accept these trade-offs because TLS 1.3 gives better defaults while still requiring careful configuration, valid certificates, updates, and monitoring.

At a high level, containerization runs applications in isolated environments while still sharing the host Linux kernel. The main challenge is separating what each container can see and controlling what resources it can use. I would explain it in three parts: Linux namespaces provide isolated views, cgroups account for and control resources, and the shared kernel defines the security boundary. This makes containers lightweight and fast, but they do not provide complete kernel-level isolation.

Containerization lets several applications run on one Linux host while giving each application its own controlled view of the system. The hard part is that containers are not separate virtual machines. Their processes still use the same Linux kernel. The diagram explains this with three main ideas. Linux namespaces control what each container can see. cgroups measure and control resource use. The shared host kernel makes containers lightweight, but it also creates an important security boundary that containers cannot remove by themselves.

1. Should I focus on Linux containers and the container runtime boundary?
2. Should I explain both namespace isolation and cgroup resource controls?
3. Should I also cover the security limits of sharing one host kernel?

I would start by saying that a container is not a virtual machine. The Container Runtime, such as containerd/runc in the diagram, starts container processes on the Linux host. Container A, Container B, and Container C each have an application process, dependencies, binaries, and a container filesystem view. Those processes still execute through the same host Linux kernel.

Namespaces control what a container can see. A PID Namespace gives the container its own process-ID view. A Mount Namespace gives it a separate filesystem and mount view. A Network Namespace gives it separate network interfaces, IP addresses, routes, ports, and related networking state.

The diagram also shows IPC, UTS, User, and Cgroup namespaces. IPC separates certain process communication resources. UTS separates the hostname and domain name. A User Namespace can map container user and group IDs to different IDs outside the container. A Cgroup Namespace gives the container an isolated view of its cgroup hierarchy.

Namespaces mainly control visibility. cgroups control resource use. The runtime places container processes into a cgroup hierarchy and applies resource rules.

For CPU, the diagram shows cpu.max and cpu.weight. Memory uses controls such as memory.max and memory.high. I/O can use io.max and io.weight. pids.max limits the number of processes. For networking, the diagram notes that policy or accounting can use tc or eBPF because cgroup v2 does not provide a direct bandwidth controller.

All containers share the Linux Kernel. They therefore rely on the same kernel scheduler, memory manager, VFS, network stack, device drivers, and security modules. This shared kernel is why containers are small and start quickly.

The downside is that the kernel is also a shared security boundary. Containers use the kernel version and architecture supplied by the host. A kernel vulnerability can therefore affect the host and other containers.

Containers do not create separate hardware or separate kernels. CPU features, memory, devices, and other physical resources are shared. Timing and cache side channels are not automatically prevented.

Resource exhaustion is also possible when cgroup limits are missing. Running as root inside a poorly restricted container can be dangerous. So namespaces, cgroups, capabilities, and Linux security modules provide different kinds of isolation and control, but containers alone do not provide complete kernel-level security.

The benefit is that containers are lightweight because they share one Linux kernel. Namespaces still give each container separate views of processes, filesystems, networking, hostnames, and users. cgroups can measure and control CPU, memory, I/O, and process usage. The downside is that the kernel and physical hardware remain shared. A kernel problem may therefore affect more than one container. Missing resource limits can also let one container use too much CPU, memory, or other host resources. We accept this trade-off because containers provide useful isolation with much less overhead than giving every workload its own operating-system kernel.