DevOps Senior - Technical Assessment

Candidate information

Full name

Email

Phone (optional)

Years of experience

CV / Resume Accepted formats: PDF, DOC, DOCX. Maximum 5MB

Knowledge questions

This IAM policy has a security problem: `{ "Effect": "Allow", "Action": "s3:*", "Resource": "*" }`. What is it?

Wildcard `*` in Resource and Action grants full access to ALL S3 buckets. Violates least privilege principle. Solution: specify exact bucket ARNs and only necessary actions (e.g., `s3:GetObject` on `arn:aws:s3:::my-bucket/*`)

Missing the `Principal` field in the policy, without which IAM cannot determine who the permission applies to and the policy is completely ignored

The problem is using JSON format instead of YAML to define IAM policies; AWS recommends YAML for being more readable and less error-prone

IAM policies do not support the use of wildcards (`*`) in any field; each action and resource must be specified individually without exceptions

How is a multi-account strategy structured with AWS Organizations?

A single AWS account for all environments and teams is sufficient if granular IAM policies are used to separate access

Landing Zone with OUs (Organizational Units): Security, Workloads (dev/staging/prod), Sandbox. SCPs for guardrails at OU level. Centralized logging account, separate security account, and SSO for federated access

AWS Organizations is exclusively a consolidated billing service and does not provide security or governance functionalities

An individual AWS account per developer on the team is needed to guarantee complete resource isolation

When to use ALB vs NLB vs API Gateway in AWS?

They are completely interchangeable services that provide exactly the same functionality with different commercial names

API Gateway completely replaces ALB and NLB in all use cases and is always the most economical and efficient option

ALB: HTTP/HTTPS with path/host/header routing (web microservices). NLB: TCP/UDP ultra-low latency and millions of connections (gaming, IoT). API Gateway: REST/WebSocket APIs with auth, throttling, transformations, and monetization

NLB is exclusively for databases and cannot be used to balance web application or REST API traffic

How is Azure AD (Entra ID) used to federate identities in an organization?

Azure AD only works with Microsoft-developed applications (Office 365, Teams) and is not compatible with third-party or custom applications

Entra ID only serves to manage corporate email accounts and has no authentication or authorization capabilities for applications

It is not possible to integrate Azure AD with AWS or GCP; each cloud provider requires its own completely independent identity system

Entra ID acts as central Identity Provider (IdP): SSO with SAML/OIDC for cloud and on-premise apps, Conditional Access policies, MFA, integration with AWS/GCP via federation trust, and sync with on-premise AD via Azure AD Connect

When to choose BigQuery (GCP) vs Redshift (AWS) vs Athena (AWS) for analytics?

BigQuery: serverless, pay-per-query, ideal for ad-hoc analysis and integrated ML. Redshift: dedicated cluster, better for predictable workloads and constant high volume. Athena: serverless over S3, ideal for occasional queries without dedicated infrastructure

They are exactly the same services with different names on each cloud provider; the choice is purely by provider preference

Athena is always faster than BigQuery in all scenarios because it operates directly on S3 without additional processing overhead

Redshift is a serverless service like BigQuery and does not require cluster management or node configuration from the user

This Docker image has vulnerabilities: `FROM node:14\nARG DB_PASSWORD\nRUN echo $DB_PASSWORD > /tmp/config\nCOPY . /app\nRUN npm install`. What are the problems?

The only problem is missing `WORKDIR /app` before COPY to correctly set the working directory

Outdated base image (node:14 EOL with known CVEs), secret in build args (remains in layer history), secret written to image filesystem. Solution: updated image, multi-stage, secrets via runtime env vars or Docker secrets, not at build time

The problem is using npm instead of yarn as package manager; yarn is more secure because it verifies checksums of all installed packages

ARG is more secure than ENV for handling secrets in Docker because ARG values are automatically removed after the build completes

A Pod is in CrashLoopBackOff. Logs show `OOMKilled` and the liveness probe fails. What is happening?

The cluster does not have enough available nodes and the scheduler cannot find a node with free resources to run the Pod

CrashLoopBackOff is always a network error caused by DNS problems or connectivity issues between the Pod and the Service exposing it

The container exceeds its memory limit (OOMKilled by kernel) and restarts. The liveness probe fails during restart, causing the loop. Solution: increase `resources.limits.memory`, optimize memory consumption, or check if liveness probe is too heavy

The only solution is to manually delete the Pod with `kubectl delete pod` and wait for the Deployment to recreate it with a clean configuration

How to achieve zero-downtime deployments in Kubernetes?

Just running `kubectl apply` with the new manifest is sufficient to achieve zero-downtime without any additional configuration

Zero-downtime is technically impossible in Kubernetes due to the ephemeral nature of Pods and container startup time

Only increasing the Deployment replica count is needed; with enough replicas downtime becomes imperceptible automatically

Rolling update with `maxSurge`/`maxUnavailable`, readiness probes (no traffic until ready), preStop hooks (graceful shutdown), PodDisruptionBudget (minimum available pods), and connection draining on Service/Ingress

What is a Service Mesh (Istio/Linkerd) and what problems does it solve?

Infrastructure layer managing service-to-service communication: automatic mTLS (security), circuit breaking and retries (resilience), observability (metrics, traces), traffic management (canary, A/B) — all without modifying application code

A type of specialized physical network for data centers that requires dedicated hardware and cannot be implemented in cloud environments

Only serves to centralize logging of distributed applications and does not provide security or traffic management functionalities

Completely replaces Kubernetes as a container orchestrator and cannot be used alongside it in the same infrastructure

Terraform plan shows unexpected changes on a resource not modified in code. What happened?

Terraform has a known bug that causes phantom changes in the plan; it is resolved by updating to the latest CLI version

Drift: someone modified the resource manually (console/CLI) outside Terraform. State does not match reality. Solution: `terraform refresh` to update state, then decide whether to import the manual change or revert with `terraform apply`

Must completely delete the state file and recreate it from scratch with `terraform import` of all existing resources

Unexpected changes in the plan are normal Terraform behavior and can be safely ignored when running apply

How to manage Terraform state in a team?

Each developer should maintain their own local state file on their machine and sync it manually with the team via chat or email

Committing the state file to the Git repository is sufficient for team collaboration; Git handles conflicts automatically

Remote backend (S3 + DynamoDB for locking on AWS, or Terraform Cloud). Locking prevents concurrent writes. Workspaces or separate directories per environment. State encryption at rest and access controlled via IAM

State locking is not needed if the team is small (less than 10 people); conflicts are extremely rare in practice

How to structure Terraform modules for multi-environment (dev/staging/prod)?

Reusable modules with variables for environment differences. Structure: `modules/` (shared logic) + `environments/dev|staging|prod/` (specific configuration with tfvars). Use workspaces or separate directories, with remote state per environment

Copy and paste the complete Terraform code for each environment in separate directories without sharing modules or configuration

A single main.tf file for all environments with `if/else` conditionals to differentiate the configuration of each one

Terraform does not natively support multiple environments; an external tool like Terragrunt is mandatory

This Ansible playbook is not idempotent: `- name: Configure app\n shell: echo "DB_HOST=prod" >> /etc/app.conf`. Why and how to fix?

Ansible is always idempotent by design regardless of the module used; the `shell` module guarantees the command only executes once

The problem is using the `echo` command instead of `cat`; switching to `cat` makes the playbook idempotent automatically

Just need to add `become: yes` to run as root; the idempotency problem is resolved with elevated permissions

`shell` with `>>` appends the line every time it runs (duplicates). Solution: use `lineinfile` module with `line` and `regexp`, or `template` with a Jinja2 file. Alternative: add `creates:` or `when:` to condition execution

How to implement canary deployments with automatic rollback based on metrics?

Canary deployment is simply deploying the new version to 50% of servers simultaneously without metric monitoring

Canary only works as part of a blue-green strategy and cannot be implemented independently as a deployment pattern

Deploy new version to a small % of traffic (5-10%), monitor key metrics (error rate, p99 latency, saturation). If metrics exceed threshold → automatic rollback. Tools: Flagger/Argo Rollouts in K8s, AWS CodeDeploy with CloudWatch alarms

Automatic rollback based on metrics is not possible to implement; human intervention is always required to decide whether to revert a deployment

How to integrate feature flags in a deployment pipeline?

Feature flags (LaunchDarkly, Unleash, Flagsmith) allow separating deploy from release: deploy code with features disabled, gradually activate by user segment, instant rollback without redeploy. Integrate in CI/CD to activate flags after successful deploy

Feature flags are simply static environment variables configured on the server that require redeploy to change their value

Feature flags completely replace code versioning with Git and make branches and tags unnecessary for managing releases

Only work with frontend applications (JavaScript/React) and are not applicable to backend services or APIs due to technical limitations

How to manage secrets securely in infrastructure?

Defining environment variables directly in source code is sufficient if the repository is private and has restricted team access

Encrypting the `.env` file with GPG and committing it to the repository is a secure practice accepted by industry standards

HashiCorp Vault (dynamic secrets, rotation), AWS Secrets Manager/Parameter Store (native integration), Sealed Secrets in K8s (encrypted in repo, decrypted in cluster). Principles: automatic rotation, audit logging, least privilege, never in code/repos

Secrets do not need periodic rotation if they are sufficiently long and complex; rotation only introduces unnecessary downtime risk

This Kubernetes NetworkPolicy has a problem: `apiVersion: networking.k8s.io/v1\nkind: NetworkPolicy\nspec:\n podSelector: {}\n policyTypes: ["Ingress"]\n ingress:\n - from:\n - podSelector:\n matchLabels:\n app: frontend`. What is missing?

The policy is completely correct and has no security problems; it adequately restricts all unauthorized traffic

Only restricts ingress but not egress — pods can communicate with any external destination (data exfiltration possible). Missing `policyTypes: ["Ingress", "Egress"]` with explicit egress rules limiting allowed destinations

Missing namespace specification in the podSelector; without namespace the policy does not apply to any pod in the cluster

`podSelector: {}` is invalid syntax in NetworkPolicy and should specify at least one label to select affected pods

What is the difference between logs, metrics, and traces, and how are they correlated with OpenTelemetry?

Three different ways to do exactly the same thing; choosing one is sufficient to have complete system observability

OpenTelemetry is exclusively a distributed tracing tool and has no capability to manage logs or metrics

Metrics completely replace logs in modern systems; maintaining logs is a legacy practice that adds unnecessary overhead

Logs: discrete events with context (what happened). Metrics: aggregatable numeric values over time (how the system is doing). Traces: tracking a request across services (where the problem is). OpenTelemetry unifies with shared trace_id/span_id across all three

How to implement auto-scaling with custom metrics in Kubernetes?

HPA (Horizontal Pod Autoscaler) with custom metrics via Prometheus Adapter or KEDA (Kubernetes Event-Driven Autoscaling). KEDA scales based on external events (queue length, HTTP requests, cron). Configure: metric server → HPA/KEDA → scale target with cooldown periods

Only HPA with CPU and memory metrics is sufficient for any use case; custom metrics provide no additional benefit

Kubernetes does not support custom metrics for auto-scaling; it can only scale based on container CPU and memory

Auto-scaling with custom metrics only works in managed cloud clusters (EKS, GKE, AKS) and is not possible in on-premise clusters

How to automate incident response using webhooks and tools like n8n?

Incident response must always be completely manual because automation introduces risks of incorrect actions without human supervision

Alerts (Prometheus/CloudWatch) → webhook to n8n/PagerDuty → automated workflow: create ticket, notify Slack with context, escalate if no ACK in X minutes, execute automatic runbooks (restart pod, scale up), and document incident timeline

n8n is exclusively a marketing automation tool and has no capabilities for managing infrastructure or application incidents

Webhooks are not sufficiently reliable for managing critical incidents because messages can be lost without delivery guarantee

Coding challenge

Design and implement complete infrastructure with Terraform: VPC with public/private subnets, EKS or ECS cluster with auto-scaling, RDS with read replica, and CI/CD pipeline with canary strategy. Include architecture diagram and decision documentation.

Requirements

Modular Terraform: VPC (public/private subnets, NAT), EKS/ECS with auto-scaling policies
RDS PostgreSQL with read replica in another AZ and automatic backups
CI/CD pipeline with canary deployment and automatic rollback based on metrics
Architecture diagram (draw.io, Mermaid, or similar)
Technical decision documentation (ADRs) and cost estimation

Examples

Input: terraform apply -var-file=environments/prod.tfvars

Output:

Complete infrastructure deployed: VPC with 3 AZs, EKS cluster with 2-10 auto-scaling nodes, multi-AZ RDS, ALB with WAF, and functional pipeline

Accepted technologies

Terraform
AWS (EKS/ECS, RDS, VPC)
GitHub Actions / GitLab CI
Helm charts for K8s
Prometheus + Grafana for observability

Solution submission

Repository URL * Supported platforms: GitHub, GitLab, Bitbucket Enter a valid repository URL (https://github.com, gitlab.com, or bitbucket.org followed by owner/repository)

DevOps - Senior